Re: [PATCH v2 04/10] um: Turn signals_* into thread-local variables

[Benjamin Berg <benjamin@sipsolutions.net>]

Hi,

On Thu, 2025-09-11 at 09:37 +0200, Benjamin Berg wrote:
> Hi,
> 
> On Thu, 2025-09-11 at 12:34 +0800, Tiwei Bie wrote:
> > On Wed, 10 Sep 2025 14:15:28 +0200, Johannes Berg wrote:
> > > On Sun, 2025-08-10 at 13:51 +0800, Tiwei Bie wrote:
> > > > From: Tiwei Bie <tiwei.btw@antgroup.com>
> > > > 
> > > > Turn signals_enabled, signals_pending and signals_active into
> > > > thread-local variables. This enables us to control and track
> > > > signals independently on each CPU thread. This is a preparation
> > > > for adding SMP support.
> > > 
> > > [...]
> > > 
> > > > +static __thread int signals_enabled;
> > > 
> > > How much glibc infrastructure does __thread rely on? More
> > > specifically:
> > > Some time ago we had a discussion about building UML as a nolibc
> > > binary,
> > > what would that mean for the __thread usage here?
> > 
> > We would need to parse TLS data (PT_TLS) from the ELF file
> > ourselves
> > and properly set up TLS when creating threads using clone().
> 
> I guess right now we cannot use PER_CPU variables in these files.
> However, my expectation that this is possible when using nolibc, and
> then it should be simple enough to replace the __thread.

That said, I do believe that the allocations from the libc itself are
problematic. A lot of the mappings from UML are there already (i.e. the
physical memory is mapped). However, I believe the vmalloc area for
example is not guarded.

So when pthread allocates the thread specific memory (stack, TLS, ...),
we really do not know where this will be mapped into the address space.
If it happens to be in an area that UML wants to use later, then UML
could map e.g. vmalloc data over it.

Now, it could be that (currently) the addresses picked by pthread (or
the host kernel) do not actually clash with anything. However, I do not
think there is any guarantee for that.

Benjamin