From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next 0/2] rtnetlink: avoid a warning in rtnl_newlink() Date: Fri, 30 Nov 2018 13:34:26 -0800 (PST) Message-ID: <20181130.133426.679787546958710403.davem@davemloft.net> References: <20181128063231.12907-1-jakub.kicinski@netronome.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dsahern@gmail.com, jiri@resnulli.us, roopa@cumulusnetworks.com, christian.brauner@ubuntu.com, netdev@vger.kernel.org, oss-drivers@netronome.com To: jakub.kicinski@netronome.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:60314 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725941AbeLAIpG (ORCPT ); Sat, 1 Dec 2018 03:45:06 -0500 In-Reply-To: <20181128063231.12907-1-jakub.kicinski@netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jakub Kicinski 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.