Possible bug: MINSIGSTKSZ values

Possible bug: MINSIGSTKSZ values

[Rich Felker]

Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
insufficient to store the ucontext_t for many archs. I'd like to keep
it small on archs where that's possible, but the current value might
not even work for modern x86 with large AVX state, etc. that needs to
be saved. I don't have a proposed fix yet, but I think we should
survey the values that are needed for different archs and either make
it vary per-arch, or if they're all comparable, just increase the
value to something that works for all archs.

Note that the min pthread stack size is also well below the size of
ucontext_t for many archs, but I don't think this is a problem. If you
make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
need to start it with all signals blocked and leave them blocked (or
avoid using signal handlers at all).

Rich

Re: Possible bug: MINSIGSTKSZ values

[Rich Felker]

On Fri, Nov 14, 2014 at 10:18:43PM -0500, Rich Felker wrote:
> Note that the min pthread stack size is also well below the size of
> ucontext_t for many archs, but I don't think this is a problem. If you
> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
> need to start it with all signals blocked and leave them blocked (or
> avoid using signal handlers at all).

Sadly, this logic seems incorrect since we depend on signals for
cancellation. So the minimum allowable thread stack size might also be
forced higher on archs that need large signal frames... :(

Rich

Re: Possible bug: MINSIGSTKSZ values

[黄建忠]

Hi, Rich,

If that means some opensource projects need to be modified to fit Musl,  
would you consider to add a "__MUSL__" macro?

I think such a special macro will make upstream patch easy to be accepted.


在 11/15/14 11:18, Rich Felker 写道:
> Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
> insufficient to store the ucontext_t for many archs. I'd like to keep
> it small on archs where that's possible, but the current value might
> not even work for modern x86 with large AVX state, etc. that needs to
> be saved. I don't have a proposed fix yet, but I think we should
> survey the values that are needed for different archs and either make
> it vary per-arch, or if they're all comparable, just increase the
> value to something that works for all archs.
>
> Note that the min pthread stack size is also well below the size of
> ucontext_t for many archs, but I don't think this is a problem. If you
> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
> need to start it with all signals blocked and leave them blocked (or
> avoid using signal handlers at all).
>
> Rich
>


-- 
Huang JianZhong

Re: Possible bug: MINSIGSTKSZ values

[Ivan Kanakarakis]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

There will never be a __MUSL__ macro.
Please, see FAQ entry #2 for explanation
http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F



On 17 November 2014 03:18, 黄建忠 <jianzhong.huang@i-soft.com.cn> wrote:

> Hi, Rich,
>
> If that means some opensource projects need to be modified to fit Musl,
> would you consider to add a "__MUSL__" macro?
>
> I think such a special macro will make upstream patch easy to be accepted.
>
>
> 在 11/15/14 11:18, Rich Felker 写道:
>
>  Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
>> insufficient to store the ucontext_t for many archs. I'd like to keep
>> it small on archs where that's possible, but the current value might
>> not even work for modern x86 with large AVX state, etc. that needs to
>> be saved. I don't have a proposed fix yet, but I think we should
>> survey the values that are needed for different archs and either make
>> it vary per-arch, or if they're all comparable, just increase the
>> value to something that works for all archs.
>>
>> Note that the min pthread stack size is also well below the size of
>> ucontext_t for many archs, but I don't think this is a problem. If you
>> make a thread with a stack smaller than MINSIGSTKSZ+epsilon, you just
>> need to start it with all signals blocked and leave them blocked (or
>> avoid using signal handlers at all).
>>
>> Rich
>>
>>
>
> --
> Huang JianZhong
>
>
>
>


-- 
*Ivan c00kiemon5ter Kanakarakis*  >:3

[-- Attachment #2: Type: text/html, Size: 2714 bytes --]

Re: Possible bug: MINSIGSTKSZ values

[黄建忠]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Already read and understood that.

I agree that adding a "__MUSL__" macro is tricky(or WRONG as said), but 
I think it's will make thing easier.
we can not assume upstream projects will do these checking or will like 
to accept patches to "solve certain implementation" since they assume 
glibc is the standard for now.

It's a comprise, just a suggestion :-)

在 11/17/14 09:26, Ivan Kanakarakis 写道:
> There will never be a __MUSL__ macro.
> Please, see FAQ entry #2 for explanation
> http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
>
>
>
> On 17 November 2014 03:18, 黄建忠 <jianzhong.huang@i-soft.com.cn 
> <mailto:jianzhong.huang@i-soft.com.cn>> wrote:
>
>     Hi, Rich,
>
>     If that means some opensource projects need to be modified to fit
>     Musl,  would you consider to add a "__MUSL__" macro?
>
>     I think such a special macro will make upstream patch easy to be
>     accepted.
>
>
>     在 11/15/14 11:18, Rich Felker 写道:
>
>         Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
>         insufficient to store the ucontext_t for many archs. I'd like
>         to keep
>         it small on archs where that's possible, but the current value
>         might
>         not even work for modern x86 with large AVX state, etc. that
>         needs to
>         be saved. I don't have a proposed fix yet, but I think we should
>         survey the values that are needed for different archs and
>         either make
>         it vary per-arch, or if they're all comparable, just increase the
>         value to something that works for all archs.
>
>         Note that the min pthread stack size is also well below the
>         size of
>         ucontext_t for many archs, but I don't think this is a
>         problem. If you
>         make a thread with a stack smaller than MINSIGSTKSZ+epsilon,
>         you just
>         need to start it with all signals blocked and leave them
>         blocked (or
>         avoid using signal handlers at all).
>
>         Rich
>
>
>
>     -- 
>     Huang JianZhong
>
>
>
>
>
>
> -- 
> /Ivan c00kiemon5ter Kanakarakis/  >:3


-- 
Huang JianZhong


[-- Attachment #2: Type: text/html, Size: 4861 bytes --]

Re: Possible bug: MINSIGSTKSZ values

[Rich Felker]

On Mon, Nov 17, 2014 at 09:18:12AM +0800, 黄建忠 wrote:
> Hi, Rich,
> 
> If that means some opensource projects need to be modified to fit
> Musl,  would you consider to add a "__MUSL__" macro?
> 
> I think such a special macro will make upstream patch easy to be accepted.

I've never seen code that explicitly makes such a small thread stack;
it's not something you'd do without a specific need to, and probably
something you'd only do in an application where you control the
deployment and what libc etc. is in use rather than as source
distributed for use on different kinds of systems. Most code uses the
default thread-stack size or an explicit size based on its own stack
usage plus some margin of safety.

Also, as mentioned in my follow-up, the minimum thread stack size
really needs to include enough room for a signal frame since
cancellation is implemented with a signal handler and thus needs a
signal frame. So we probably need to bump up the minimum thread size
on some archs anyway. :(

Rich