linux-kernel - Re: [PATCH v2 04/10] um: Turn signals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f402a7b5ddfe92a8fbbc1460102cac7b5a5864b5.camel@sipsolutions.net>
Date: Wed, 10 Sep 2025 14:15:28 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Tiwei Bie <tiwei.bie@...ux.dev>, richard@....at, 
	anton.ivanov@...bridgegreys.com
Cc: linux-um@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	benjamin@...solutions.net, arnd@...db.de, tiwei.btw@...group.com
Subject: Re: [PATCH v2 04/10] um: Turn signals_* into thread-local variables

On Sun, 2025-08-10 at 13:51 +0800, Tiwei Bie wrote:
> From: Tiwei Bie <tiwei.btw@...group.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?

johannes