devel June 2023

devel@uclibc-ng.org

5 participants
4 discussions

[PATCH] Fix exec-null test for newer kernels

by Yann Sionneau

From: Yann Sionneau <ysionneau(a)kalrayinc.com> Without this patch, since https://github.com/torvalds/linux/commit/dcd46d897adb70d63e025f175a00a89797… this test runs in infinite loop. Signed-off-by: Yann Sionneau <ysionneau(a)kalrayinc.com> --- test/unistd/exec-null.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/test/unistd/exec-null.c b/test/unistd/exec-null.c index 3df99f3..0f79b3d 100644 --- a/test/unistd/exec-null.c +++ b/test/unistd/exec-null.c @@ -4,7 +4,12 @@ int main(int argc, char *argv[]) { - if (argc == 0) + /* since Linux https://github.com/torvalds/linux/commit/dcd46d897adb70d63e025f175a00a89797… + * kernel forces an empty first arg if execve is called + * with argv == NULL. + * so we need to handle argc == 1 for newer kernel as well + */ + if (argc == 0 || argc == 1) return 0; char *exec_argv[1], *exec_envp[1]; -- 2.17.1

10 months, 2 weeks

[PATCH 1/2] Revert "librt: avoid compilation error"

by Yann Sionneau

This reverts commit 08d46f1ce21e4ec51b2b1626beeaea6cbe7fdc6b. Signed-off-by: Yann Sionneau <yann(a)sionneau.net> --- librt/clock_nanosleep.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/librt/clock_nanosleep.c b/librt/clock_nanosleep.c index 1515cf5b0..4cf1e06b4 100644 --- a/librt/clock_nanosleep.c +++ b/librt/clock_nanosleep.c @@ -36,9 +36,9 @@ clock_nanosleep (clockid_t clock_id, int flags, const struct timespec *req, if (clock_id == CLOCK_PROCESS_CPUTIME_ID) clock_id = MAKE_PROCESS_CPUCLOCK (0, CPUCLOCK_SCHED); -#if defined(SINGLE_THREAD_P) + if (SINGLE_THREAD_P) r = INTERNAL_SYSCALL (clock_nanosleep, err, 4, clock_id, flags, req, rem); -#else + else { int oldstate = LIBC_CANCEL_ASYNC (); @@ -47,7 +47,6 @@ clock_nanosleep (clockid_t clock_id, int flags, const struct timespec *req, LIBC_CANCEL_RESET (oldstate); } -#endif return (INTERNAL_SYSCALL_ERROR_P (r, err) ? INTERNAL_SYSCALL_ERRNO (r, err) : 0); -- 2.34.1

10 months, 2 weeks

Re: Revert request and discussion about "librt: avoid compilation error"

by Damien Le Moal

On 2023/06/07 23:57, Yann Sionneau wrote: > Hello uClibc-ng hackers, Damien, Rich, > > I am sending this email to discuss the possibility to revert > https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=08d46f1ce21e4e… > > I think this change is wrong, I have been tracking an issue for a few > days and I am pretty sure the issue comes from this commit. > > Basically what happens is that with this commit, tst-cancel18 test is > failing. > > The test is available over there: > https://github.com/wbx-github/uclibc-ng-test/blob/master/test/nptl/tst-canc… > > The reason for this fail is that clock_nanosleep code from libc is badly > compiled: > https://elixir.bootlin.com/uclibc-ng/latest/source/librt/clock_nanosleep.c#… > > Because SINGLE_THREAD_P is actually defined, in case your libc build > supports NPTL threads (which is, I think, the majority of configs, > except very old systems using LINUXTHREADS or NOMMU maybe). > > In my case (kvx arch): > > #define SINGLE_THREAD_P __builtin_expect (THREAD_GETMEM (THREAD_SELF, > header.multiple_threads) == 0, 1) > > See: > https://elixir.bootlin.com/uclibc-ng/latest/source/libpthread/nptl/sysdeps/… > > This results to clock_nanosleep code being compiled to a very simple > version that directly calls the syscall and does not change at all the > thread cancellability to asynchronous before calling the syscall. > > Therefore, when the test main thread calls pthread_cancel(), no signal > is sent (see > https://elixir.bootlin.com/uclibc-ng/latest/source/libpthread/nptl/pthread_…) > and therefore the nanosleep syscall is never interrupted and the test fails. > > clock_nanosleep is defined to be a mandatory cancellation point by > POSIX, it must be interruptible in all cases by pthread_cancel, whether > in synchronous or asynchronous mode. > > I think the fix for the NOMMU case should be different, maybe checking > for if LIBC_CANCEL_ASYNC is defined ? > > Damien do you have time to work on a new fix for the NOMMU case? Are you > OK with the revert? Not OK with a revert as that will bring back the compilation errors for RISC-V NOMMU case. Instead, please work on a fix for your case on top of the current code. If I recall correctly, the code around this is rather messy with lots of ifdefs, which may be why this regression was introduced. Cleaning up the code first to avoid that may help avoiding further issues in the future. Note that to test patches/regressions for risc-v NOMMU builds, you can simply use buildroot and run: make sipeed_maix_bit_defconfig make To check that it builds. > > Can someone confirm my analysis here? > > Thanks! > > Best regards, > -- Damien Le Moal Western Digital Research

10 months, 2 weeks

test

by Yann Sionneau

test

10 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel June 2023