linux-kernel - Re: [PATCH] rxrpc: split up rxrpc_send_call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <12692.1475278509@warthog.procyon.org.uk>
Date:   Sat, 01 Oct 2016 00:35:09 +0100
From:   David Howells <dhowells@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     dhowells@...hat.com, "David S. Miller" <davem@...emloft.net>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rxrpc: split up rxrpc_send_call_packet()

Arnd Bergmann <arnd@...db.de> wrote:

> A number of reworks went into rxrpc_send_call_packet() recently, which
> introduced another warning when built with -Wmaybe-uninitialized:
> 
> In file included from ../net/rxrpc/output.c:20:0:
> net/rxrpc/output.c: In function 'rxrpc_send_call_packet':
> net/rxrpc/ar-internal.h:1187:27: error: 'top' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> net/rxrpc/output.c:103:24: note: 'top' was declared here
> net/rxrpc/output.c:225:25: error: 'hard_ack' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This is a false positive, but it's also an indication that the function is
> getting complex enough that the compiler cannot figure out what it does.
> 
> This splits out a rxrpc_send_ack_packet() function for one part of
> it, making it more understandable by both humans and the compiler
> and avoiding the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> Unfortunately, this is a larger rework that I was hoping for, and
> I have only build tested it, so please review carefully, or just
> discard it and treat it as feedback to the original patch.

I think I'd rather cleanly split it into two transmission functions.  I'll do
that.

Thanks,
David