On Thu, 2025-09-11 at 11:44 +0200, Johannes Berg wrote: > 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 <[email protected]> > > > > > > > > > > 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. > > Maybe? The only thing would be to know which "CPU" we're executing on? > getpid() is async signal safe (i.e. you can call it), but there could be > better ways of doing this such as setting different signal handler > functions in different CPUs.
There are a number of ways to solve that problem. One way would be to use a signal stack and calculating it from the stack pointer. Though I am still considering that we should use the tasks stack as the signal stack, in which case we may need to track the CPU that a task is executing on. On 64bit, one could also use the FS/GS registers for per-CPU data. I believe the libc uses FS only on 64bit, so we could probably already use the GS register to for per-CPU data. So, I am not really worried about this, we probably need a nice solution for per-CPU data anyway. Benjamin
