net: sunrpc: svcauth_gss: use BUG_ON instead of if condition followed by BUG

Use BUG_ON instead of if condition followed by BUG.

This issue was detected with the help of Coccinelle.

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
 net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

net/sunrpc/auth_gss/svcauth_gss.c +3 -6

index 7b1ee5a..a10ce43 100644
@@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
 	/* copy out mic... */
-	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+	BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);
 	*p++ = htonl(gc->gc_seq);
-	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
 	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;

Signature · 1 line

2.7.4

In the past we've avoided BUG_ON(X) where X might have side effects, on the theory that it should actually be OK just to compile out BUG_ON()s. Has that changed?

In any case, I don't find that this improves readability; dropping.

--b.

Quoted 39 lines · Gustavo A. R. Silva

Use BUG_ON instead of if condition followed by BUG.

This issue was detected with the help of Coccinelle.

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------

1 file changed, 3 insertions(+), 6 deletions(-)

net/sunrpc/auth_gss/svcauth_gss.c +3 -6

index 7b1ee5a..a10ce43 100644
@@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
 	/* copy out mic... */
-	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+	BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);
 	*p++ = htonl(gc->gc_seq);
-	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
 	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;

Signature · 1 line

2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and return an error?

-dros

Quoted 54 lines · J. Bruce Fields

In the past we've avoided BUG_ON(X) where X might have side effects, on the theory that it should actually be OK just to compile out BUG_ON()s. Has that changed?

In any case, I don't find that this improves readability; dropping.

--b.

Quoted 39 lines · Gustavo A. R. Silva

Use BUG_ON instead of if condition followed by BUG.

This issue was detected with the help of Coccinelle.

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------

1 file changed, 3 insertions(+), 6 deletions(-)

net/sunrpc/auth_gss/svcauth_gss.c +3 -6

index 7b1ee5a..a10ce43 100644
@@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
 	/* copy out mic... */
-	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+	BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);
 	*p++ = htonl(gc->gc_seq);
-	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
 	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;

Signature · 1 line

2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 1 line · Weston Andros Adamson

Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and return an error?

I think the BUG() will just kill an nfsd thread that isn't holding any interesting locks.

The failures look unlikely. (Except for that read_u32... return, I wonder if we're missing a check there.)

--b.

Quoted 58 lines

-dros

Quoted 55 lines · J. Bruce Fields

In the past we've avoided BUG_ON(X) where X might have side effects, on the theory that it should actually be OK just to compile out BUG_ON()s. Has that changed?

In any case, I don't find that this improves readability; dropping.

--b.

Quoted 39 lines · Gustavo A. R. Silva

Use BUG_ON instead of if condition followed by BUG.

This issue was detected with the help of Coccinelle.

Signed-off-by Gustavo A. R. Silva <[email protected]>

---
net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------

1 file changed, 3 insertions(+), 6 deletions(-)

net/sunrpc/auth_gss/svcauth_gss.c +3 -6

index 7b1ee5a..a10ce43 100644
@@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
 	/* copy out mic... */
-	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+	BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);
 	*p++ = htonl(gc->gc_seq);
-	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
-		BUG();
+	BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
 	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;

Signature · 1 line

2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines · J. Bruce Fields

Quoted 1 line · Weston Andros Adamson

Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and return an error?

I think the BUG() will just kill an nfsd thread that isn't holding any interesting locks.

Not necessarily. If panic_on_oops is set (and it usually is in "production" setups), it'll crash the box there.

Quoted 2 lines

The failures look unlikely. (Except for that read_u32... return, I wonder if we're missing a check there.)

Agreed, looks like you only hit an error if the read attempts to go out of bounds. In principle that shouldn't ever happen (and I haven't seen any reports of it).

Still...I agree with Dros that it's better to handle this without oopsing if we can. We can return an error from either of those functions. A sane error and a WARN_ONCE would be better here.

Quoted 11 lines · J. Bruce Fields

Quoted 2 lines · Weston Andros Adamson

Quoted 1 line

Is there a reason to BUG() in these places? Couldn't we

WARN_ON_ONCE and return an error?

Quoted 4 lines

I think the BUG() will just kill an nfsd thread that isn't holding any interesting locks.

Not necessarily. If panic_on_oops is set (and it usually is in "production" setups), it'll crash the box there.

Maybe they're getting what they asked for?

Quoted 10 lines

Quoted 2 lines

The failures look unlikely. (Except for that read_u32... return, I wonder if we're missing a check there.)

Agreed, looks like you only hit an error if the read attempts to go out of bounds. In principle that shouldn't ever happen (and I haven't seen any reports of it).

Still...I agree with Dros that it's better to handle this without oopsing if we can. We can return an error from either of those functions. A sane error and a WARN_ONCE would be better here.

OK, OK, OK.

There are also some more BUGs that could use looking into if anyone wants to.

--b.

commit eb754930662f

Author: J. Bruce Fields <[email protected]>
Date:   Tue Oct 24 14:58:11 2017 -0400

rpc: remove some BUG()s

It would be kinder to WARN() and recover in several spots here instead of BUG()ing.

Also, it looks like the read_u32_from_xdr_buf() call could actually fail, though it might require a broken (or malicious) client, so convert that to just an error return.

Reported-by Weston Andros Adamson <[email protected]>

Signed-off-by J. Bruce Fields <[email protected]>

net/sunrpc/auth_gss/svcauth_gss.c +0 -0

index 7b1ee5a0b03c..73165e9ca5bf 100644
@@ -855,11 +855,13 @@ unwrap_integ_data(struct svc_rqst *rqstp,  

struct xdr_buf *buf, u32 seq, struct g

net/sunrpc/auth_gss/svcauth_gss.c +5 -3

 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len)) {
+		WARN_ON_ONCE(1);
+		return stat;
+	}
 	/* copy out mic... */
 	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+		return stat;
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1613,10 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);

Quoting "J. Bruce Fields" <[email protected]>:

Quoted 76 lines · Jeff Layton

Quoted 12 lines · J. Bruce Fields

Quoted 2 lines · Weston Andros Adamson

Quoted 1 line

Is there a reason to BUG() in these places? Couldn't we

WARN_ON_ONCE and return an error?

Quoted 4 lines

I think the BUG() will just kill an nfsd thread that isn't holding any interesting locks.

Not necessarily. If panic_on_oops is set (and it usually is in "production" setups), it'll crash the box there.

Maybe they're getting what they asked for?

Quoted 10 lines

Quoted 2 lines

The failures look unlikely. (Except for that read_u32... return, I wonder if we're missing a check there.)

Agreed, looks like you only hit an error if the read attempts to go out of bounds. In principle that shouldn't ever happen (and I haven't seen any reports of it).

Still...I agree with Dros that it's better to handle this without oopsing if we can. We can return an error from either of those functions. A sane error and a WARN_ONCE would be better here.

OK, OK, OK.

There are also some more BUGs that could use looking into if anyone wants to.

--b.

commit eb754930662f

Author: J. Bruce Fields <[email protected]>
Date:   Tue Oct 24 14:58:11 2017 -0400

rpc: remove some BUG()s

It would be kinder to WARN() and recover in several spots here instead of BUG()ing.

Also, it looks like the read_u32_from_xdr_buf() call could actually fail, though it might require a broken (or malicious) client, so convert that to just an error return.

Reported-by Weston Andros Adamson <[email protected]>

Signed-off-by J. Bruce Fields <[email protected]>

net/sunrpc/auth_gss/svcauth_gss.c +0 -0

index 7b1ee5a0b03c..73165e9ca5bf 100644
@@ -855,11 +855,13 @@ unwrap_integ_data(struct svc_rqst *rqstp,  

struct xdr_buf *buf, u32 seq, struct g

net/sunrpc/auth_gss/svcauth_gss.c +5 -3

 		return stat;
 	if (integ_len > buf->len)
 		return stat;
-	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
-		BUG();
+	if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len)) {
+		WARN_ON_ONCE(1);
+		return stat;
+	}
 	/* copy out mic... */
 	if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
-		BUG();
+		return stat;
 	if (mic.len > RPC_MAX_AUTH_SIZE)
 		return stat;
 	mic.data = kmalloc(mic.len, GFP_KERNEL);

@@ -1611,8 +1613,10 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
 	BUG_ON(integ_len % 4);
 	*p++ = htonl(integ_len);

net/sunrpc/auth_gss/svcauth_gss.c svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp) · line 1622

Quoted 10 lines

net/sunrpc/auth_gss/svcauth_gss.c +4 -2

 	*p++ = htonl(gc->gc_seq);
-	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
-		BUG();
+	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len)) {
+		WARN_ON_ONCE(1);
+		goto out_err;
+	}
 	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;

What about the following BUG() at net/sunrpc/svc_xprt.c:1058:

/*
* Remove a dead transport
*/
static void svc_delete_xprt(struct svc_xprt *xprt)

{
         struct svc_serv *serv = xprt->xpt_server;
         struct svc_deferred_req *dr;

         /* Only do this once */
         if (test_and_set_bit(XPT_DEAD, &xprt->xpt_flags))
                 BUG();

         dprintk("svc: svc_delete_xprt(%p)\n", xprt);
         xprt->xpt_ops->xpo_detach(xprt);

         spin_lock_bh(&serv->sv_lock);
         list_del_init(&xprt->xpt_list);
         WARN_ON_ONCE(!list_empty(&xprt->xpt_ready));
         if (test_bit(XPT_TEMP, &xprt->xpt_flags))
                 serv->sv_tmpcnt--;
         spin_unlock_bh(&serv->sv_lock);

         while ((dr = svc_deferred_dequeue(xprt)) != NULL)
                 kfree(dr);

         call_xpt_users(xprt);
         svc_xprt_put(xprt);
}

I'm suspicious about that comment above the _if_ condition: /* Only do this once */

Would it help to replace that BUG with a WARN_ON_ONCE?