[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241004161737.GH10433@brightrain.aerifal.cx>
Date: Fri, 4 Oct 2024 12:17:38 -0400
From: Rich Felker <dalias@...c.org>
To: JinCheng Li <naiveli233@...look.com>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: Do we have any requirements for the notify method which
is registered into the timer_create of Musl, such as not using tsd
On Sun, Sep 22, 2024 at 11:19:53AM +0000, JinCheng Li wrote:
> Hi
>
> I found when using timer_create in hwasan, after call 'notify'
> function once, musl will call cleanup_fromsig and run
> __pthread_tsd_run_dtors. Then the hwasan tsd destructor will be done
> and cleared. After then we step into notify the second time, and
> becauese the hwasan tsd has been cleared, when the hwasan check has
> been triggered, sigv will happened. Why MUSL need do
> pthread_cleanup_push ，pthread_cleanup_pop and clear all tsd after
> notify? Does this mean that timed callbacks involving tsd may have
> issues executing in the timer_create of musl, for example the tsd in
> hwasan.
Semantically, each SIGEV_THREAD timer event arrives in a *newly
created thread*, which does not preserve any thread-local state from a
previous timer expiration event.
musl's implementation of SIGEV_THREAD reuses the same kernel-level
thread for each expiration event so that we have reserved the
resources for it and can ensure that there are no missed expiration
events due to lack of resources to create a new thread. To do this, we
make a "new application-level thread" by re-initializing the
kernel-level thread's state and the memory it uses for stack/TLS/TSD
to the values that should be seen in a newly created thread.
I don't know how hwasan works or what it needs to do to handle these
threads the way it wants to.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
