[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5af8f26bcb3468eb777bb8a8c8258d6@AcuMS.aculab.com>
Date: Tue, 20 Oct 2020 08:00:19 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Joe Perches' <joe@...ches.com>, kernel test robot <lkp@...el.com>,
"Ard Biesheuvel" <ardb@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>
CC: "kbuild-all@...ts.01.org" <kbuild-all@...ts.01.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: RE: lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes
is larger than 1024 bytes
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@...el.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?
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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists