netdev - Re: [PATCH net-next 0/2] rtnetlink: avoid a warning in rtnl

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] [day] [month] [year] [list]

Message-Id: <20181130.133426.679787546958710403.davem@davemloft.net>
Date:   Fri, 30 Nov 2018 13:34:26 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     jakub.kicinski@...ronome.com
Cc:     dsahern@...il.com, jiri@...nulli.us, roopa@...ulusnetworks.com,
        christian.brauner@...ntu.com, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 0/2] rtnetlink: avoid a warning in
 rtnl_newlink()

From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Tue, 27 Nov 2018 22:32:29 -0800

> I've been hoping for some time that someone more competent would fix
> the stack frame size warning in rtnl_newlink(), but looks like I'll
> have to take a stab at it myself :)  That's the only warning I see
> in most of my builds.
> 
> First patch refactors away a somewhat surprising if (1) code block.
> Reindentation will most likely cause cherry-pick problems but OTOH
> rtnl_newlink() doesn't seem to be changed often, so perhaps we can
> risk it in the name of cleaner code?
> 
> Second patch fixes the warning in simplest possible way.  I was
> pondering if there is any more clever solution, but I can't see it..
> rtnl_newlink() is quite long with a lot of possible execution paths
> so doing memory allocations half way through leads to very ugly
> results.

Series applied, thanks for tackling this Jakub.

That whole "if (1) {" was probably just a construct used in order
to create an inner basic block for local variables, nothing more.