Hey Hugh, On Wed, Jun 21, 2017 at 09:18:23AM +0200, Willy Tarreau wrote: > Thanks a lot, I'll include your patch and will test it again. And > yes, I intend to merge Helge's fix once it lands into mainline (maybe > it is right now, I didn't check) and possibly other ones you might be > working on depending on various feedback. So here's a quick update, I've built a kernel with my initial backport fixed by applying your patch on top of it and have run various tests on it. All I can say is that for me it works. I've instrumented a little bit more my test program (which I'm attaching). With 3.10.106+ unpatched, I get this : admin@formilux:~$ ulimit -s unlimited admin@formilux:~$ /tmp/gap 65536 < /dev/null mmap() failed stack=0x550024b0 [0x550024b0-0x7fc6d0f0] (717663296 total bytes) heap~=(nil) [(nil)-(nil)] (0 total bytes) anon~=0x7ffef000 [0x2aaab000-0x7ffef000] (1431584768 total bytes) heap...stack=2143736048 bytes heap+anon+stack=2149248064 bytes 08048000-080d6000 r-xp 00000000 00:0d 3263 /var/tmp/gap 080d6000-080d8000 rw-p 0008d000 00:0d 3263 /var/tmp/gap 080d8000-080fb000 rw-p 00000000 00:00 0 [heap] 2aaab000-5537d000 rw-p 00000000 00:00 0 [stack:1813] 55382000-7fc7f000 rw-p 00000000 00:00 0 7fc7f000-7ffff000 rw-p 00000000 00:00 0 ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] rounds: 10949 The output is not obvious, it dumps its last known pointer for each VMA and the upper and lower known as well, then dumps the contents of /proc/self/maps either after the segfault or after a failed alloc. Here you can see that the stack was seen equal to 0x550024b0, which totally belongs to the anon area, which is reported as stack in /proc/self/maps probably due to the pointers crossing each other. The stack really was the next VMA (55382000-7fc7f000). So we had a significant collision here, with about ~56 stack accesses being made in the anon VMA. With 3.10.107-rc and your latest fix I get this : admin@formilux:~$ ulimit -s unlimited admin@formilux:~$ /tmp/gap 65536