netdev - Re: [PATCH net] rtnetlink: fix frame size warning in rtnl_fill

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: <1447712329.2095039.441554865.621B2AF9@webmail.messagingengine.com>
Date:	Mon, 16 Nov 2015 23:18:49 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net] rtnetlink: fix frame size warning in rtnl_fill_ifinfo

Hi,

On Mon, Nov 16, 2015, at 21:38, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Mon, 16 Nov 2015 12:05:03 +0100
> 
> > By declaring the huge stack allocations as static. We can do so
> > because we hold rtnl.
> 
> Look across the tree, this is an idiom copied all over the place.
> If putting a rtnl_link_stats64 object on the stack is truly a
> problem, we have a lot of spots to fix.
> 
> I do not think, therefore, that this solution is tenable, we
> need something that handles all cases properly.

I just wanted to shut up the gcc warning which is added if a function
uses more than 2048 bytes of stack space. We normally don't have the
problem and could also divide the function into two, but I don't see a
general solution to the problem. Mostly they need to be custom tailored
to the specific usage.

I can have a look if we can use kmalloc based storage for the stats, but
this also means that we add another NULL pointer check and error
handling for those cases. Let me have a look!

Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html