[LTP] [PATCH] lapi/tls: remove the TLS support from i386

[Jan Stancek]

On Wed, Jan 21, 2026 at 10:02 AM Li Wang via ltp <ltp@lists.linux.it> wrote:
>
> Using a LTP naked clone() to verify that CLONE_SETTLS is unreliable
> when running 32-bit on x86_64, since TLS requires two steps: writing
> the descriptor and switching the selector. But CLONE_SETTLS on i386
> only overrides the former:
>
>  kernel_clone()
>     copy_process()
>        copy_thread()
>           set_new_tls()
>              do_set_thread_area()
>
> In copy_thread(), the child's register frame is copied from the parent
> *childregs = *current_pt_regs(); and on the 32-bit side it also does
> savesegment(gs, p->thread.gs); saving the current %gs into thread_struct.
>
> Together, this means that unless something explicitly overwrites it later,
> the child's initial %gs selector is inherited from the parent.
>
>   https://elixir.bootlin.com/linux/v6.18/source/arch/x86/kernel/process.c#L243
>
> Then, in do_set_thread_area(), the kernel updates the TLS descriptor
> set_tls_desc(p, idx, &info, 1); However, when (p != current), the x86_32 path
> does not update or refresh any segment selector. So it updates the descriptor
> but does not switch the child's %gs selector to the new modified_sel.
>
>   https://elixir.bootlin.com/linux/v6.18/source/arch/x86/kernel/tls.c#L150
>
> Therefore, on i386, relying on CLONE_SETTLS alone can leave the child
> executing with the parent's %gs selector, so TLS accesses still resolve
> to the old TLS base.
>
> ===============
>
> The behavior above explains why clone10 fails even if we update the TLS
> descriptor base (either hard-coding or via set_thread_area()).
>
> Example (x86_64 kernel running a 32-bit ELF):
>
>   # uname -rm
>   6.19.0-rc2.liwang x86_64
>
>   # readelf -h clone10 |grep Class
>   Class:                             ELF32
>
>   # ./clone10
>   ...
>   clone10.c:48: TINFO: Child (PID: 5262, TID: 5263): TLS value set to: 101
>   clone10.c:72: TFAIL: Parent (PID: 5262, TID: 5262): TLS value mismatch: got 101, expected 100
>
> Reported-by: Wei Gao <wegao@suse.com>
> Signed-off-by: Li Wang <liwang@redhat.com>

Acked-by: Jan Stancek <jstancek@redhat.com>