In message <20100210141016.4d18.a69d9...@jp.fujitsu.com> 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: > > r...@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: > > r...@c3000:~# ulimit -s 15; ls > > Killed > > -> correct. > > > > With your patch: > > r...@c3000:~# ulimit -s 15; ls > > Killed > > _or_: > > r...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
