In message <20100210141016.4D18.A69D9226@xxxxxxxxxxxxxx> you wrote: > > On 02/09/2010 10:51 PM, Michael Neuling wrote: > > >>> I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it > > >>> as well. > > >> > > >> There's only one CONFIG_GROWSUP arch - parisc. > > >> Could someone please test it on parisc? > > > > I did. > > > > > How about doing: > > > 'ulimit -s 15; ls' > > > before and after the patch is applied. Before it's applied, 'ls' should > > > be killed. After the patch is applied, 'ls' should no longer be killed. > > > > > > I'm suggesting a stack limit of 15KB since it's small enough to trigger > > > 20*PAGE_SIZE. Also 15KB not a multiple of PAGE_SIZE, which is a trickier > > > case to handle correctly with this code. > > > > > > 4K pages on parisc should be fine to test with. > > > > Mikey, thanks for the suggested test plan. > > > > I'm not sure if your patch does it correct for parisc/stack-grows-up-case. > > > > I tested your patch on a 4k pages kernel: > > root@c3000:~# uname -a > > Linux c3000 2.6.33-rc7-32bit #221 Tue Feb 9 23:17:06 CET 2010 parisc GNU/Li nux > > > > Without your patch: > > root@c3000:~# ulimit -s 15; ls > > Killed > > -> correct. > > > > With your patch: > > root@c3000:~# ulimit -s 15; ls > > Killed > > _or_: > > root@c3000:~# ulimit -s 15; ls > > Segmentation fault > > -> ?? > > > > Any idea? > > My x86_64 box also makes segmentation fault. I think "ulimit -s 15" is too sm all stack for ls. > "ulimit -s 27; ls " wroks perfectly fine. Arrh. I asked Helge offline earlier to check what use to work on parisc on 2.6.31. I guess PPC has a nice clean non-bloated ABI :-D Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
