| Message ID | 15499.1559298884@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rxrpc: Fix uninitialized error code in rxrpc_send_data_packet() | expand |
From: David Howells <dhowells@redhat.com> Date: Fri, 31 May 2019 11:34:44 +0100 > Here's my take on the patch. I assume I'll see a final version of this under separate cover.
Hi David, On Fri, May 31, 2019 at 12:35 PM David Howells <dhowells@redhat.com> wrote: > Here's my take on the patch. > > David > --- > rxrpc: Fix uninitialized error code in rxrpc_send_data_packet() > > With gcc 4.1: > > net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’: > net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function > > Indeed, if the first jump to the send_fragmentable label is made, and > the address family is not handled in the switch() statement, ret will be > used uninitialized. > > Fix this by BUG()'ing as is done in other places in rxrpc where internal > support for future address families will need adding. It should not be > possible to reach this normally as the address families are checked > up-front. > > Fixes: 5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: David Howells <dhowells@redhat.com> I'm not such a big fan of BUG(), so I'd go for ret = -EAFNOSUPPORT, but given rxrpc is already full of BUG() calls, I guess it is an acceptable solution. > --- > diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c > index 004c762c2e8d..6f2b4fb4b0aa 100644 > --- a/net/rxrpc/output.c > +++ b/net/rxrpc/output.c > @@ -523,6 +523,9 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb, > } > break; > #endif > + > + default: > + BUG(); > } > > if (ret < 0) Gr{oetje,eeting}s, Geert
Geert Uytterhoeven <geert@linux-m68k.org> wrote: > I'm not such a big fan of BUG(), so I'd go for ret = -EAFNOSUPPORT, but given > rxrpc is already full of BUG() calls, I guess it is an acceptable solution. Okay. Are you okay with this going through net-next? David
Hi David, On Tue, Jun 4, 2019 at 9:34 AM David Howells <dhowells@redhat.com> wrote: > Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > I'm not such a big fan of BUG(), so I'd go for ret = -EAFNOSUPPORT, but given > > rxrpc is already full of BUG() calls, I guess it is an acceptable solution. > > Okay. Are you okay with this going through net-next? Yes, I am. Gr{oetje,eeting}s, Geert
diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 004c762c2e8d..6f2b4fb4b0aa 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -523,6 +523,9 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb, } break; #endif + + default: + BUG(); } if (ret < 0)
Hi Geert, Here's my take on the patch. David --- rxrpc: Fix uninitialized error code in rxrpc_send_data_packet() With gcc 4.1: net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’: net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function Indeed, if the first jump to the send_fragmentable label is made, and the address family is not handled in the switch() statement, ret will be used uninitialized. Fix this by BUG()'ing as is done in other places in rxrpc where internal support for future address families will need adding. It should not be possible to reach this normally as the address families are checked up-front. Fixes: 5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David Howells <dhowells@redhat.com> ---