March 2025 - Linux-kselftest-mirror

[PATCH] tools/nolibc: add support for openat(2)

by Louis Taylor

openat is useful to avoid needing to construct relative paths, so expose a wrapper for using it directly. Signed-off-by: Louis Taylor <louis(a)kragniz.eu> --- tools/include/nolibc/sys.h | 29 ++++++++++++++++++++ tools/testing/selftests/nolibc/nolibc-test.c | 22 +++++++++++++++ 2 files changed, 51 insertions(+) diff --git a/tools/include/nolibc/sys.h b/tools/include/nolibc/sys.h index 8f44c33b1213..e5ff34df4aee 100644 --- a/tools/include/nolibc/sys.h +++ b/tools/include/nolibc/sys.h @@ -765,6 +765,35 @@ int mount(const char *src, const char *tgt, return __sysret(sys_mount(src, tgt, fst, flags, data)); } +/* + * int openat(int dirfd, const char *path, int flags[, mode_t mode]); + */ + +static __attribute__((unused)) +int sys_openat(int dirfd, const char *path, int flags, mode_t mode) +{ +#ifdef __NR_openat + return my_syscall4(__NR_openat, dirfd, path, flags, mode); +#else + return __nolibc_enosys(__func__, dirfd, path, flags, mode); +#endif +} + +static __attribute__((unused)) +int openat(int dirfd, const char *path, int flags, ...) +{ + mode_t mode = 0; + + if (flags & O_CREAT) { + va_list args; + + va_start(args, flags); + mode = va_arg(args, int); + va_end(args); + } + + return __sysret(sys_openat(dirfd, path, flags, mode)); +} /* * int open(const char *path, int flags[, mode_t mode]); diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c index 79c3e6a845f3..97ded6c76f99 100644 --- a/tools/testing/selftests/nolibc/nolibc-test.c +++ b/tools/testing/selftests/nolibc/nolibc-test.c @@ -1028,6 +1028,26 @@ int test_rlimit(void) return 0; } +int test_openat(void) +{ + int dev; + int null; + + dev = openat(AT_FDCWD, "/dev", O_DIRECTORY); + if (dev < 0) + return -1; + + null = openat(dev, "null", 0); + if (null < 0) { + close(dev); + return -1; + } + + close(dev); + close(null); + + return 0; +} /* Run syscall tests between IDs <min> and <max>. * Return 0 on success, non-zero on failure. @@ -1116,6 +1136,8 @@ int run_syscall(int min, int max) CASE_TEST(mmap_munmap_good); EXPECT_SYSZR(1, test_mmap_munmap()); break; CASE_TEST(open_tty); EXPECT_SYSNE(1, tmp = open("/dev/null", 0), -1); if (tmp != -1) close(tmp); break; CASE_TEST(open_blah); EXPECT_SYSER(1, tmp = open("/proc/self/blah", 0), -1, ENOENT); if (tmp != -1) close(tmp); break; + CASE_TEST(openat_fdcwd); EXPECT_SYSNE(1, tmp = openat(AT_FDCWD, "/dev/null", 0), -1); if (tmp != -1) close(tmp); break; + CASE_TEST(openat_dir); EXPECT_SYSNE(1, test_openat(), -1); break; CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break; CASE_TEST(poll_null); EXPECT_SYSZR(1, poll(NULL, 0, 0)); break; CASE_TEST(poll_stdout); EXPECT_SYSNE(1, ({ struct pollfd fds = { 1, POLLOUT, 0}; poll(&fds, 1, 0); }), -1); break; -- 2.45.2

3 days, 4 hours

2
3
0 0

[PATCH 0/2] selftests/pidfd: Fix missing headers

by Siddharth Menon

Fix compilation errors caused by missing headers in the pidfd selftest. The errors include: pidfd_fdinfo_test.c:230:13: error: implicit declaration of function ‘mount’ pidfd_setns_test.c:172:54: error: implicit declaration of function ‘ioctl’ Siddharth Menon (2): selftests/pidfd: Fix missing header selftests/pidfd: Fix missing header tools/testing/selftests/pidfd/pidfd_fdinfo_test.c | 1 + tools/testing/selftests/pidfd/pidfd_setns_test.c | 1 + 2 files changed, 2 insertions(+) -- 2.48.1

3 days, 4 hours

2
3
0 0

CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup()

by Ben Hutchings

Hi all, CVE-2024-56741 is supposed to be fixed by commit 7290f5923191 "apparmor: test: Fix memory leak for aa_unpack_strdup()" but I think this assignment should be rejected. While a user-triggered memory leak may be exploitable for denial-of- service, the code that was fixed here is a part of KUnit tests. KUnit tests usually run a single time at boot, not under user control, and can then later be invoked through debugfs by the root user. Firstly, it is intended that the root user can deny service through the reboot system call, so I don't think additional ways to do this are security flaws. Secondly, the KUnit documentation at <https://docs.kernel.org/dev- tools/kunit/run_manual.html> says: Note: KUnit is not designed for use in a production system. It is possible that tests may reduce the stability or security of the system. so I don't think security issues in KUnit tests generally deserve CVE IDs. (That said, the help text for CONFIG_KUNIT does not have such a warning.) Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo.

3 days, 5 hours

2
1
0 0

[PATCH] selftests/dma: Fix bad array reference.

by Liu Ye

dir[directions] should be directions[dir] to correctly index the directions array. Signed-off-by: Liu Ye <liuye(a)kylinos.cn> --- tools/testing/selftests/dma/dma_map_benchmark.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c index b12f1f9babf8..b925756373ce 100644 --- a/tools/testing/selftests/dma/dma_map_benchmark.c +++ b/tools/testing/selftests/dma/dma_map_benchmark.c @@ -118,7 +118,7 @@ int main(int argc, char **argv) } printf("dma mapping benchmark: threads:%d seconds:%d node:%d dir:%s granule: %d\n", - threads, seconds, node, dir[directions], granule); + threads, seconds, node, directions[dir], granule); printf("average map latency(us):%.1f standard deviation:%.1f\n", map.avg_map_100ns/10.0, map.map_stddev/10.0); printf("average unmap latency(us):%.1f standard deviation:%.1f\n", -- 2.25.1

3 days, 10 hours

3
3
0 0

[PATCH 0/8] tracing: probes: Fixes and enhancing error logs

by Masami Hiramatsu (Google)

The following series fixes some bugs and adding some error messages which are not handled. This also add some selftests which tests the new error messages. Thank you, --- Masami Hiramatsu (Google) (8): tracing: tprobe-events: Fix a memory leak when tprobe with $retval tracing: tprobe-events: Reject invalid tracepoint name tracing: fprobe-events: Log error for exceeding the number of entry args tracing: probe-events: Log errro for exceeding the number of arguments tracing: probe-events: Remove unused MAX_ARG_BUF_LEN macro selftests/ftrace: Expand the tprobe event test to check wrong format selftests/ftrace: Add new syntax error test selftests/ftrace: Add dynamic events argument limitation test case kernel/trace/trace_eprobe.c | 2 + kernel/trace/trace_fprobe.c | 25 +++++++++++- kernel/trace/trace_kprobe.c | 5 ++ kernel/trace/trace_probe.h | 6 ++- kernel/trace/trace_uprobe.c | 9 +++- .../ftrace/test.d/dynevent/add_remove_tprobe.tc | 14 +++++++ .../ftrace/test.d/dynevent/dynevent_limitations.tc | 42 ++++++++++++++++++++ .../ftrace/test.d/dynevent/fprobe_syntax_errors.tc | 1 8 files changed, 98 insertions(+), 6 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/dynevent_limitations.tc -- Masami Hiramatsu (Google) <mhiramat(a)kernel.org>

3 days, 11 hours

4
19
0 0

[PATCH] selftests/nolibc: only run constructor tests on nolibc

by Thomas Weißschuh

The nolibc testsuite can be run against other libcs to test for interoperability. Some aspects of the constructor execution are not standardized and musl does not provide all tested feature, for one it does not provide arguments to the constructors, anymore? Skip the constructor tests on non-nolibc configurations. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- tools/testing/selftests/nolibc/nolibc-test.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c index 798fbdcd3ff8c36b514feb3fa1c7b8d7701cccd7..94db506eca906ff0ce8f518298dee34abf386484 100644 --- a/tools/testing/selftests/nolibc/nolibc-test.c +++ b/tools/testing/selftests/nolibc/nolibc-test.c @@ -738,9 +738,9 @@ int run_startup(int min, int max) CASE_TEST(environ_HOME); EXPECT_PTRNZ(1, getenv("HOME")); break; CASE_TEST(auxv_addr); EXPECT_PTRGT(test_auxv != (void *)-1, test_auxv, brk); break; CASE_TEST(auxv_AT_UID); EXPECT_EQ(1, getauxval(AT_UID), getuid()); break; - CASE_TEST(constructor); EXPECT_EQ(1, constructor_test_value, 2); break; + CASE_TEST(constructor); EXPECT_EQ(is_nolibc, constructor_test_value, 2); break; CASE_TEST(linkage_errno); EXPECT_PTREQ(1, linkage_test_errno_addr(), &errno); break; - CASE_TEST(linkage_constr); EXPECT_EQ(1, linkage_test_constructor_test_value, 6); break; + CASE_TEST(linkage_constr); EXPECT_EQ(is_nolibc, linkage_test_constructor_test_value, 6); break; case __LINE__: return ret; /* must be last */ /* note: do not set any defaults so as to permit holes above */ --- base-commit: 16681bea9a80080765c98b545ad74c17de2d513c change-id: 20250212-nolibc-test-constructor-42491ba71a19 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

3 days, 15 hours

2
6
0 0

[PATCH] kunit: constify return of string literals

by Christian Göttsche

From: Christian Göttsche <cgzones(a)googlemail.com> The function kunit_status_to_ok_not_ok() returns string literals, thus declare the return value as such. Reported by clang: ./include/kunit/test.h:143:10: warning: returning 'const char[3]' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] 143 | return "ok"; | ^~~~ ./include/kunit/test.h:145:10: warning: returning 'const char[7]' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] 145 | return "not ok"; | ^~~~~~~~ ./include/kunit/test.h:147:9: warning: returning 'const char[8]' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] 147 | return "invalid"; | ^~~~~~~~~ Signed-off-by: Christian Göttsche <cgzones(a)googlemail.com> --- include/kunit/test.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kunit/test.h b/include/kunit/test.h index 34b71e42fb10..ae1b57578476 100644 --- a/include/kunit/test.h +++ b/include/kunit/test.h @@ -135,7 +135,7 @@ struct kunit_case { struct string_stream *log; }; -static inline char *kunit_status_to_ok_not_ok(enum kunit_status status) +static inline const char *kunit_status_to_ok_not_ok(enum kunit_status status) { switch (status) { case KUNIT_SKIPPED: -- 2.45.2

3 days, 21 hours

2
1
0 0

[PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings

by Lorenzo Stoakes

The guard regions feature was initially implemented to support anonymous mappings only, excluding shmem. This was done such as to introduce the feature carefully and incrementally and to be conservative when considering the various caveats and corner cases that are applicable to file-backed mappings but not to anonymous ones. Now this feature has landed in 6.13, it is time to revisit this and to extend this functionality to file-backed and shmem mappings. In order to make this maximally useful, and since one may map file-backed mappings read-only (for instance ELF images), we also remove the restriction on read-only mappings and permit the establishment of guard regions in any non-hugetlb, non-mlock()'d mapping. It is permissible to permit the establishment of guard regions in read-only mappings because the guard regions only reduce access to the mapping, and when removed simply reinstate the existing attributes of the underlying VMA, meaning no access violations can occur. While the change in kernel code introduced in this series is small, the majority of the effort here is spent in extending the testing to assert that the feature works correctly across numerous file-backed mapping scenarios. Every single guard region self-test performed against anonymous memory (which is relevant and not anon-only) has now been updated to also be performed against shmem and a mapping of a file in the working directory. This confirms that all cases also function correctly for file-backed guard regions. In addition a number of other tests are added for specific file-backed mapping scenarios. There are a number of other concerns that one might have with regard to guard regions, addressed below: Readahead ~~~~~~~~~ Readahead is a process through which the page cache is populated on the assumption that sequential reads will occur, thus amortising I/O and, through a clever use of the PG_readahead folio flag establishing during major fault and checked upon minor fault, provides for asynchronous I/O to occur as dat is processed, reducing I/O stalls as data is faulted in. Guard regions do not alter this mechanism which operations at the folio and fault level, but do of course prevent the faulting of folios that would otherwise be mapped. In the instance of a major fault prior to a guard region, synchronous readahead will occur including populating folios in the page cache which the guard regions will, in the case of the mapping in question, prevent access to. In addition, if PG_readahead is placed in a folio that is now inaccessible, this will prevent asynchronous readahead from occurring as it would otherwise do. However, there are mechanisms for heuristically resetting this within readahead regardless, which will 'recover' correct readahead behaviour. Readahead presumes sequential data access, the presence of a guard region clearly indicates that, at least in the guard region, no such sequential access will occur, as it cannot occur there. So this should have very little impact on any real workload. The far more important point is as to whether readahead causes incorrect or inappropriate mapping of ranges disallowed by the presence of guard regions - this is not the case, as readahead does not 'pre-fault' memory in this fashion. At any rate, any mechanism which would attempt to do so would hit the usual page fault paths, which correctly handle PTE markers as with anonymous mappings. Fault-Around ~~~~~~~~~~~~ The fault-around logic, in a similar vein to readahead, attempts to improve efficiency with regard to file-backed memory mappings, however it differs in that it does not try to fetch folios into the page cache that are about to be accessed, but rather pre-maps a range of folios around the faulting address. Guard regions making use of PTE markers makes this relatively trivial, as this case is already handled - see filemap_map_folio_range() and filemap_map_order0_folio() - in both instances, the solution is to simply keep the established page table mappings and let the fault handler take care of PTE markers, as per the comment: /* * NOTE: If there're PTE markers, we'll leave them to be * handled in the specific fault path, and it'll prohibit * the fault-around logic. */ This works, as establishing guard regions results in page table mappings with PTE markers, and clearing them removes them. Truncation ~~~~~~~~~~ File truncation will not eliminate existing guard regions, as the truncation operation will ultimately zap the range via unmap_mapping_range(), which specifically excludes PTE markers. Zapping ~~~~~~~ Zapping is, as with anonymous mappings, handled by zap_nonpresent_ptes(), which specifically deals with guard entries, leaving them intact except in instances such as process teardown or munmap() where they need to be removed. Reclaim ~~~~~~~ When reclaim is performed on file-backed folios, it ultimately invokes try_to_unmap_one() via the rmap. If the folio is non-large, then map_pte() will ultimately abort the operation for the guard region mapping. If large, then check_pte() will determine that this is a non-device private entry/device-exclusive entry 'swap' PTE and thus abort the operation in that instance. Therefore, no odd things happen in the instance of reclaim being attempted upon a file-backed guard region. Hole Punching ~~~~~~~~~~~~~ This updates the page cache and ultimately invokes unmap_mapping_range(), which explicitly leaves PTE markers in place. Because the establishment of guard regions zapped any existing mappings to file-backed folios, once the guard regions are removed then the hole-punched region will be faulted in as usual and everything will behave as expected. Lorenzo Stoakes (4): mm: allow guard regions in file-backed and read-only mappings selftests/mm: rename guard-pages to guard-regions tools/selftests: expand all guard region tests to file-backed tools/selftests: add file/shmem-backed mapping guard region tests mm/madvise.c | 8 +- tools/testing/selftests/mm/.gitignore | 2 +- tools/testing/selftests/mm/Makefile | 2 +- .../mm/{guard-pages.c => guard-regions.c} | 921 ++++++++++++++++-- 4 files changed, 821 insertions(+), 112 deletions(-) rename tools/testing/selftests/mm/{guard-pages.c => guard-regions.c} (58%) -- 2.48.1

4 days, 4 hours

6
58
0 0

[PATCH 0/2] selftests/nolibc: add armthumb configuration

by Thomas Weißschuh

While nolibc does support ARM Thumb instructions, that support was not tested specifically. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Thomas Weißschuh (2): selftests/nolibc: explicitly enable ARM mode selftests/nolibc: add armthumb configuration tools/testing/selftests/nolibc/Makefile | 7 +++++++ tools/testing/selftests/nolibc/run-tests.sh | 5 +++-- 2 files changed, 10 insertions(+), 2 deletions(-) --- base-commit: 3bd53b2fa57d9472d3af63b3f4d26023ba07b579 change-id: 20250228-nolibc-armthumb-372963140267 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

4 days, 20 hours

2
3
0 0

[PATCH v2 0/4] tools/nolibc: MIPS: entrypoint cleanups and N32/N64 ABIs

by Thomas Weißschuh

Introduce support for the N32 and N64 ABIs. As preparation, the entrypoint is first simplified significantly. Thanks to Maciej for all the valuable information. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Clean up entrypoint first - Annotate #endifs - Link to v1: https://lore.kernel.org/r/20250212-nolibc-mips-n32-v1-1-6892e58d1321@weisss… --- Thomas Weißschuh (4): tools/nolibc: MIPS: drop $gp setup tools/nolibc: MIPS: drop manual stack pointer alignment tools/nolibc: MIPS: drop noreorder option tools/nolibc: MIPS: add support for N64 and N32 ABIs tools/include/nolibc/arch-mips.h | 117 +++++++++++++++++++++------- tools/testing/selftests/nolibc/Makefile | 28 ++++++- tools/testing/selftests/nolibc/run-tests.sh | 2 +- 3 files changed, 118 insertions(+), 29 deletions(-) --- base-commit: 9c812b01f13d37410ea103e00bc47e5e0f6d2bad change-id: 20231105-nolibc-mips-n32-234901bd910d Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

4 days, 21 hours

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror March 2025