| Message ID | BLU0-SMTP61D9E1AAC7E9DE17FA604F97440@phx.gbl (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Sun, Apr 27, 2014 at 4:20 PM, John David Anglin <dave.anglin@bell.net> wrote: > The attached change implements the default behavior used by the majority of > architectures. > > Signed-off-by: John David Anglin <dave.anglin@bell.net> Reviewed-by: Carlos O'Donell <carlos@systemhalted.org> I have reviewed the kernel code to make sure this does what's intended and I've reviewed the userpace NPTL implementation to verify that the new infinity value correctly causes the desired semantics e.g. use of a sensible default. This will cause threads using the max stack to have their stack decreased from 80 MB to 8 MB, but 80 MB was never the correct value to use anyway and is the cause of userspace failures to create more threads. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/parisc/include/uapi/asm/resource.h b/arch/parisc/include/uapi/asm/resource.h index 8b06343..090483c 100644 --- a/arch/parisc/include/uapi/asm/resource.h +++ b/arch/parisc/include/uapi/asm/resource.h @@ -1,7 +1,6 @@ #ifndef _ASM_PARISC_RESOURCE_H #define _ASM_PARISC_RESOURCE_H -#define _STK_LIM_MAX 10 * _STK_LIM #include <asm-generic/resource.h> #endif
There are only a couple of architectures that override _STK_LIM_MAX to a non-infinity value. This changes the stack allocation semantics in subtle ways. For example, make changes its stack allocation to the hard maximum defined by _STK_LIM_MAX. As a results, threads executed by processes running under make are allocated a stack size of _STK_LIM_MAX rather than a sensible default value. This causes various thread stress tests to fail when they can't muster more than about 50 threads. The attached change implements the default behavior used by the majority of architectures. Signed-off-by: John David Anglin <dave.anglin@bell.net> --- -- John David Anglin dave.anglin@bell.net