| Message ID | 20160831123911.3467676-2-arnd@arndb.de |
|---|---|
| State | Awaiting Upstream, archived |
| Delegated to: | David Miller |
| Headers | show |
Arnd Bergmann <arnd@arndb.de> wrote: > gcc -Wmaybe-initialized correctly points out a newly introduced bug > through which we can end up calling rxrpc_queue_call() for a dead > connection: How do you turn that on from within the Kbuild system? David
On Wednesday, August 31, 2016 6:39:04 PM CEST David Howells wrote: > Arnd Bergmann <arnd@arndb.de> wrote: > > > gcc -Wmaybe-initialized correctly points out a newly introduced bug > > through which we can end up calling rxrpc_queue_call() for a dead > > connection: > > How do you turn that on from within the Kbuild system? You don't, my mistake. My build bot runs with 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally") disabled, and I had assumed that Linus left the warning enabled with "make W=1", but that was incorrect as Trond Myklebust also pointed out. You still get the warning with "make EXTRA_CFLAGS=-Wmaybe-uninitialized", which of course nobody normally does. I'll try to come up with a patch to enable the warning in the W=1 level in the same conditions that used to be enabled up to v4.7. Arnd
Is there a 1/2 somewhere? I don't see it. David
Arnd Bergmann <arnd@arndb.de> wrote: > + } else { > + sched = 0; That should be false, not 0, btw. David
On Wednesday, August 31, 2016 9:25:46 PM CEST David Howells wrote: > Is there a 1/2 somewhere? I don't see it. > > David Sorry, mixed up the Cc list. It only went to netdev and lkml and isn't really related. That one was a workaround for a false-positive -Wmaybe-uninitialized warning in NFS, see https://lkml.org/lkml/2016/8/31/412 Arnd
On Wednesday, August 31, 2016 9:26:21 PM CEST David Howells wrote: > Arnd Bergmann <arnd@arndb.de> wrote: > > > + } else { > > + sched = 0; > > That should be false, not 0, btw. > Right, sorry about that. Do you want me to resend the fixed version, or do you apply and fix it yourself? As patch 1/2 isn't actually meant for net-next anyway, the series doesn't need to stay together. Arnd
From: David Howells <dhowells@redhat.com> Date: Wed, 31 Aug 2016 21:25:46 +0100 > Is there a 1/2 somewhere? I don't see it. It was an NFSv4 patch.
Arnd Bergmann <arnd@arndb.de> wrote: > Right, sorry about that. Do you want me to resend the fixed version, > or do you apply and fix it yourself? I can fix it up myself. I'll pull it into my tree when I've finished doing the fixing up I'm currently working on. David
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c index 104ee8b1de06..2daec1eaec6f 100644 --- a/net/rxrpc/call_object.c +++ b/net/rxrpc/call_object.c @@ -595,6 +595,8 @@ static void rxrpc_mark_call_released(struct rxrpc_call *call) sched = __rxrpc_abort_call(call, RX_CALL_DEAD, ECONNRESET); if (!test_and_set_bit(RXRPC_CALL_EV_RELEASE, &call->events)) sched = true; + } else { + sched = 0; } write_unlock(&call->state_lock); if (sched)
gcc -Wmaybe-initialized correctly points out a newly introduced bug through which we can end up calling rxrpc_queue_call() for a dead connection: net/rxrpc/call_object.c: In function 'rxrpc_mark_call_released': net/rxrpc/call_object.c:600:5: error: 'sched' may be used uninitialized in this function [-Werror=maybe-uninitialized] This sets the 'sched' variable to zero to restore the previous behavior. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: f5c17aaeb2ae ("rxrpc: Calls should only have one terminal state") --- net/rxrpc/call_object.c | 2 ++ 1 file changed, 2 insertions(+)