- devel - example.com

dlclose() issue
by Waldemar Brodkorb 15 Apr '18

15 Apr '18

Hi, I still having issues with dlclose(). Can anybody help me with this issue? This is a long standing bug and still not solved. Recently I reverted commit 952bb00f0b2eb576b0bf48c4f87018429a42e28d in commit 5bdc2b4dee516c8e4d7ba9f5d26c9bf31418b52f, because some Gentoo people reported issues with preparing stage1/stage2 images with this patch applied. The problem which was fixed by accident with this commit is segfaults in dlclose when running apache2 or php -m. But the munmap() calls where just wrong. Then I thought I found a real fix for the dlclose() segfaults in the old uClibc bugtracker https://bugs.busybox.net/show_bug.cgi?id=6158 I tested and pushed commit bf4c2d242f587700e3eb2ffd5721ddaf3cdbc7e5. But this change introduces a regression when running the uClibc-ng testsuite. When running testscope test, the test case fails, as the function registered via atexit(), is no longer available after dlclose() is executed. Why the dlclose() function is so extremely complex in uClibc and glibc? Musl seems to do nothing in dlclose() :/ Any help is really appreciated. best regards Waldemar

1 1

[PATCH] lseek.c: bugfix ltp lseek01.c
by Guo Ren 13 Apr '18

13 Apr '18

Ref the implement from the glibc and high=0 seems so bad. Signed-off-by: Guo Ren <ren_guo(a)c-sky.com> --- libc/sysdeps/linux/common/lseek.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libc/sysdeps/linux/common/lseek.c b/libc/sysdeps/linux/common/lseek.c index 33df822..80d6931 100644 --- a/libc/sysdeps/linux/common/lseek.c +++ b/libc/sysdeps/linux/common/lseek.c @@ -19,8 +19,9 @@ off_t __NC(lseek)(int fd, off_t offset, int whence) { #if __WORDSIZE == 32 __off64_t result; - __off_t high = 0; - return INLINE_SYSCALL(llseek, 5, fd, high, offset, &result, whence) ?: result; + return INLINE_SYSCALL(llseek, 5, fd, + (long) (((uint64_t) (offset)) >> 32), + (long) offset, &result, whence) ?: result; #else return lseek64(fd, offset, whence); #endif -- 2.7.4

2 1

[PATCH] common/sendfile.c: bugfix can't support offset is NULL
by Guo Ren 13 Apr '18

13 Apr '18

In ltp testcase sendfile08.c, it use offset=NULL to test the api. See "man sendfile" and it really support offset is NULL. Signed-off-by: Guo Ren <ren_guo(a)c-sky.com> --- libc/sysdeps/linux/common/sendfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libc/sysdeps/linux/common/sendfile.c b/libc/sysdeps/linux/common/sendfile.c index af05ba4..def98da 100644 --- a/libc/sysdeps/linux/common/sendfile.c +++ b/libc/sysdeps/linux/common/sendfile.c @@ -40,7 +40,7 @@ ssize_t sendfile(int out_fd, int in_fd, __off_t *offset, size_t count) return -1; } - if (offset == NULL || (int)offset < 0) { + if ((int)offset < 0) { __set_errno(EFAULT); return -1; } -- 2.7.4

2 1

[PATCH] or1k: add F_{DUPFD_CLOEXEC, SETPIPE_SZ, GETPIPE_SZ}
by Thomas Petazzoni 13 Apr '18

13 Apr '18

Those definitions exist on all other architectures, but were not present in or1k specific headers when or1k support was merged. On the kernel side, their support is completely architecture independent, so we just need those definitions to make those fcntl() calls available on or1k. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> --- libc/sysdeps/linux/or1k/bits/fcntl.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libc/sysdeps/linux/or1k/bits/fcntl.h b/libc/sysdeps/linux/or1k/bits/fcntl.h index bd6a8c511..a82ede424 100644 --- a/libc/sysdeps/linux/or1k/bits/fcntl.h +++ b/libc/sysdeps/linux/or1k/bits/fcntl.h @@ -102,6 +102,10 @@ # define F_SETLEASE 1024 /* Set a lease. */ # define F_GETLEASE 1025 /* Enquire what lease is active. */ # define F_NOTIFY 1026 /* Request notfications on a directory. */ +# define F_DUPFD_CLOEXEC 1030 /* Duplicate file descriptor with + close-on-exit set on new fd. */ +# define F_SETPIPE_SZ 1031 /* Set pipe page size array. */ +# define F_GETPIPE_SZ 1032 /* Get pipe page size array. */ #endif /* For F_[GET|SET]FL. */ -- 2.14.3

2 1

Re: [uclibc-ng-devel] compile uclibc with retpoline switch
by Waldemar Brodkorb 05 Apr '18

05 Apr '18

Hi, Ata, John (US) wrote, > Hi all, > > > > With Spectre variant 2 (CVE-2017-5715), gcc has been updated to avoid branch > prediction problems via the retpoline patch. Specifically, by using either – > mindirect-branch=thunk-inline or –mindirect-branch=thunk or –mindirect-branch- > thunk-external, the compiler will convert indirect branches and function > returns to call and return thunks thus avoiding speculative execution in those > cases. Of course, there is a performance penalty depending on the exact > argument used. Has anyone compiled uclibc with one of those switches? I didn't tried it, yet. You might be the first :) Any issues seen with that? best regards Waldemar

3 2

tst-atomic
by Alexey Brodkin 04 Apr '18

04 Apr '18

Hi Waldemar, I see in commit e65912f8b2a6 ("rework most tests to work as standalone package") "tst-atomic" and "tst-atomic-long" were marked as disabled for all architectures as opposed to previously (in times of test-suite being a part of uClibc) disabled only for selected arches (IA64, MIPS and SPARC). The only guess I have it was done due to inability to refer not-exported "atomic.h". Is that correct? But anyways I'm looking at a possibility to revive those as they might be of use especially in case of emulation of atomics. Any thoughts on how that could be done? -Alexey

2 2

compile uclibc with retpoline switch
by Ata, John (US) 02 Apr '18

02 Apr '18

Hi all, With Spectre variant 2 (CVE-2017-5715), gcc has been updated to avoid branch prediction problems via the retpoline patch. Specifically, by using either -mindirect-branch=thunk-inline or -mindirect-branch=thunk or -mindirect-branch-thunk-external, the compiler will convert indirect branches and function returns to call and return thunks thus avoiding speculative execution in those cases. Of course, there is a performance penalty depending on the exact argument used. Has anyone compiled uclibc with one of those switches? Take care, ---- John Ata, CISSP Senior Principal Software Engineer Electronics Systems STOP Operating System<http://www.baesystems.com/en-us/product/stop> Software Development T 703-563-8115 | F 703-668-4359 | john.ata(a)baesystems.com<mailto:john.ata@baesystems.com> http://www.baesystems.com/csp [cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330]<http://www.twitter.com/baesystemsinc>[cid:image004.png@01D138BC.8E54E330]<http://www.youtube.com/baesystemsinc>[cid:image006.png@01D138BC.8E54E330]<http://www.flickr.com/photos/baesystemsinc/>

1 0

memmove() broken by design for mips?
by Pieter Smith 29 Mar '18

29 Mar '18

It looks like memmove() is broken by design for mips. This has come up before in a previous thread, but with no proper resolution: https://mailman.uclibc-ng.org/pipermail/devel/2016-April/000837.html Per the man pages and posix specification, memmove() must work with overlapping regions: https://linux.die.net/man/3/memmove https://www.unix.com/man-page/POSIX/3posix/memmove/ Unless __ARCH_HAS_BWD_MEMCPY__ is set, the generic memmove() (which is used for mips) will use memcpy() when the destination pointer is lower than the source pointer, whether the regions are overlapping or not. The author of libc/string/mips/memcpy.S is clear about the fact that the mips implementation for memcpy() cannot deal with overlapping regions. For Android, support for overlapping regions seems to be required for memcpy(), so memcpy() will offload to memmove() when an overlap occurs. How this could work with memmove() again offloading to memcpy() on mips is lost on me. I am observing the problem on a big-endian mips 34kc with OpenSSL. We are using nginx as an https webserver with openssl as the ssl library. We observed unexpected Message Authentication Code failures when data was received. After some detective work, we were observing the uClibc memmove() occasionally copying a source buffer cache-line worth of zero's (32 bytes) to the destination buffer instead of the actual source data. Needless to say, I do not know of a cipher that plays nicely when the input buffer suffers from Alzheimer's. The OpenSSL implementation of the GCM-128 cipher rightfully fails the tag check from it's perspective, returning a Message Authentication Code failure to the client. I quick solution is to always define __ARCH_HAS_BWD_MEMCPY__ on mips, but I do not consider that a clear expression of the intent. Can anyone comment on this? - Pieter Smith

2 6

[PATCH 1/2] csky: del ARCH_HAS_DEPRECATED_SYSCALLS and vfork.S
by Guo Ren 29 Mar '18

29 Mar '18

For linux-csky upstream, I need remove them. Signed-off-by: Guo Ren <ren_guo(a)c-sky.com> --- extra/Configs/Config.csky | 1 - libc/sysdeps/linux/csky/Makefile.arch | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/extra/Configs/Config.csky b/extra/Configs/Config.csky index 3173ce9..f5dc683 100644 --- a/extra/Configs/Config.csky +++ b/extra/Configs/Config.csky @@ -6,7 +6,6 @@ config FORCE_OPTIONS_FOR_ARCH bool default y select ARCH_ANY_ENDIAN - select ARCH_HAS_DEPRECATED_SYSCALLS select ARCH_USE_MMU select ARCH_HAS_MMU diff --git a/libc/sysdeps/linux/csky/Makefile.arch b/libc/sysdeps/linux/csky/Makefile.arch index 704b36a..a3157c2 100644 --- a/libc/sysdeps/linux/csky/Makefile.arch +++ b/libc/sysdeps/linux/csky/Makefile.arch @@ -1,6 +1,6 @@ CSRC-y := clone.c __syscall_error.c cacheflush.c SSRC-y := __longjmp.S setjmp.S -SSRC-y += libc-read_tp.S vfork.S csky_clone.S +SSRC-y += libc-read_tp.S csky_clone.S -- 2.7.4

2 5

[pieter@boesman.nl: memmove() broken by design for mips?]
by Pieter Smith 27 Mar '18

27 Mar '18

It looks like memmove() is broken by design for mips. This has come up before in a previous thread, but with no proper resolution: https://mailman.uclibc-ng.org/pipermail/devel/2016-April/000837.html Per the man pages and posix specification, memmove() must work with overlapping regions: https://linux.die.net/man/3/memmove https://www.unix.com/man-page/POSIX/3posix/memmove/ Unless __ARCH_HAS_BWD_MEMCPY__ is set, the generic memmove() (which is used for mips) will use memcpy() when the destination pointer is lower than the source pointer, whether the regions are overlapping or not. The author of libc/string/mips/memcpy.S is clear about the fact that the mips implementation for memcpy() cannot deal with overlapping regions. For Android, support for overlapping regions seems to be required for memcpy(), so memcpy() will offload to memmove() when an overlap occurs. How this could work with memmove() again offloading to memcpy() on mips is lost on me. I am observing the problem on a big-endian mips 34kc with OpenSSL. We are using nginx as an https webserver with openssl as the ssl library. We observed unexpected Message Authentication Code failures when data was received. After some detective work, we were observing the uClibc memmove() occasionally copying a source buffer cache-line worth of zero's (32 bytes) to the destination buffer instead of the actual source data. Needless to say, I do not know of a cipher that plays nicely when the input buffer suffers from Alzheimer's. The OpenSSL implementation of the GCM-128 cipher rightfully fails the tag check from it's perspective, returning a Message Authentication Code failure to the client. I quick solution is to always define __ARCH_HAS_BWD_MEMCPY__ on mips, but I do not consider that a clear expression of the intent. Can anyone comment on this? - Pieter Smith

1 0