No Bug. This commit updates the large memcpy case (no overlap). The
update is to perform memcpy on either 2 or 4 contiguous pages at
once. This 1) helps to alleviate the affects of false memory aliasing
when destination and source have a close 4k alignment and 2) In most
cases and for most DRAM units is a modestly more efficient access
pattern. These changes are a clear performance improvement for
VEC_SIZE =16/32, though more ambiguous for VEC_SIZE=64. test-memcpy,
test-memccpy, test-mempcpy, test-memmove, and tst-memmove-overflow all
pass.
Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com>
Some registers that can be clobbered by the kernel during a syscall are not
listed on the clobbers list in sysdeps/unix/sysv/linux/powerpc/sysdep.h.
For syscalls using sc:
- XER is zeroed by the kernel on exit
For syscalls using scv:
- XER is zeroed by the kernel on exit
- Different from the sc case, most CR fields can be clobbered (according to
the ELF ABI and the Linux kernel's syscall ABI for powerpc
(linux/Documentation/powerpc/syscall64-abi.rst)
The same should apply to vsyscalls, which effectively execute a function call
but are not currently adding these registers as clobbers either.
These are likely not causing issues today, but they should be added to the
clobbers list just in case things change on the kernel side in the future.
Reported-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Raphael M Zinsly <rzinsly@linux.ibm.com>
The syslog open the '/dev/console' for LOG_CONS without O_CLOEXEC,
which might leak in multithread programs that call fork.
Checked on x86_64-linux-gnu.
MSG_NOSIGNAL was added on POSIX 2008 and Hurd seems to support it.
The SIGPIPE handling also makes the implementation not thread-safe
(due the sigaction usage).
Checked on x86_64-linux-gnu.
The tst-wait4 is moved to common file and used for wait3
tests.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The test is also converted to use libsupport.
Checked on i686-linux-gnu and x86_64-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
It uses stat to compare against the values set by lutimes.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
It uses stat to compare against the values set by futimes.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Now that libsupport abstract Linux possible missing support (either
due FS limitation that can't handle 64 bit timestamp or architectures
that do not handle values larger than unsigned 32 bit values) the
tests can be turned generic.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also built the
tests for i686-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Lazy tlsdesc relocation is racy because the static tls optimization and
tlsdesc management operations are done without holding the dlopen lock.
This similar to the commit b7cf203b5c
for aarch64, but it fixes a different race: bug 27137.
On i386 the code is a bit more complicated than on x86_64 because both
rel and rela relocs are supported.
Lazy tlsdesc relocation is racy because the static tls optimization and
tlsdesc management operations are done without holding the dlopen lock.
This similar to the commit b7cf203b5c
for aarch64, but it fixes a different race: bug 27137.
Another issue is that ld auditing ignores DT_BIND_NOW and thus tries to
relocate tlsdesc lazily, but that does not work in a BIND_NOW module
due to missing DT_TLSDESC_PLT. Unconditionally relocating tlsdesc at
load time fixes this bug 27721 too.
map is not valid to access here because it can be freed by a concurrent
dlclose: during tls access (via __tls_get_addr) _dl_update_slotinfo is
called without holding dlopen locks. So don't check the modid of map.
The map == 0 and map != 0 code paths can be shared (avoiding the dtv
resize in case of map == 0 is just an optimization: larger dtv than
necessary would be fine too).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Since
commit a509eb117f
Avoid late dlopen failure due to scope, TLS slotinfo updates [BZ #25112]
the generation counter update is not needed in the failure path.
That commit ensures allocation in _dl_add_to_slotinfo happens before
the demarcation point in dlopen (it is called twice, first time is for
allocation only where dlopen can still be reverted on failure, then
second time actual dtv updates are done which then cannot fail).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The test dlopens a large number of modules with TLS, they are reused
from an existing test.
The test relies on the reuse of slotinfo entries after dlclose, without
bug 27135 fixed this needs a failing dlopen. With a slotinfo list that
has non-monotone increasing generation counters, bug 27136 can trigger.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The max modid is a valid index in the dtv, it should not be skipped.
The bug is observable if the last module has modid == 64 and its
generation is same or less than the max generation of the previous
modules. Then dtv[0].counter implies dtv[64] is initialized but
it isn't. Fixes bug 27136.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The value of PR_TAGGED_ADDR_ENABLE was incorrect in the installed
headers and the prctl command macros were missing that are needed
for it to be useful (PR_SET_TAGGED_ADDR_CTRL). Linux headers have
the definitions since 5.4 so it's widely available, we don't need
to repeat these definitions. The remaining definitions are from
Linux 5.10.
To build glibc with --enable-memory-tagging, Linux 5.4 headers and
binutils 2.33.1 or newer is needed.
Reviewed-by: DJ Delorie <dj@redhat.com>
Since Linux 4.13, kernel limits the maximum command line arguments
length to 6 MiB [1]. Normally the limit is still quarter of the maximum
stack size but if that limit exceeds 6 MiB it's clamped down.
glibc's __sysconf implementation for Linux platform is not aware of
this limitation and for stack sizes of over 24 MiB it returns higher
ARG_MAX than Linux will actually accept. This can be verified by
executing the following application on Linux 4.13 or newer:
#include <stdio.h>
#include <string.h>
#include <sys/resource.h>
#include <sys/time.h>
#include <unistd.h>
int main(void) {
const struct rlimit rlim = { 40 * 1024 * 1024,
40 * 1024 * 1024 };
if (setrlimit(RLIMIT_STACK, &rlim) < 0) {
perror("setrlimit: RLIMIT_STACK");
return 1;
}
printf("ARG_MAX : %8ld\n", sysconf(_SC_ARG_MAX));
printf("63 * 100 KiB: %8ld\n", 63L * 100 * 1024);
printf("6 MiB : %8ld\n", 6L * 1024 * 1024);
char str[100 * 1024], *argv[64], *envp[1];
memset(&str, 'A', sizeof str);
str[sizeof str - 1] = '\0';
for (size_t i = 0; i < sizeof argv / sizeof *argv - 1; ++i) {
argv[i] = str;
}
argv[sizeof argv / sizeof *argv - 1] = envp[0] = 0;
execve("/bin/true", argv, envp);
perror("execve");
return 1;
}
On affected systems the program will report ARG_MAX as 10 MiB but
despite that executing /bin/true with a bit over 6 MiB of command line
arguments will fail with E2BIG error. Expected result is that ARG_MAX
is reported as 6 MiB.
Update the __sysconf function to clamp ARG_MAX value to 6 MiB if it
would otherwise exceed it. This resolves bug #25305 which was market
WONTFIX as suggested solution was to cap ARG_MAX at 128 KiB.
As an aside and point of comparison, bionic (a libc implementation for
Android systems) decided to resolve this issue by always returning 128
KiB ignoring any potential xargs regressions [2].
On older kernels this results in returning overly conservative value
but that's a safer option than being aggressive and returning invalid
value on recent systems. It's also worth noting that at this point
all supported Linux releases have the 6 MiB barrier so only someone
running an unsupported kernel version would get incorrectly truncated
result.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
[1] See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da029c11e6b12f321f36dac8771e833b65cec962
[2] See baed51ee3a
POSIX states for syslog [1]:
"Values of the priority argument are formed by OR'ing together a
severity-level value and an optional facility value. If no
facility value is specified, the current default facility value is
used."
So the patch fixes an existing violation of the openlog interface contract
where it is ignoring the facility argument when the value is zero
It allows the use LOG_KERN by calling openlog prior syslog usage.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html
Cover key corner cases (e.g., whether errno is set) that are well
settled in glibc, fix some examples to avoid integer overflow, and
update some other dated examples (code needed for K&R C, e.g.).
* manual/charset.texi (Non-reentrant String Conversion):
* manual/filesys.texi (Symbolic Links):
* manual/memory.texi (Allocating Cleared Space):
* manual/socket.texi (Host Names):
* manual/string.texi (Concatenating Strings):
* manual/users.texi (Setting Groups):
Use reallocarray instead of realloc, to avoid integer overflow issues.
* manual/filesys.texi (Scanning Directory Content):
* manual/memory.texi (The GNU Allocator, Hooks for Malloc):
* manual/tunables.texi:
Use code font for 'malloc' instead of roman font.
(Symbolic Links): Don't assume readlink return value fits in 'int'.
* manual/memory.texi (Memory Allocation and C, Basic Allocation)
(Malloc Examples, Alloca Example):
* manual/stdio.texi (Formatted Output Functions):
* manual/string.texi (Concatenating Strings, Collation Functions):
Omit pointer casts that are needed only in ancient K&R C.
* manual/memory.texi (Basic Allocation):
Say that malloc sets errno on failure.
Say "convert" rather than "cast", since casts are no longer needed.
* manual/memory.texi (Basic Allocation):
* manual/string.texi (Concatenating Strings):
In examples, use C99 declarations after statements for brevity.
* manual/memory.texi (Malloc Examples): Add portability notes for
malloc (0), errno setting, and PTRDIFF_MAX.
(Changing Block Size): Say that realloc (p, 0) acts like
(p ? (free (p), NULL) : malloc (0)).
Add xreallocarray example, since other examples can use it.
Add portability notes for realloc (0, 0), realloc (p, 0),
PTRDIFF_MAX, and improve notes for reallocating to the same size.
(Allocating Cleared Space): Reword now-confusing discussion
about replacement, and xref "Replacing malloc".
* manual/stdio.texi (Formatted Output Functions):
Don't assume message size fits in 'int'.
* manual/string.texi (Concatenating Strings):
Fix undefined behavior involving arithmetic on a freed pointer.
The commit 2433d39b69, which added time64 support to select, changed
the function to use __NR_pselect6 (or __NR_pelect6_time64) on all
architectures. However, on architectures where the symbol was
implemented with __NR_select the kernel normalizes the passed timeout
instead of return EINVAL. For instance, the input timeval
{ 0, 5000000 } is interpreted as { 5, 0 }.
And as indicated by BZ #27651, this semantic seems to be expected
and changing it results in some performance issues (most likely
the program does not check the return code and keeps issuing
select with unormalized tv_usec argument).
To avoid a different semantic depending whether which syscall the
architecture used to issue, select now always normalize the timeout
input. This is a slight change for some ABIs (for instance aarch64).
Checked on x86_64-linux-gnu and i686-linux-gnu.
When parse_tunables tries to erase a tunable marked as SXID_ERASE for
setuid programs, it ends up setting the envvar string iterator
incorrectly, because of which it may parse the next tunable
incorrectly. Given that currently the implementation allows malformed
and unrecognized tunables pass through, it may even allow SXID_ERASE
tunables to go through.
This change revamps the SXID_ERASE implementation so that:
- Only valid tunables are written back to the tunestr string, because
of which children of SXID programs will only inherit a clean list of
identified tunables that are not SXID_ERASE.
- Unrecognized tunables get scrubbed off from the environment and
subsequently from the child environment.
- This has the side-effect that a tunable that is not identified by
the setxid binary, will not be passed on to a non-setxid child even
if the child could have identified that tunable. This may break
applications that expect this behaviour but expecting such tunables
to cross the SXID boundary is wrong.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Instead of passing GLIBC_TUNABLES via the environment, pass the
environment variable from parent to child. This allows us to test
multiple variables to ensure better coverage.
The test list currently only includes the case that's already being
tested. More tests will be added later.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Add a new function support_capture_subprogram_self_sgid that spawns an
sgid child of the running program with its own image and returns the
exit code of the child process. This functionality is used by at
least three tests in the testsuite at the moment, so it makes sense to
consolidate.
There is also a new function support_subprogram_wait which should
provide simple system() like functionality that does not set up file
actions. This is useful in cases where only the return code of the
spawned subprocess is interesting.
This patch also ports tst-secure-getenv to this new function. A
subsequent patch will port other tests. This also brings an important
change to tst-secure-getenv behaviour. Now instead of succeeding, the
test fails as UNSUPPORTED if it is unable to spawn a setgid child,
which is how it should have been in the first place.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
An incorrect check in __longjmp_chk could fail on valid code causing
FAIL: debug/tst-longjmp_chk2
The original check was
altstack_sp + altstack_size - setjmp_sp > altstack_size
i.e. sp at setjmp was outside of the altstack range. Here we know that
longjmp is called from a signal handler on the altstack (SS_ONSTACK),
and that it jumps in the wrong direction (sp decreases), so the check
wants to ensure the jump goes to another stack.
The check is wrong when altstack_sp == setjmp_sp which can happen
when the altstack is a local buffer in the function that calls setjmp,
so the patch allows == too. This fixes bug 27709.
Note that the generic __longjmp_chk check seems to be different.
(it checks if longjmp was on the altstack but does not check setjmp,
so it would not catch incorrect longjmp use within the signal handler).
