<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/include/nolibc, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-01-11T14:18:20+00:00</updated>
<entry>
<title>tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set</title>
<updated>2026-01-11T14:18:20+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2025-09-24T14:20:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e6e013a73973213dfdd77c95b06e5614941a585'/>
<id>urn:sha1:2e6e013a73973213dfdd77c95b06e5614941a585</id>
<content type='text'>
[ Upstream commit c485ca3aff2442adea4c08ceb5183e671ebed22a ]

There is no errno variable when NOLIBC_IGNORE_ERRNO is defined. As such,
simply print the message with "unknown error" rather than the integer
value of errno.

Fixes: acab7bcdb1bc ("tools/nolibc/stdio: add perror() to report the errno value")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: make time_t robust if __kernel_old_time_t is missing in host headers</title>
<updated>2025-10-15T09:56:29+00:00</updated>
<author>
<name>Zhouyi Zhou</name>
<email>zhouzhouyi@gmail.com</email>
</author>
<published>2025-09-19T01:46:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c3dcf9164568d8b95f75c4ce44c16bbe171d12f'/>
<id>urn:sha1:5c3dcf9164568d8b95f75c4ce44c16bbe171d12f</id>
<content type='text'>
[ Upstream commit 0ff52df6b32a6b04a7c9dfe3d7a387aff215b482 ]

Commit d5094bcb5bfd ("tools/nolibc: define time_t in terms of
__kernel_old_time_t") made nolibc use the kernel's time type so that
`time_t` matches `timespec::tv_sec` on all ABIs (notably x32).

But since __kernel_old_time_t is fairly new, notably from 2020 in commit
94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t"),
nolibc builds that rely on host headers may fail.

Switch to __kernel_time_t, which is the same as __kernel_old_time_t and
has existed for longer.

Tested in PPC VM of Open Source Lab of Oregon State University
(./tools/testing/selftests/rcutorture/bin/mkinitrd.sh)

Fixes: d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t")
Signed-off-by: Zhouyi Zhou &lt;zhouzhouyi@gmail.com&gt;
[Thomas: Reformat commit and its message a bit]
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: fix spelling of FD_SETBITMASK in FD_* macros</title>
<updated>2025-08-28T14:26:04+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2025-06-19T09:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=09dac4c15121889e1017b896562fb4255bff7e03'/>
<id>urn:sha1:09dac4c15121889e1017b896562fb4255bff7e03</id>
<content type='text'>
commit a477629baa2a0e9991f640af418e8c973a1c08e3 upstream.

While nolibc-test does test syscalls, it doesn't test as much the rest
of the macros, and a wrong spelling of FD_SETBITMASK in commit
feaf75658783a broke programs using either FD_SET() or FD_CLR() without
being noticed. Let's fix these macros.

Fixes: feaf75658783a ("nolibc: fix fd_set type")
Cc: stable@vger.kernel.org # v6.2+
Acked-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: define time_t in terms of __kernel_old_time_t</title>
<updated>2025-08-28T14:25:53+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2025-07-12T09:00:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e52ec4dd28e6e9e5692c0ae3150821790f2a15b6'/>
<id>urn:sha1:e52ec4dd28e6e9e5692c0ae3150821790f2a15b6</id>
<content type='text'>
[ Upstream commit d5094bcb5bfdfea2cf0de8aaf77cc65db56cbdb5 ]

Nolibc assumes that the kernel ABI is using a time values that are as
large as a long integer. For most ABIs this holds true.
But for x32 this is not correct, as it uses 32bit longs but 64bit times.

Also the 'struct stat' implementation of nolibc relies on timespec::tv_sec
and time_t being the same type. While timespec::tv_sec comes from the
kernel and is of type __kernel_old_time_t, time_t is defined within nolibc.

Switch to the __kernel_old_time_t to always get the correct type.

Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://lore.kernel.org/r/20250712-nolibc-x32-v1-1-6d81cb798710@weissschuh.net
Acked-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc/stdlib: fix memory error in realloc()</title>
<updated>2024-06-12T09:02:56+00:00</updated>
<author>
<name>Brennan Xavier McManus</name>
<email>bxmcmanus@gmail.com</email>
</author>
<published>2024-01-09T23:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5996b2b2dac739f2a27da13de8eee5b85b2550b3'/>
<id>urn:sha1:5996b2b2dac739f2a27da13de8eee5b85b2550b3</id>
<content type='text'>
commit 791f4641142e2aced85de082e5783b4fb0b977c2 upstream.

Pass user_p_len to memcpy() instead of heap-&gt;len to prevent realloc()
from copying an extra sizeof(heap) bytes from beyond the allocated
region.

Signed-off-by: Brennan Xavier McManus &lt;bxmcmanus@gmail.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Ammar Faizi &lt;ammarfaizi2@gnuweeb.org&gt;
Fixes: 0e0ff638400be8f497a35b51a4751fd823f6bd6a ("tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()`")
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: prevent gcc from making memset() loop over itself</title>
<updated>2023-02-01T07:34:31+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-01-09T07:54:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=141fe35cb13e63aca9e6e2c1d81fed880db273a1'/>
<id>urn:sha1:141fe35cb13e63aca9e6e2c1d81fed880db273a1</id>
<content type='text'>
[ Upstream commit 1bfbe1f3e96720daf185f03d101f072d69753f88 ]

When building on ARM in thumb mode with gcc-11.3 at -O2 or -O3,
nolibc-test segfaults during the select() tests. It turns out that at
this level, gcc recognizes an opportunity for using memset() to zero
the fd_set, but it miscompiles it because it also recognizes a memset
pattern as well, and decides to call memset() from the memset() code:

  000122bc &lt;memset&gt;:
     122bc:       b510            push    {r4, lr}
     122be:       0004            movs    r4, r0
     122c0:       2a00            cmp     r2, #0
     122c2:       d003            beq.n   122cc &lt;memset+0x10&gt;
     122c4:       23ff            movs    r3, #255        ; 0xff
     122c6:       4019            ands    r1, r3
     122c8:       f7ff fff8       bl      122bc &lt;memset&gt;
     122cc:       0020            movs    r0, r4
     122ce:       bd10            pop     {r4, pc}

Simply placing an empty asm() statement inside the loop suffices to
avoid this.

Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: fix missing includes causing build issues at -O0</title>
<updated>2023-02-01T07:34:31+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-01-09T07:54:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f3b7893078ca1e6b17a0b2501544ed4f8d9f8ef8'/>
<id>urn:sha1:f3b7893078ca1e6b17a0b2501544ed4f8d9f8ef8</id>
<content type='text'>
[ Upstream commit 55abdd1f5e1e07418bf4a46c233a92f83cb5ae97 ]

After the nolibc includes were split to facilitate portability from
standard libcs, programs that include only what they need may miss
some symbols which are needed by libgcc. This is the case for raise()
which is needed by the divide by zero code in some architectures for
example.

Regardless, being able to include only the apparently needed files is
convenient.

Instead of trying to move all exported definitions to a single file,
since this can change over time, this patch takes another approach
consisting in including the nolibc header at the end of all standard
include files. This way their types and functions are already known
at the moment of inclusion, and including any single one of them is
sufficient to bring all the required ones.

Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: Fix S_ISxxx macros</title>
<updated>2023-02-01T07:34:31+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@bsdimp.com</email>
</author>
<published>2023-01-09T07:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=338ec07a14cd82d9962b9d5f8b7d599864747ccd'/>
<id>urn:sha1:338ec07a14cd82d9962b9d5f8b7d599864747ccd</id>
<content type='text'>
[ Upstream commit 16f5cea74179b5795af7ce359971f5128d10f80e ]

The mode field has the type encoded as an value in a field, not as a bit
mask. Mask the mode with S_IFMT instead of each type to test. Otherwise,
false positives are possible: eg S_ISDIR will return true for block
devices because S_IFDIR = 0040000 and S_IFBLK = 0060000 since mode is
masked with S_IFDIR instead of S_IFMT. These macros now match the
similar definitions in tools/include/uapi/linux/stat.h.

Signed-off-by: Warner Losh &lt;imp@bsdimp.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nolibc: fix fd_set type</title>
<updated>2023-02-01T07:34:30+00:00</updated>
<author>
<name>Sven Schnelle</name>
<email>svens@linux.ibm.com</email>
</author>
<published>2023-01-09T07:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=99dd3449279bcc15a69af734f7609bfce1ff1e1c'/>
<id>urn:sha1:99dd3449279bcc15a69af734f7609bfce1ff1e1c</id>
<content type='text'>
[ Upstream commit feaf75658783a919410f8c2039dbc24b6a29603d ]

The kernel uses unsigned long for the fd_set bitmap,
but nolibc use u32. This works fine on little endian
machines, but fails on big endian. Convert to unsigned
long to fix this.

Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/nolibc: fix the O_* fcntl/open macro definitions for riscv</title>
<updated>2023-01-18T10:58:27+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-01-09T07:54:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd57d5e5e28e8b51fea428ebc7780aecb46abd02'/>
<id>urn:sha1:cd57d5e5e28e8b51fea428ebc7780aecb46abd02</id>
<content type='text'>
[ Upstream commit 00b18da4089330196906b9fe075c581c17eb726c ]

When RISCV port was imported in 5.2, the O_* macros were taken with
their octal value and written as-is in hex, resulting in the getdents64()
to fail in nolibc-test.

Fixes: 582e84f7b779 ("tool headers nolibc: add RISCV support") #5.2
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
