Re: lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes

[Joe Perches <joe@perches.com>]

On Tue, 2020-10-20 at 08:00 +0000, David Laight wrote:
> From: Joe Perches
> > Sent: 19 October 2020 16:47
> > On Mon, 2020-10-19 at 03:13 +0800, kernel test robot wrote:
> > > Hi Ard,
> > > 
> > > First bad commit (maybe != root cause):
> > > 
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head:   9d9af1007bc08971953ae915d88dc9bb21344b53
> > > commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move existing library code into
> > lib/crypto
> > > date:   11 months ago
> > > config: i386-randconfig-r023-20201019 (attached as .config)
> > > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> > > reproduce (this is a W=1 build):
> > >         #
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fb8ef25803ef33e2eb60b62
> > 6435828b937bed75
> > >         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > >         git fetch --no-tags linus master
> > >         git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
> > >         # save the attached .config to linux build tree
> > >         make W=1 ARCH=i386
> > > 
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > 
> > > All warnings (new ones prefixed by >>):
> > > 
> > >    lib/crypto/chacha.c: In function 'chacha_permute':
> > > > > lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes [-
> > Wframe-larger-than=]
> > >       65 | }
> > >          | ^
> > > 
> > > vim +65 lib/crypto/chacha.c
> > 
> > This seems to come from function tracing overhead.
> 
> Are you sure?

No.  I'm trying to isolate it now.

> I've not got the x86 object, but the x86-64 version caches the 16 x[]
> values (from the parameter) in registers.
> The 32 bit cpu doesn't have enough registers, but gcc tends to
> compile assuming an infinite number.
> So it may have spilled lots of virtual registers to different
> stack locations - instead of writing the values to their 'target'
> address.