From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6529 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?6buE5bu65b+g?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible bug: MINSIGSTKSZ values Date: Mon, 17 Nov 2014 09:49:20 +0800 Message-ID: <54695420.3050408@i-soft.com.cn> References: <20141115031843.GA3679@brightrain.aerifal.cx> <54694CD4.5070501@i-soft.com.cn> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070506060702080609020103" X-Trace: ger.gmane.org 1416188990 1706 80.91.229.3 (17 Nov 2014 01:49:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 01:49:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6542-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 17 02:49:42 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XqBRl-0006ol-SN for gllmg-musl@m.gmane.org; Mon, 17 Nov 2014 02:49:42 +0100 Original-Received: (qmail 17728 invoked by uid 550); 17 Nov 2014 01:49:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17720 invoked from network); 17 Nov 2014 01:49:39 -0000 X-QQ-mid: bizesmtp3t1416188963t483t250 X-QQ-SSF: 00400000002000F0F522B00A0000000 X-QQ-FEAT: 1cJ015dZ0ZAj9ssWYF3lm3t5m/q3lzsitmbtzEN8HgumKpoyj/xgOq4rJB5DW pYWDrs1f2KRCqUWHFGlkG7WIQ2CC+nrrL02cUnhm2hNjLEe0hJdCohjirZvHN2kgKeSdWO8 QAFClJINR9BDD6KpcT+cj8ahLpmezYlypp1MgUcqFIOF70amIDMwjtSnLtEejhJcvyWDbXT RE5Dffyi9X05phgUVFgB1k3wxIVIjdpk= X-QQ-GoodBg: 2 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: X-QQ-SENDSIZE: 520 X-QQ-FName: C467E850B7EA4D39B40E04B07D2E4ECF X-QQ-LocalIP: 58.250.132.20 Xref: news.gmane.org gmane.linux.lib.musl.general:6529 Archived-At: This is a multi-part message in MIME format. --------------070506060702080609020103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 黄建忠 > 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 --------------070506060702080609020103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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> 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
--------------070506060702080609020103--