Re: [uclibc-ng-devel] [PATCH] libpthread/nptl: bugfix malloc segfault in race conditions.

2018-01-15 Thread Waldemar Brodkorb
Hi Guo,
Guo Ren wrote,

> In libc/sysdeps/linux/common/bits/uClibc_pthread.h:
> extern void weak_function _pthread_cleanup_push_defer(...)
> 
> This *weak_function* declaration will cause nptl/cleanup_defer_compat.c:
> strong_alias (...) !!!FAIL!!!, because it include pthreadP.h->pthread.h
> ->uClibc_pthread.h
> 
> That means:
> Readelf -s libpthread/nptl/cleanup_defer_compat.o you will get:
> 18:    198 FUNCWEAK   DEFAULT1 _pthread_cleanup_push_def
> Readelf -s libc/misc/internals/__uClibc_main.o you will also get:
> 32: 003858 FUNCWEAK   DEFAULT1 _pthread_cleanup_push_def
> 
> Final: gcc malloc_pthread_test.c -lpthread
> The libc/stdlib/malloc-standard/malloc.c:839 (__MALLOC_LOCK->
> _pthread_cleanup_push_def) will use the one in __uClibc_main.o
> !!!not in cleanup_defer_compat.o!!!, becasue two cleanup_defer_compat in
> libc.a with the same weak declarations and the __uClibc_main.o is close
> to front.
> 
> 
> 
> All of malloc/free will failed in muti-threads' race conditions
> probabilistic.
> 
> As it happens, uClibc-0.9.33.2 is OK, Becasue:
> It's seperated in libpthread.a and libc.a, and the libc.a is the
> last lib for ld internal-cmd, and malloc will get right cleanup_defer_compat
> from libpthread.a.
> 
> This BUG is from 2016-09-24 to now:
> >>>
> commit 29ff9055c80efe77a7130767a9fcb3ab8c67e8ce
> Author: Waldemar Brodkorb 
> Date:   Sat Sep 24 02:55:31 2016 +0200
> 
> use a single libc and deduplicate threading code
> 
> Similar to musl libc a single libc has many benefits and solves
> some open issues with uClibc-ng.
> 
> - no pthread_mutex_* weak symbols exported anymore
> - applications no longer failing to link when either
>   -lrt or -lpthread are missing for dynamic and static linking mode
> - smaller C library
> - slightly better runtime performance
> <<<
> 
> Perharps we need carefully check all of the impact about that commit.

Yes, you are right. There might be more sharp edges.

Thanks for the fix, applied and pushed,
 Waldemar

___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel


Re: [uclibc-ng-devel] [PATCH v2] xtensa: fix strcmp

2018-01-15 Thread Waldemar Brodkorb
Hi Max,
Max Filippov wrote,

> Loops with 'loop forever' annotation inside strcmp are actually meant to
> loop forever. Falling through the end of the first loop may result in
> equal strings being compared unequal, e.g.:
> 
>   #include 
> 
>   int main(void)
>   {
>   char a[4096] __attribute__((aligned(4)));
>   char b[4096] __attribute__((aligned(4)));
> 
>   memset(a, ' ', 258 * 8);
>   memset(b, ' ', 258 * 8);
>   a[255 * 8] = 0;
>   a[256 * 8] = 'a';
>   b[255 * 8] = 0;
>   b[256 * 8] = 'b';
>   return !(strcmp(a, b) == 0);
>   }
> 
> Falling through the end of the second loop may result in unequal strings
> being compared as equal, e.g.:
> 
>   #include 
> 
>   int main(void)
>   {
>   char a[4096] __attribute__((aligned(4)));
>   char b[4096] __attribute__((aligned(4)));
> 
>   memset(a, ' ', 514 * 6);
>   memset(b, ' ', 514 * 6);
>   a[514 * 6 + 0] = 'a';
>   a[514 * 6 + 1] = 0;
>   b[514 * 6 + 0] = 'b';
>   b[514 * 6 + 1] = 0;
>   return !(strcmp(a, b) != 0);
>   }
> 
> Use 0 as a loop counter to make 2^32 - 1 iterations which is enough to
> cover all addressable memory. While at it drop useless nop at the end of
> the first loop and use a11 for all loop counters.
> 
> Signed-off-by: Max Filippov 
> ---
> Changes v1->v2:
> - wrong test case for the second loop, fixed.
> 

Applied and pushed,
 thx
  Waldemar
___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel


Re: [uclibc-ng-devel] [PATCH 0/4] Use varargs for common syscall() implementation

2018-01-15 Thread Waldemar Brodkorb
Hi Stafford,
Stafford Horne wrote,

> Hello,
> 
> This is a followup to the ("f764bcffe" or1k: syscall: Pass arguments on the
> stack) patch which fixes the issue where the definition of syscall() in 
> unistd.h
> and the common implementation in uclibc-ng don't match.
> 
> This series allows the implementation to match the definition and then goes on
> to remove generic implementations used by or1k, nds32 and arc.

Finally applied and pushed the or1k and nds32 patches. Arc patches
are dropped as suggested by Vineet. The nds32 patchset was fixed up
a little before pushing. No regressions found by running the
uClibc-ng testsuite.

Thanks a lot,
 Waldemar
___
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel