Re: [RFC] mlock/stack guard interaction fixup

[Greg KH <gregkh@suse.de>]

On Sun, Aug 22, 2010 at 10:55:17AM +0100, Ian Campbell wrote:
> On Sun, 2010-08-22 at 08:33 +0100, Ian Campbell wrote:
> > On Sun, 2010-08-22 at 07:57 +0100, Ian Campbell wrote:
> > > On Sat, 2010-08-21 at 08:48 -0700, Linus Torvalds wrote:
> > > > On Sat, Aug 21, 2010 at 4:56 AM, Ian Campbell <ijc@hellion.org.uk> wrote:
> > > > >
> > > > > I don't know that they are particularly good tests for this change but I
> > > > > also ran allmodconfig kernel build and ltp on 2.6.35.3+fixes without
> > > > > issue. Are there any good mlock heavy workloads?
> > > > 
> > > > mlock itself isn't very interesting, I think more interesting is
> > > > testing that the doubly linked list handles all the cases correctly.
> > > > Something that splits mappings, unmaps partial ones etc etc. Running
> > > > something like Electric Fence is probably a good idea.
> > > 
> > > EF_DISABLE_BANNER=1 EF_ALLOW_MALLOC_0=1 LD_PRELOAD=libefence.so.0.0 make
> > > 
> > > craps out pretty quickly with:
> > > 
> > >           CC      init/main.o
> > >         
> > >         ElectricFence Exiting: mprotect() failed: Cannot allocate memory
> > >         make[1]: *** [init/main.o] Error 255
> > >         make: *** [init] Error 2
> > > 
> > > but it does that with 2.6.35.3, 2.6.35.2, 2.6.35.1 and 2.6.35 too so it
> > > doesn't seem to be breakage relating to any of the stack guard stuff
> > 
> > I increased the vm.max_map_count sysctl and now things are rolling
> > along. Will let you know how I get on.
> 
> So its slow and memory intensive as hell due to efence so my test box is
> struggling[0] but it has compiled 270+ .o files successfully so I think
> it's OK from that perspective. I think it'll be quite a while before I
> can say its passed an allmodconfig under efence though.
> 
> In the meantime I notice you've committed the patches. Can we get them
> queued up for stable backports at some point? I appreciate you might
> want them to bake for a bit longer in 2.6.36-rc first.
> 
> Greg, we are talking about:
> 0e8e50e20c837eeec8323bba7dcd25fe5479194c mm: make stack guard page logic use vm_prev pointer
> 7798330ac8114c731cfab83e634c6ecedaa233d7 mm: make the mlock() stack guard page checks stricter
> 297c5eee372478fc32fec5fe8eed711eedb13f3d mm: make the vma list be doubly linked

I must be missing something, but aren't these patches just "cleanups"
and changing the logic here to be nicer?  Or do they fix real problems
with the previous stack guard stuff?

Is it the second one you really need here?

thanks,

greg k-h