Maximum number of threads

Posted Jun 20, 2017 3:50 UTC (Tue) by ikm (guest, #493)
Parent article: Preventing stack guard-page hopping

Wouldn't this limit the maximum number of threads which can be created in a 32-bit address space to something smaller than 3072? Is it unreasonable to ask for more threads than that, given their stacks are all small?

Maximum number of threads

Posted Jun 20, 2017 5:34 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

32-bit glibc gives each thread a whopping 2MB stack by default (per `man pthread_create`), so you'll run out of address space long before then.

Maximum number of threads

Posted Jun 20, 2017 6:39 UTC (Tue) by thestinger (guest, #91827) [Link]

It only uses that 2M value if the stack rlimit is set to unlimited. Secondary stack size is usually 8M because the rlimit for the main thread stack is usually 8M, not unlimited.

Maximum number of threads

Posted Jun 20, 2017 15:01 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (2 responses)

No, this only affects the main thread stack. glibc does not use the kernel's MAP_GROWSDOWN feature for new thread stacks. The stack guard size for new threads is controlled using pthread_attr_setguardsize().

Maximum number of threads

Posted Jun 20, 2017 15:37 UTC (Tue) by ikm (guest, #493) [Link] (1 responses)

Hmm, the parent article specifically mentions that the main thread stack is generally not a problem, but the ones of the rest of the threads are:

> In a single-threaded process, the address space reserved for the stack can be large and difficult to overflow. Multi-threaded processes contain multiple stacks, though; those stacks are smaller and are likely to be placed between other virtual-memory areas of interest. An accidental overflow could corrupt the area located below a stack; a deliberate overflow, if it can be arranged, could be used to compromise the system.

So, if I understood things right, the change was about growing the guard size of all of the program's threads.

Maximum number of threads

Posted Jun 20, 2017 15:46 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Right, the article is incorrect on this point.