Messages in this thread | | | Date | Fri, 30 Jun 2017 19:26:02 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev |
| |
On Fri 30-06-17 10:08:03, Linus Torvalds wrote: > On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko <mhocko@kernel.org> 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
| |