On Mon 03-07-17 09:30:35, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 8:49 AM, Michal Hocko wrote:
> >
> > If you think this is worth pursuing in upstream, just let me know and I
> > can polish it, add a patch for the man page and other things.
>
> Hmm. This doesn't look bad, except the bprm g
On Mon, Jul 3, 2017 at 8:49 AM, Michal Hocko wrote:
>
> If you think this is worth pursuing in upstream, just let me know and I
> can polish it, add a patch for the man page and other things.
Hmm. This doesn't look bad, except the bprm games there really look annoying.
Also, I'm wondering whethe
On Fri 30-06-17 10:48:15, Linus Torvalds wrote:
> On Fri, Jun 30, 2017 at 10:26 AM, Michal Hocko wrote:
> >
> > 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 nothi
On Fri, Jun 30, 2017 at 10:26 AM, Michal Hocko wrote:
>
> 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.
Oh, good.
If t
On Fri 30-06-17 10:08:03, Linus Torvalds wrote:
> On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko 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 implementa
On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko 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_
On Wed 28-06-17 16:26:33, Linus Torvalds wrote:
[...]
> In fact, I'd even be quite open to adding a kernel warning about badly
> behaved binaries that grow their stack by a big amount in one go. Not
> only is it bad taste (and we really should encourage compilers to do
> probing every page when gro
On Thu, Jun 29, 2017 at 11:55 AM, Oleg Nesterov wrote:
>
> I didn't ;) I moved it up, right above VM_GROWSDOWN check.
I think I will just need to take a long nap, I'm clearly not tracking
the patches very well.
Linus
On 06/29, Linus Torvalds wrote:
>
> On Thu, Jun 29, 2017 at 8:19 AM, Oleg Nesterov wrote:
> >
> > Hmm. May be you misread this patch?
>
> Ahh, yes. I'm ok with your patch.
>
> That said, you did remove something extra: the comment about
>
> /* Check that both stack segments have the same anon_
On Thu, Jun 29, 2017 at 8:19 AM, Oleg Nesterov wrote:
>
> Hmm. May be you misread this patch?
Ahh, yes. I'm ok with your patch.
That said, you did remove something extra: the comment about
/* Check that both stack segments have the same anon_vma? */
is actually still relevant wrt that VM_G
On 06/28, Linus Torvalds wrote:
>
> On Wed, Jun 28, 2017 at 10:52 AM, Oleg Nesterov wrote:
> >
> > Now that the stack-guard-page has gone, why do we need to allow to grow
> > into the previous VM_GROWSDOWN vma? IOW, why we can not simply remove
> > the VM_GROWSDOWN check in expand_downwards() ?
>
On Wed, Jun 28, 2017 at 10:52 AM, Oleg Nesterov wrote:
>
> Now that the stack-guard-page has gone, why do we need to allow to grow
> into the previous VM_GROWSDOWN vma? IOW, why we can not simply remove
> the VM_GROWSDOWN check in expand_downwards() ?
Because the "prev" vma may actually be the or
12 matches
Mail list logo
