[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyLyhRtiZ0y3Mv-g0jLf3eHEJF_s+YUhim2bWAiYzRfSA@mail.gmail.com>
Date: Fri, 30 Jun 2017 10:08:03 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Oleg Nesterov <oleg@...hat.com>, Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Larry Woodman <lwoodman@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev
On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko <mhocko@...nel.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().
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.
Don't encourage shit.
Linus
Powered by blists - more mailing lists