Are stack canaries shared via threads

It appears that the stack memory limit is not allocated (anyway, it couldn't with unlimited stack). https://www.kernel.org/doc/Documentation/vm/overcommit-accounting says:

The C language stack growth does an implicit mremap. If you want absolute guarantees and run close to the edge you MUST mmap your stack for the largest size you think you will need. For typical stack usage this does not matter much but it's a corner case if you really really care

However mmapping the stack would be the goal of a compiler (if it has an option for that).

EDIT: After some tests on an x84_64 Debian machine, I've found that the stack grows without any system call (according to strace). So, this means that the kernel grows it automatically (this is what the "implicit" means above), i.e. without explicit mmap/mremap from the process.

It was quite hard to find detailed information confirming this. I recommend Understanding The Linux Virtual Memory Manager by Mel Gorman. I suppose that the answer is in Section 4.6.1 Handling a Page Fault, with the exception "Region not valid but is beside an expandable region like the stack" and the corresponding action "Expand the region and allocate a page". See also D.5.2 Expanding the Stack.

Other references about Linux memory management (but with almost nothing about the stack):

• Memory FAQ
• What every programmer should know about memory by Ulrich Drepper

EDIT 2: This implementation has a drawback: in corner cases, a stack-heap collision may not be detected, even in the case where the stack would be larger than the limit! The reason is that a write in a variable in the stack may end up in allocated heap memory, in which case there is no page fault and the kernel cannot know that the stack needed to be extended. See my example in the discussion Silent stack-heap collision under GNU/Linux I started in the gcc-help list. To avoid that, the compiler needs to add some code at function call; this can be done with -fstack-check for GCC (see Ian Lance Taylor's reply and the GCC man page for details).

You can see some information using pmap -x PID - it's divided into kbytes, rss and dirty memory for each library/module/open file/stack of a process:

undefine@uml:~$ pmap -x 13206
13206:   sleep 60
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000      24      20       0 r-x-- sleep
0000000000606000       4       4       4 r---- sleep
0000000000607000       4       4       4 rw--- sleep
000000000063b000     132       8       8 rw---   [ anon ]
00007f6a9847e000    4308      44       0 r---- locale-archive
00007f6a988b3000    1772     376       0 r-x-- libc-2.19.so
00007f6a98a6e000    2048       0       0 ----- libc-2.19.so
00007f6a98c6e000      16      16      16 r---- libc-2.19.so
00007f6a98c72000       8       8       8 rw--- libc-2.19.so
00007f6a98c74000      20      12      12 rw---   [ anon ]
00007f6a98c79000     140     116       0 r-x-- ld-2.19.so
00007f6a98e71000      12      12      12 rw---   [ anon ]
00007f6a98e99000       8       8       8 rw---   [ anon ]
00007f6a98e9b000       4       4       4 r---- ld-2.19.so
00007f6a98e9c000       4       4       4 rw--- ld-2.19.so
00007f6a98e9d000       4       4       4 rw---   [ anon ]
00007fff09fd0000     132      12      12 rw---   [ stack ]
00007fff09ffe000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- ------- 
total kB            8652     656      96