On Fri 30-06-17 10:08:03, Linus Torvalds wrote: > On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko <[email protected]> wrote: > > > > FWIW our gcc guys shown an interest in having something to tell the > > kernel how much the stack can grow at once. They want it for testing of > > the new stack probing alloca implementation. > > Here, I made this just for them: > > #define STACK_GROWTH_SIZE (4096) > > isn't that beautiful? A new kernel interface without some stupid sysfs > file for it. > > And the added advantage is that it compiles to nice dense code too. > > > I have something > > preliminary with /proc/<pid>/stack_expand_limit for the internal testing > > purpose but maybe there will be more interest for this. I > > NO NO NO. > > I absolutely refuse to see the stack gap as some kind of "this is how > much you can grow the stack without probing". > > That's complete and utter garbage. > > Tell them that they can grow the stack by 4kB. That's it. If they want > to get all fancy, and they say that they really want an > architecture-specific value, tell them to use getpagesize().
Ohh, you misunderstood I guess. They wanted that only for internal testing (e.g. make sure that everything that matters blows up if it is doing something wrong). Absolutely nothing to base any compilator decistion on. > The stack gap is there due to the ABI being broken. If we're fixing > the ABI, then the stack gap has *nothing* to add. Yeah I know. The only usecase why I thought this might be interesting is when you run the code you haven't compiled with a compiler which does the proper thing. Think of all the 3rd party stuff that you eventually _need_ to run. Then you have also a hard guess to tune your gap for. If you can blow on/warn about unexpectedly large stack expansions then you can protect that particular piece of SW. But as I've said, this is not something I planned to post upstream but you mentioning a warning made me think that I could just mention it. -- Michal Hocko SUSE Labs
