Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 9 May 2011 16:17:29 -0700 | Subject | Re: [PATCH] Don't mlock guardpage if the stack is growing up |
| |
On Mon, May 9, 2011 at 4:08 PM, Tony Luck <tony.luck@gmail.com> wrote: > > Definitely not for normal processes - I'm not sure how both stacks are > set up for threads.
We don't actually allow user space to set the growsup/growsdown bits any more (we have PROT_GROWSUP and PROT_GROWSDOWN, but that is to allow mprotect to not give an exact range, but say "apply this to the end of a growsup/growsdown segment").
So the only thing that has those bits are things that the kernel sets explicitly at exec time. So if ia64 doesn't set it, we're all good.
>> One thing I did want to verify: did the mlockall() actually change the >> stack size without that patch? Just to double-check that the patch >> actually did change semantics visibly. > > On an unpatched system I see this (lots more than one page of growth - > pages are 64K on this config): > 6007fffffff50000-6007fffffff70000 rw-p 00000000 00:00 0 > 6007fffffff50000-6008000000750000 rw-p 00000000 00:00 0 > > On a patched system I see (this one has 16K pages - no growth) > 600007ffff9d0000-600007ffff9d4000 rw-p 00000000 00:00 0 > 600007ffff9d0000-600007ffff9d4000 rw-p 00000000 00:00 0
Ok, I'll consider it tested. I'll commit it with Mikulas as author, but note that I edited it so he won't get the blame if there's some problem.
Linus
| |