[LTP] clone10.c failed on 32bit compilation

Wei Gao wegao@suse.com
Fri Jan 16 04:01:40 CET 2026


Hi Chunfu Wen Li Wang

We're encountering an issue where the new test case clone10.c is consistently failing in 32-bit mode. Have you experienced similar problems?
I've attached some preliminary investigation results for reference. Any insights or suggestions would be greatly appreciated.

uname -r
6.19.0-rc5-gb71e635feefc

export CFLAGS="-m32 -fstack-protector-strong"
export LDFLAGS="-m32"
make clone10

tst_tmpdir.c:316: TINFO: Using /tmp/LTP_cloV8soQm as tmpdir (tmpfs filesystem)
tst_test.c:2025: TINFO: LTP version: 20250130-546-g13dbd838c
tst_test.c:2028: TINFO: Tested kernel: 6.19.0-rc5-gb71e635feefc #11 SMP PREEMPT_DYNAMIC Tue Jan 13 16:16:15 CST 2026 x86_64
tst_kconfig.c:71: TINFO: Couldn't locate kernel config!
tst_test.c:1846: TINFO: Overall timeout per run is 0h 00m 30s
clone10.c:63: TBROK: clone() failed: EINVAL (22)

Trace kernel source and found error will triggered by following function:
arch/x86/kernel/tls.c
static int set_new_tls(struct task_struct *p, unsigned long tls)
{
    struct user_desc __user *utls = (struct user_desc __user *)tls;

    if (in_ia32_syscall())
        return do_set_thread_area(p, -1, utls, 0);  <<<<<<<<<<<<
    else
        return do_set_thread_area_64(p, ARCH_SET_FS, tls);
}


int do_set_thread_area(struct task_struct *p, int idx,
                       struct user_desc __user *u_info,
                       int can_allocate)
{
...
        if (idx == -1)
                idx = info.entry_number;  <<<< entry_number is 0 which set by clone10

        /*
         * index -1 means the kernel should try to find and
         * allocate an empty descriptor:
         */
        if (idx == -1 && can_allocate) {   <<< can_allocate is 0 so SKIP, means 32bit mode can not support auto allocate
                idx = get_free_idx();
                if (idx < 0)
                        return idx;
                if (put_user(idx, &u_info->entry_number))
                        return -EFAULT;
        }

        if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
                return -EINVAL;  <<<< idx now is 0 so finally hit this return to clone10


Try following patch firslty still got EINVAL since tls_desc->entry_number will be -1 still go same error.

diff --git a/include/lapi/tls.h b/include/lapi/tls.h
index a067872e0..aedc907d9 100644
--- a/include/lapi/tls.h
+++ b/include/lapi/tls.h
@@ -73,6 +73,7 @@ static inline void init_tls(void)
        tls_desc->limit_in_pages = 0;
        tls_desc->seg_not_present = 0;
        tls_desc->useable = 1;
+       tls_ptr = tls_desc;

 #else
        tst_brk(TCONF, "Unsupported architecture for TLS");

so i try to change entry_number to correct one base kernel src logic.
diff --git a/include/lapi/tls.h b/include/lapi/tls.h
index a067872e0..9e69244da 100644
--- a/include/lapi/tls.h
+++ b/include/lapi/tls.h
@@ -64,7 +64,7 @@ static inline void init_tls(void)
        tls_ptr = allocate_tls_area();
        tls_desc = SAFE_MALLOC(sizeof(*tls_desc));
        memset(tls_desc, 0, sizeof(*tls_desc));
-       tls_desc->entry_number = -1;
+       tls_desc->entry_number = 13;
        tls_desc->base_addr = (unsigned long)tls_ptr;
        tls_desc->limit = TLS_SIZE;
        tls_desc->seg_32bit = 1;

Now i get following output, no EINVAL now but it seems child and parent point to same tls area.
tst_tmpdir.c:316: TINFO: Using /tmp/LTP_cloa20awq as tmpdir (tmpfs filesystem)
tst_test.c:2025: TINFO: LTP version: 20250130-546-g13dbd838c
tst_test.c:2028: TINFO: Tested kernel: 6.19.0-rc5-gb71e635feefc #11 SMP PREEMPT_DYNAMIC Tue Jan 13 16:16:15 CST 2026 x86_64
tst_kconfig.c:71: TINFO: Couldn't locate kernel config!
tst_test.c:1846: TINFO: Overall timeout per run is 0h 00m 30s
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


Thanks.
Regards
Wei Gao


More information about the ltp mailing list