[musl][PATCH]fix tsd's issue

[musl][PATCH]fix tsd's issue

[=?gb18030?B?zcPX09bt?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 492 bytes --]

Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows:
1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized.
2, Musl calls malloc before updating TLS size in dl stage 3.
3, New created initial_tls doesn't carry builtin_tls's tsd.


The attached patch could fix this issue, please review it, thanks.

[-- Attachment #1.2: Type: text/html, Size: 718 bytes --]

[-- Attachment #2: fix_tsd_issue.patch --]
[-- Type: application/octet-stream, Size: 662 bytes --]

diff --git a/ldso/dynlink.c b/ldso/dynlink.c
index 09f3b0a8..94b8c776 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -2024,9 +2024,12 @@ void __dls3(size_t *sp, size_t *auxv)
 	/* Actual copying to new TLS needs to happen after relocations,
 	 * since the TLS images might have contained relocated addresses. */
 	if (initial_tls != builtin_tls) {
-		if (__init_tp(__copy_tls(initial_tls)) < 0) {
+        pthread_t self = __pthread_self();
+        phtread_t td = __copy_tls(initial_tls);
+		if (__init_tp(td) < 0) {
 			a_crash();
 		}
+        td->tsd = self->tsd;
 	} else {
 		size_t tmp_tls_size = libc.tls_size;
 		pthread_t self = __pthread_self();

Re: [musl][PATCH]fix tsd's issue

[Rich Felker]

On Tue, Feb 14, 2023 at 03:25:23PM +0800, 兔子猪 wrote:
> Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows:
> 1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized.
> 2, Musl calls malloc before updating TLS size in dl stage 3.
> 3, New created initial_tls doesn't carry builtin_tls's tsd.
> 
> 
> The attached patch could fix this issue, please review it, thanks.

An interposed malloc being reachable before the crt1 entry point is a
bug that needs to be fixed. This is a context where it's not valid to
call any application-provided code. Where does the call happen from?
dynlink.c itself uses the internal malloc but I guess there's
somewhere the interposable malloc is getting called indirectly from.

Rich

Re: [musl][PATCH]fix tsd's issue

[Rich Felker]

On Tue, Feb 14, 2023 at 07:05:15AM -0500, Rich Felker wrote:
> On Tue, Feb 14, 2023 at 03:25:23PM +0800, 兔子猪 wrote:
> > Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows:
> > 1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized.
> > 2, Musl calls malloc before updating TLS size in dl stage 3.
> > 3, New created initial_tls doesn't carry builtin_tls's tsd.
> > 
> > 
> > The attached patch could fix this issue, please review it, thanks.
> 
> An interposed malloc being reachable before the crt1 entry point is a
> bug that needs to be fixed. This is a context where it's not valid to
> call any application-provided code. Where does the call happen from?
> dynlink.c itself uses the internal malloc but I guess there's
> somewhere the interposable malloc is getting called indirectly from.

I went looking for it and couldn't find any sign of malloc
reachability unless you go back to 1.2.1. Commit
c1e5d243b7e39b2fbfb17144608ce045575d8e95 removed the use via stdio,
and 34952fe5de44a833370cbe87b63fb8eec61466d7 switched to internal
malloc for all direct use from ldso. Are you just using a really old
version?

Rich

[musl] =?gb18030?B?u9i4tKO6IFttdXNsXVtQQVRDSF1maXggdHNkJ3MgaXNzdWU=?=

[=?gb18030?B?zcPX09bt?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1976 bytes --]

I got it, I am using version 1.2.0, Next I will switch to the latest version.




------------------ Ô­Ê¼Óʼþ ------------------
·¢¼þÈË:                                                                                                                        "musl"                                                                                    <dalias@libc.org&gt;;
·¢ËÍʱ¼ä:&nbsp;2023Äê2ÔÂ14ÈÕ(ÐÇÆÚ¶þ) ÍíÉÏ9:44
ÊÕ¼þÈË:&nbsp;"ÍÃ×ÓÖí"<3264430019@qq.com&gt;;
³­ËÍ:&nbsp;"musl"<musl@lists.openwall.com&gt;;
Ö÷Ìâ:&nbsp;Re: [musl][PATCH]fix tsd's issue



On Tue, Feb 14, 2023 at 07:05:15AM -0500, Rich Felker wrote:
&gt; On Tue, Feb 14, 2023 at 03:25:23PM +0800, ÍÃ×ÓÖí wrote:
&gt; &gt; Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows:
&gt; &gt; 1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized.
&gt; &gt; 2, Musl calls malloc before updating TLS size in dl stage 3.
&gt; &gt; 3, New created initial_tls doesn't carry builtin_tls's tsd.
&gt; &gt; 
&gt; &gt; 
&gt; &gt; The attached patch could fix this issue, please review it, thanks.
&gt; 
&gt; An interposed malloc being reachable before the crt1 entry point is a
&gt; bug that needs to be fixed. This is a context where it's not valid to
&gt; call any application-provided code. Where does the call happen from?
&gt; dynlink.c itself uses the internal malloc but I guess there's
&gt; somewhere the interposable malloc is getting called indirectly from.

I went looking for it and couldn't find any sign of malloc
reachability unless you go back to 1.2.1. Commit
c1e5d243b7e39b2fbfb17144608ce045575d8e95 removed the use via stdio,
and 34952fe5de44a833370cbe87b63fb8eec61466d7 switched to internal
malloc for all direct use from ldso. Are you just using a really old
version?

Rich

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