Noah Goldstein [Mon, 17 May 2021 17:56:52 +0000 (13:56 -0400)]
x86: Optimize memcmp-avx2-movbe.S
No bug. This commit optimizes memcmp-avx2.S. The optimizations include
adding a new vec compare path for small sizes, reorganizing the entry
control flow, and removing some unnecissary ALU instructions from the
main loop. test-memcmp and test-wmemcmp are both passing.
Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Noah Goldstein [Mon, 17 May 2021 17:56:17 +0000 (13:56 -0400)]
x86: Expand bench-memcmp.c and test-memcmp.c
No bug. This commit adds some additional performance test cases to
bench-memcmp.c and test-memcmp.c. The new benchtests include some
medium range sizes, as well as small sizes near page cross. The new
correctness tests correspond with the new benchtests though add some
additional cases for checking the page cross logic.
Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Joseph Myers [Tue, 18 May 2021 19:47:49 +0000 (19:47 +0000)]
Do not declare asctime_r and ctime_r for C2X
ISO C2X added the asctime_r, ctime_r, gmtime_r and localtime_r
functions from POSIX. It's now removed asctime_r and ctime_r again,
reflecting that they are marked obsolescent in POSIX; update glibc's
time.h accordingly.
The same change that removed those two functions from C2X also marked
asctime and ctime as deprecated (reflecting how POSIX shows them as
obsolescent), i.e. using the [[deprecated]] attribute in the
prototypes shown in C2X. It's less clear if we should explicitly
deprecate those functions like that in the glibc headers; this patch
does nothing regarding such a deprecation (there's no normative
requirement from C2X showing the functions as deprecated).
Stefan Liebler [Mon, 17 May 2021 14:19:36 +0000 (16:19 +0200)]
Fix stringop-overflow warning in bug-regex19.c.
Starting with commit 26492c0a14966c32c43cd6ca1d0dca5e62c6cfef
"Annotate additional APIs with GCC attribute access.",
gcc emits this warning on s390x:
In function 'do_one_test',
inlined from 'do_mb_tests' at bug-regex19.c:385:11:
bug-regex19.c:271:9: error: 're_search' specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
271 | res = re_search (®buf, test->string, strlen (test->string),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
272 | test->start, strlen (test->string) - test->start, NULL);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/regex.h:2,
from bug-regex19.c:22:
bug-regex19.c: In function 'do_mb_tests':
../posix/regex.h:554:17: note: in a call to function 're_search' declared with attribute 'read_only (2, 3)'
554 | extern regoff_t re_search (struct re_pattern_buffer *__buffer,
| ^~~~~~~~~
...
The function do_one_test is inlined into do_mb_tests on s390x (at least with
gcc 10). If do_one_test is marked with __attribute__ ((noinline)), there are
no warnings on s390x. If do_one_test is marked with
__attribute__ ((always_inline)), there are the same warnings on x86_64.
test->string points to a variable length array on stack of do_mb_tests
and the content is generated based on the passed test struct.
According to Martin Sebor, this is a false positive caused by the same bug as
the one in nss/makedb.c. It's fixed in GCC 11 and will also be available in
the next GCC 10.4 release.
elf/cache.c: Fix resource leaks identified by static analyzers
A coverity run identified a number of resource leaks in cache.c.
There are a couple of simple memory leaks where a local allocation is
not freed before function return. Then there is a mmap leak and a
file descriptor leak where a map is not unmapped in the error case and
a file descriptor remains open respectively.
Joseph Myers [Mon, 17 May 2021 20:55:21 +0000 (20:55 +0000)]
Add C2X timespec_getres
ISO C2X adds a timespec_getres function alongside the C11
timespec_get, with functionality similar to that of POSIX clock_getres
(including allowing a NULL pointer to be passed to the function).
Implement this function for glibc, similarly to the implementation of
timespec_get.
This includes a basic test like that of timespec_get, but no
documentation in the manual, given that TIME_UTC and timespec_get
aren't documented in the manual at all. The handling of 64-bit time
follows that in timespec_get; people maintaining patch series for
64-bit time will need to update them accordingly (to export
__timespec_getres64, redirect calls in time.h and run the test for
_TIME_BITS=64).
Tested for x86_64 and x86, and (previous version; only testcase
differs) with build-many-glibcs.py.
Andreas Schwab [Mon, 17 May 2021 12:00:19 +0000 (14:00 +0200)]
Missing ENOMEM in realloc_check wrapper (bug 27870)
When MALLOC_CHECK_ is non-zero, the realloc hook missed to set errno to
ENOMEM when called with too big size. Run the test tst-malloc-too-large
also with MALLOC_CHECK_=3 to catch that.
Matheus Castanho [Wed, 12 May 2021 14:27:16 +0000 (11:27 -0300)]
benchtests: Use JSON for bench-rawmemchr output
Convert the output of benchtests/bench-rawmemchr to JSON like other string
benchmarks. This makes the output more parseable and allows usage of
compare_strings.py, for example.
Reviewed-by: Lucas A. M. Magalhaes <lamm@linux.ibm.com>
Matheus Castanho [Tue, 11 May 2021 20:53:07 +0000 (17:53 -0300)]
powerpc: Add optimized rawmemchr for POWER10
Reuse code for optimized strlen to implement a faster version of rawmemchr.
This takes advantage of the same benefits provided by the strlen implementation,
but needs some extra steps. __strlen_power10 code should be unchanged after this
change.
rawmemchr returns a pointer to the char found, while strlen returns only the
length, so we have to take that into account when preparing the return value.
To quickly check 64B, the loop on __strlen_power10 merges the whole block into
16B by using unsigned minimum vector operations (vminub) and checks if there are
any \0 on the resulting vector. The same code is used by rawmemchr if the char c
is 0. However, this approach does not work when c != 0. We first need to
subtract each byte by c, so that the value we are looking for is converted to a
0, then taking the minimum and checking for nulls works again.
The new code branches after it has compared ~256 bytes and chooses which of the
two strategies above will be used in the main loop, based on the char c. This
extra branch adds some overhead (~5%) for length ~256, but is quickly amortized
by the faster loop for larger sizes.
Compared to __rawmemchr_power9, this version is ~20% faster for length < 256.
Because of the optimized main loop, the improvement becomes ~35% for c != 0
and ~50% for c = 0 for strings longer than 256.
Reviewed-by: Lucas A. M. Magalhaes <lamm@linux.ibm.com> Reviewed-by: Raphael M Zinsly <rzinsly@linux.ibm.com>
Florian Weimer [Mon, 17 May 2021 07:59:14 +0000 (09:59 +0200)]
nptl: Move pthread_getcpuclockid into libc
The symbol was moved using scripts/move-symbol-to-libc.py.
__libpthread_version_placeholder@@GLIBC_2.2 is needed by this change;
the Versions entry for GLIBC_2.2 in libpthread had leftover symbols
due to an error in a previous conflict resolution. The condition
for the placeholder symbol is complicated because some architectures
have earlier symbols at the GLIBC_2.2 symbol versions, so the
placeholder is not required there (yet).
Florian Weimer [Mon, 17 May 2021 07:59:14 +0000 (09:59 +0200)]
nptl: Move pthread_getattr_default_np into libc
The symbol was moved using scripts/move-symbol-to-libc.py.
A new placeholder symbol __libpthread_version_placeholder@GLIBC_2.18
is needed to keep the GLIBC_2.18 symbol version in libpthread.
The __pthread_getattr_default_np@@GLIBC_PRIVATE export is used
from pthread_create.
Florian Weimer [Mon, 17 May 2021 07:59:14 +0000 (09:59 +0200)]
elf: Partially initialize ld.so after static dlopen (bug 20802)
After static dlopen, a copy of ld.so is loaded into the inner
namespace, but that copy is not initialized at all. Some
architectures run into serious problems as result, which is why the
_dl_var_init mechanism was invented. With libpthread moving into
libc and parts into ld.so, more architectures impacted, so it makes
sense to switch to a generic mechanism which performs the partial
initialization.
As a result, getauxval now works after static dlopen (bug 20802).
Florian Weimer [Mon, 17 May 2021 07:59:14 +0000 (09:59 +0200)]
nptl: Move __nptl_create_event, __nptl_death_event into libc
In libthread_db, use the exported GLIBC_PRIVATE symbols directly
instead of relying on _thread_db_* variables in libpthread
(which used to be created by the DB_FUNCTION macros).
Florian Weimer [Mon, 17 May 2021 07:59:14 +0000 (09:59 +0200)]
nptl: Move __nptl_initial_report_events into ld.so/startup code
The initialization of the report_events TCB field is now performed
in __tls_init_tp instead of __pthread_initialize_minimal_internal
(in libpthread).
The events interface is difficult to test because GDB stopped using it
in 2015. The td_thr_get_info change to ignore lookup issues is enough
to support GDB with this change.
Martin Sebor [Sun, 16 May 2021 21:21:18 +0000 (15:21 -0600)]
Enable support for GCC 11 -Wmismatched-dealloc.
To help detect common kinds of memory (and other resource) management
bugs, GCC 11 adds support for the detection of mismatched calls to
allocation and deallocation functions. At each call site to a known
deallocation function GCC checks the set of allocation functions
the former can be paired with and, if the two don't match, issues
a -Wmismatched-dealloc warning (something similar happens in C++
for mismatched calls to new and delete). GCC also uses the same
mechanism to detect attempts to deallocate objects not allocated
by any allocation function (or pointers past the first byte into
allocated objects) by -Wfree-nonheap-object.
This support is enabled for built-in functions like malloc and free.
To extend it beyond those, GCC extends attribute malloc to designate
a deallocation function to which pointers returned from the allocation
function may be passed to deallocate the allocated objects. Another,
optional argument designates the positional argument to which
the pointer must be passed.
This change is the first step in enabling this extended support for
Glibc.
nptl: Fix tst-pthread-gdb-attach for ptrace_scope equal 1
This is similar to the fix for elf/tst-pldd (2f9046fb059e94fe25):
it checks ptrace_scope value (values higher than 2 are too restrictive
to allow the test to run) and it rearranges the spawned processes
to make the target process the gdb child.
Checked on x86_64-linux-gnu with ptrace_scope set to 1.
stdlib: Fix data race in __run_exit_handlers [BZ #27749]
Keep __exit_funcs_lock almost all the time and unlock it only to execute
callbacks. This fixed two issues.
1. f->func.cxa was modified outside the lock with rare data race like:
thread 0: __run_exit_handlers unlock __exit_funcs_lock
thread 1: __internal_atexit locks __exit_funcs_lock
thread 0: f->flavor = ef_free;
thread 1: sees ef_free and use it as new
thread 1: new->func.cxa.fn = (void (*) (void *, int)) func;
thread 1: new->func.cxa.arg = arg;
thread 1: new->flavor = ef_cxa;
thread 0: cxafct = f->func.cxa.fn; // it's wrong fn!
thread 0: cxafct (f->func.cxa.arg, status); // it's wrong arg!
thread 0: goto restart;
thread 0: call the same exit_function again as it's ef_cxa
2. Don't unlock in main while loop after *listp = cur->next. If *listp
is NULL and __exit_funcs_done is false another thread may fail in
__new_exitfn on assert (l != NULL):
thread 0: *listp = cur->next; // It can be the last: *listp = NULL.
thread 0: __libc_lock_unlock
thread 1: __libc_lock_lock in __on_exit
thread 1: __new_exitfn
thread 1: if (__exit_funcs_done) // false: thread 0 isn't there yet.
thread 1: l = *listp
thread 1: moves one and crashes on assert (l != NULL);
The test needs multiple iterations to consistently fail without the fix.
The error paths of __check_native would leave the socket FD open on
return, resulting in an FD leak. Rework function exit paths so that
the fd is always closed on return.
Romain GEISSLER [Wed, 12 May 2021 02:15:33 +0000 (07:45 +0530)]
Remove all usage of @BASH@ or ${BASH} in installed files, and hardcode /bin/bash instead
(FYI, this is a repost of
https://sourceware.org/pipermail/libc-alpha/2019-July/105035.html now
that FSF papers have been signed and confirmed on FSF side).
This trivial patch attemps to fix BZ 24106. Basically the bash locally
used when building glibc on the host shall not leak on the installed
glibc, as the system where it is installed might be different and use
another bash location.
So I have looked for all occurences of @BASH@ or $(BASH) in installed
files, and replaced it by /bin/bash. This was suggested by Florian
Weimer in the bug report.
Szabolcs Nagy [Thu, 31 Dec 2020 13:59:38 +0000 (13:59 +0000)]
elf: Fix DTV gap reuse logic [BZ #27135]
For some reason only dlopen failure caused dtv gaps to be reused.
It is possible that the intent was to never reuse modids for a
different module, but after dlopen failure all gaps are reused
not just the ones caused by the unfinished dlopened.
So the code has to handle reused modids already which seems to
work, however the data races at thread creation and tls access
(see bug 19329 and bug 27111) may be more severe if slots are
reused so this is scheduled after those fixes. I think fixing
the races are not simpler if reuse is disallowed and reuse has
other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are
removed from the middle of the slotinfo list. The value does
not have to be correct: incorrect true value causes the next
modid query to do a slotinfo walk, incorrect false will leave
gaps and new entries are added at the end.
Szabolcs Nagy [Tue, 13 Dec 2016 12:28:41 +0000 (12:28 +0000)]
elf: Add test case for [BZ #19329]
Test concurrent dlopen and pthread_create when the loaded modules have
TLS. This triggers dl-tls assertion failures more reliably than the
nptl/tst-stack4 test.
The dlopened module has 100 DT_NEEDED dependencies with TLS, they were
reused from an existing TLS test. The number of created threads during
dlopen depends on filesystem speed and hardware, but at most 3 threads
are alive at a time to limit resource usage.
Szabolcs Nagy [Wed, 30 Dec 2020 19:19:37 +0000 (19:19 +0000)]
elf: Use relaxed atomics for racy accesses [BZ #19329]
This is a follow up patch to the fix for bug 19329. This adds relaxed
MO atomics to accesses that were previously data races but are now
race conditions, and where relaxed MO is sufficient.
The race conditions all follow the pattern that the write is behind the
dlopen lock, but a read can happen concurrently (e.g. during tls access)
without holding the lock. For slotinfo entries the read value only
matters if it reads from a synchronized write in dlopen or dlclose,
otherwise the related dtv entry is not valid to access so it is fine
to leave it in an inconsistent state. The same applies for
GL(dl_tls_max_dtv_idx) and GL(dl_tls_generation), but there the
algorithm relies on the fact that the read of the last synchronized
write is an increasing value.
Szabolcs Nagy [Wed, 30 Dec 2020 19:19:37 +0000 (19:19 +0000)]
elf: Fix data races in pthread_create and TLS access [BZ #19329]
DTV setup at thread creation (_dl_allocate_tls_init) is changed
to take the dlopen lock, GL(dl_load_lock). Avoiding data races
here without locks would require design changes: the map that is
accessed for static TLS initialization here may be concurrently
freed by dlclose. That use after free may be solved by only
locking around static TLS setup or by ensuring dlclose does not
free modules with static TLS, however currently every link map
with TLS has to be accessed at least to see if it needs static
TLS. And even if that's solved, still a lot of atomics would be
needed to synchronize DTV related globals without a lock. So fix
both bug 19329 and bug 27111 with a lock that prevents DTV setup
running concurrently with dlopen or dlclose.
_dl_update_slotinfo at TLS access still does not use any locks
so CONCURRENCY NOTES are added to explain the synchronization.
The early exit from the slotinfo walk when max_modid is reached
is not strictly necessary, but does not hurt either.
An incorrect acquire load was removed from _dl_resize_dtv: it
did not synchronize with any release store or fence and
synchronization is now handled separately at thread creation
and TLS access time.
There are still a number of racy read accesses to globals that
will be changed to relaxed MO atomics in a followup patch. This
should not introduce regressions compared to existing behaviour
and avoid cluttering the main part of the fix.
Not all TLS access related data races got fixed here: there are
additional races at lazy tlsdesc relocations see bug 27137.
Florian Weimer [Tue, 11 May 2021 09:08:00 +0000 (11:08 +0200)]
nptl: Move stack cache management, __libpthread_freeres into libc
This replaces the FREE_P macro with the __nptl_stack_in_use inline
function. stack_list_del is renamed to __nptl_stack_list_del,
stack_list_add to __nptl_stack_list_add, __deallocate_stack to
__nptl_deallocate_stack, free_stacks to __nptl_free_stacks.
It is convenient to move __libpthread_freeres into libc at the
same time. This removes the temporary __default_pthread_attr_freeres
export and restores full freeres coverage for __default_pthread_attr.
Florian Weimer [Tue, 11 May 2021 09:08:00 +0000 (11:08 +0200)]
nptl: Move pthread_setattr_default_np into libc
The symbol was moved using scripts/move-symbol-to-libc.py.
The export of __default_pthread_attr_freeres is temporary. There
is a minor regression in freeres coverage because in the dynamic case,
__default_pthread_attr_freeres is no longer called if libpthread is
not linked in.
Paul Zimmermann [Mon, 3 May 2021 09:30:25 +0000 (11:30 +0200)]
add workload traces for cbrtl
These workload traces cover the whole "long double" range.
This patch was prepared with the help of Adhemerval Zanella. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Florian Weimer [Mon, 10 May 2021 08:31:41 +0000 (10:31 +0200)]
nptl: Move changing of stack permissions into ld.so
All the stack lists are now in _rtld_global, so it is possible
to change stack permissions directly from there, instead of
calling into libpthread to do the change.
Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Florian Weimer [Mon, 10 May 2021 08:31:41 +0000 (10:31 +0200)]
nptl: Move more stack management variables into _rtld_global
Permissions of the cached stacks may have to be updated if an object
is loaded that requires executable stacks, so the dynamic loader
needs to know about these cached stacks.
The move of in_flight_stack and stack_cache_actsize is a requirement for
merging __reclaim_stacks into the fork implementation in libc.
Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Florian Weimer [Mon, 10 May 2021 08:31:41 +0000 (10:31 +0200)]
Linux: Simplify and fix the definition of SINGLE_THREAD_P
Always use __libc_multiple_threads if beneficial, and do not assume
the the dynamic loader is single-threaded. This assumption could
become incorrect by accident once more code is moved from libpthread
into it. The previous commit introducing the
NO_SYSCALL_CANCEL_CHECKING macro enables this change.
Do not hint to the compiler that multi-threaded programs are unlikely
(which is not quite true anymore).
Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Florian Weimer [Mon, 10 May 2021 08:31:41 +0000 (10:31 +0200)]
Linux: Explicitly disable cancellation checking in the dynamic loader
Historically, SINGLE_THREAD_P is defined to 1 in the dynamic loader.
This has the side effect of disabling cancellation points. In order
to enable future use of SINGLE_THREAD_P for single-thread
optimizations in the dynamic loader (which becomes important once
more code is moved from libpthread), introduce a new
NO_SYSCALL_CANCEL_CHECKING macro which is always 1 for IS_IN (rtld),
indepdently of the actual SINGLE_THREAD_P value.
Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Florian Weimer [Mon, 10 May 2021 08:31:41 +0000 (10:31 +0200)]
elf, nptl: Resolve recursive lock implementation early
If libpthread is included in libc, it is not necessary to delay
initialization of the lock/unlock function pointers until libpthread
is loaded. This eliminates two unprotected function pointers
from _rtld_global and removes some initialization code from
libpthread.
Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Noah Goldstein [Tue, 4 May 2021 23:02:40 +0000 (19:02 -0400)]
x86: Add EVEX optimized memchr family not safe for RTM
No bug.
This commit adds a new implementation for EVEX memchr that is not safe
for RTM because it uses vzeroupper. The benefit is that by using
ymm0-ymm15 it can use vpcmpeq and vpternlogd in the 4x loop which is
faster than the RTM safe version which cannot use vpcmpeq because
there is no EVEX encoding for the instruction. All parts of the
implementation aside from the 4x loop are the same for the two
versions and the optimization is only relevant for large sizes.
powerpc64le: Fix ifunc selection for memset, memmove, bzero and bcopy
The hwcap2 check for the aforementioned functions should check for
both PPC_FEATURE2_ARCH_3_1 and PPC_FEATURE2_HAS_ISEL but was
mistakenly checking for any one of them, enabling isa 3.1 version of
the functions in incompatible processors, like POWER8.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
linux: Remove /proc/cpuinfo fallback on alpha and sparc
There is no much gain in fallback to cpuinfo if sysfs is no present,
usually on restricted environment neither will be present. It also
simplifies the code and make all architecture use the sched_getaffinity
as the sysfs fallback.
git://sourceware.org / glibc.git / log