From: Herbert Xu > Sent: 17 June 2019 15:56 > On Mon, Jun 17, 2019 at 04:54:16PM +0200, Arnd Bergmann wrote: > > > > Just converting the three testvec_config variables is what I originally > > had in my patch. It got some configurations below the warning level, > > but some others still had the problem. I considered sending two > > separate patches, but as the symptom was the same, I just folded > > it all into one patch that does the same thing in four functions. > > Just curious, how bad is it with only moving testvec_config off > the stack? This all reminds me of some code I wrote a long time ago (1984?) that worked out the maximum stack use for a system by processing all the .o files to find out which functions called which at what stack depth and adding everything up. That system had no indirect calls and no recursion, but the worst stack use was always in diagnostic prints in obscure error paths. My guess is that the same is true for the Linux kernel. While getting rid of large on-stack buffers fixes the obvious cases full analysis is needed to guarantee the stack won't overflow. Doing that requires some method for determining the stack use of indirect calls - which really requires knowing which type of function is actually being called from each place. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
