Remove the internal_statvfs64.c and open code the implementation
on internal_statvfs.c. The alpha is now unrequired, the generic
implementation also handles it.
Also, remove unused includes on internal_statvfs.c, and remove
unused arguments on __internal_statvfs{64}.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
There is no need to handle ENOSYS on fstatfs64 call, required only
for alpha (where is already fallbacks to fstatfs).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
There is no need to handle ENOSYS on fstatfs64 call, required only
for alpha (where is already fallbacks to fstatfs). The wordsize
internal_statvfs64.c is removed, since how the LFS support is
provided by fstatvfs64.c (used on 64-bit architectures as well).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The __NR_statfs64 syscall is supported on all architectures but
aarch64, mips64, riscv64, and x86_64. And newer ABIs also uses
the new statfs64 interface (where the struct size is used as
second argument).
So the default implementation now uses:
1. __NR_statfs64 for non-LFS call and handle overflow directly
There is no need to handle __NR_statfs since all architectures
that only support are LFS only.
2. __NR_statfs if defined or __NR_statfs64 otherwise for LFS
call.
Alpha is the only outlier, since it is a 64-bit architecture which
provides non-LFS interface and only provides __NR_statfs64 on
newer kernels (v5.1+).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The __NR_fstatfs64 syscall is supported on all architectures but
aarch64, mips64, riscv64, and x86_64. And newer ABIs also uses
the new fstatfs64 interface (where the struct size is used as
first argument).
So the default implementation now uses:
1. __NR_fstatfs64 for non-LFS call and handle overflow directly
There is no need to handle __NR_fstatfs since all architectures
that only support are LFS only.
2. __NR_fstatfs if defined or __NR_fstatfs64 otherwise for LFS
call.
Alpha is the only outlier, it is a 64-bit architecture which
provides non-LFS interface and only provides __NR_fstatfs64 on
newer kernels (5.1+).
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Currently glibc has three different struct statfs{64} definitions:
1. Non-LFS support where non-LFS and LFS struct have different
size: alpha, arm, hppa, i686, m68k, microblaze, mips (all abis),
powerpc32, s390, sh4, and sparc.
2. Non-LFS support where non-LFS and LFS struct have the same
size: csky and nios2.
3. Only LFS support (where both struct have the same size): arc,
ia64, powerpc64 (including LE), riscv (both 32 and 64 bits),
s390x, sparc64, and x86 (including x32).
The STATFS_IS_STATFS64/__STATFS_MATCHES_STATFS64 does not tell apart
between 1. and 2. since for both the only difference is the struct
size (for 2. both non-LFS and LFS uses the same syscall, where for
1. the old non-LFS is used for [f]statfs).
This patch move the generic statfs.h for both csky and nios2, and
make the default definitions for newer ABIs to assume that only
LFS will be support (so there is no need to keep no-LFS and LFS
struct statfs with the same size, it will be implicit).
This patch does not change the code generation.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The XSTAT_IS_XSTAT64 and STAT_IS_KERNEL_STAT flags are now set to 1 and
STATFS_IS_STATFS64 is set to __STATFS_MATCHES_STATFS64. This makes the
default ABI for newer ports to provide only LFS calls.
A copy of non-LFS support is provided to 32-bit ABIS with non-LFS
support (arm, csky, i386, m68k, nios2, s390, and sh). Is also allows
to remove the 64-bit ports, which already uses the default values.
This patch does not change the code generation.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
aarch64, arc, ia64, mips64, powerpc64, riscv32, riscv64, s390x, sparc64,
and x86_64 defines STATFS_IS_STATFS64 to 0, but all of them alias
statfs to statfs64 and the struct statfs has the same and layout of
struct statfs64.
The correct definition will be used on the [f]statfs[64] consolidation.
This patch does not change code generation since the symbols are
implemented using the auto-generation syscall for all the aforementioned
ABIs.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The glibc.malloc.mmap_max tunable as well as al of the INT_32 tunables
don't have use for negative values, so pin the hardcoded limits in the
non-negative range of INT. There's no real benefit in any of those
use cases for the extended range of unsigned, so I have avoided added
a new type to keep things simple.
The TUNABLE_SET interface took a primitive C type argument, which
resulted in inconsistent type conversions internally due to incorrect
dereferencing of types, especialy on 32-bit architectures. This
change simplifies the TUNABLE setting logic along with the interfaces.
Now all numeric tunable values are stored as signed numbers in
tunable_num_t, which is intmax_t. All calls to set tunables cast the
input value to its primitive type and then to tunable_num_t for
storage. This relies on gcc-specific (although I suspect other
compilers woul also do the same) unsigned to signed integer conversion
semantics, i.e. the bit pattern is conserved. The reverse conversion
is guaranteed by the standard.
Add __nonnull((2)) to the setrlimit()/getrlimit() function declaration
to avoid null pointer access.
-----
v2
According to the suggestions of the Adhemerval Zanella and Zack Weinberg:
use __nonnull() to check null pointers in the compilation phase.
do not add pointer check code to setrlimit()/getrlimit().
The validity of the "resource" parameter is checked in the syscall.
v1
https://public-inbox.org/libc-alpha/20201230114131.47589-1-nixiaoming@huawei.com/
-----
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch updates json "bench-variant" attribute of "bench-memset.c"
to "default" so that the script "benchtests/scripts/plot_strings.py"
can generate a file "memset_time_default_linear.png".
Without this patch, the script "benchtests/scripts/plot_strings.py"
generates a file "memset_time__linear.png" which has inconsistent form
with "memcpy_time_default_linear.png" and
"memmove_time_default_linear.png".
It syncs with gnulib version 1731fef3d. On build_trtable prevent
inlining, so that it doesn't bloat the caller's stack and use auto
variables instead of alloca/malloc.
After these changes, build_trtable's total stack allocation is
only 20 KiB on a 64-bit machine, and this is less than glibc's 64
KiB cutoff so there's little point to using alloca to shrink it.
Checked on x86_64-linux-gnu.
It syncs with gnulib version a8bac4d49. The main changes are:
- Remove the usage of anonymous union within DYNARRAY_STRUCT.
- Use DYNARRAY_FREE instead of DYNARRAY_NAME (free) so that
Gnulib does not change 'free' to 'rpl_free'.
- Use __nonnull instead of __attribute__ ((nonnull ())).
- Use __attribute_maybe_unused__ instead of
__attribute__ ((unused, nonnull (1))).
- Use of _Noreturn instead of _attribute__ ((noreturn)).
The only difference with gnulib is:
--- glibc
+++ gnulib
@@ -18,6 +18,7 @@
#include <dynarray.h>
#include <stdio.h>
+#include <stdlib.h>
void
__libc_dynarray_at_failure (size_t size, size_t index)
@@ -27,7 +28,6 @@
__snprintf (buf, sizeof (buf), "Fatal glibc error: "
"array index %zu not less than array length %zu\n",
index, size);
- __libc_fatal (buf);
#else
abort ();
#endif
It seems a wrong sync from gnulib (the code is used on loader and
thus it requires __libc_fatal instead of abort).
Checked on x86_64-linux-gnu.
It adds __glibc_has_builtin, __glibc_has_extension, and
__attribute_maybe_unused__ alongsize with some fixes.
The differences are:
--- glibc
+++ gnulib
@@ -259,7 +259,9 @@
# define __attribute_const__ /* Ignore */
#endif
-#if __GNUC_PREREQ (2,7) || __glibc_has_attribute (__unused__)
+#if defined __STDC_VERSION__ && 201710L < __STDC_VERSION__
+# define __attribute_maybe_unused__ [[__maybe_unused__]]
+#elif __GNUC_PREREQ (2,7) || __glibc_has_attribute (__unused__)
# define __attribute_maybe_unused__ __attribute__ ((__unused__))
#else
# define __attribute_maybe_unused__ /* Ignore */
@@ -485,7 +487,7 @@
/* The #ifndef lets Gnulib avoid including these on non-glibc
platforms, where the includes typically do not exist. */
-#ifdef __GLIBC__
+#ifndef __WORDSIZE
# include <bits/wordsize.h>
# include <bits/long-double.h>
#endif
The [[__attribute_maybe_unused__]] attribute removal __ is due Joseph
questioning gcc support with -std=c2x or -std=gnu2x [1].
The _WORDSIZE replacement by __GLIBC__ is because it does not play
well with internal cdefs.h that also uses
__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI.
Checked on x86_64-linux-gnu.
[1] https://sourceware.org/pipermail/libc-alpha/2021-January/121600.html
Take in consideration the trailling NULL since sem_search uses
strcmp to compare entries.
Checked on x86_64-linux-gnu and powerpc-linux-gnu (where it triggered
a nptl/tst-sem7 regression).
Linux 5.10 adds PTRACE_PEEKMTETAGS and PTRACE_POKEMTETAGS for AArch64.
Adding those shows up that glibc is also missing PTRACE_SYSEMU and
PTRACE_SYSEMU_SINGLESTEP, for AArch64 (where they were added to Linux
in 5.3) and for PowerPC (where they were added in Linux 4.20); it
already has those two defines for x86. Add all those defines to
glibc's headers.
Tested with build-many-glibcs.py for aarch64-linux-gnu and
powerpc-linux-gnu.
No bug. Just seemed the performance could be improved a bit. Observed
and expected behavior are unchanged. Optimized body of main
loop. Updated page cross logic and optimized accordingly. Made a few
minor instruction selection modifications. No regressions in test
suite. Both test-strchrnul and test-strchr passed.
sem_open already returns EINVAL for input names larger than NAME_MAX,
so it can assume the largest name length with tfind.
Checked on x86_64-linux-gnu.
The internal semaphore list code is moved to a specific file,
sem_routine.c, and the internal usage is simplified to only two
functions (one to insert a new semaphore and one to remove it
from the internal list). There is no need to expose the
internal locking, neither how the semaphore mapping is implemented.
No functional or semantic change is expected, tested on
x86_64-linux-gnu.
Previously, glibc would pick an arbitrary tmpfs file system from
/proc/mounts if /dev/shm was not available. This could lead to
an unsuitable file system being picked for the backing storage for
shm_open, sem_open, and related functions.
This patch introduces a new function, __shm_get_name, which builds
the file name under the appropriate (now hard-coded) directory. It is
called from the various shm_* and sem_* function. Unlike the
SHM_GET_NAME macro it replaces, the callers handle the return values
and errno updates. shm-directory.c is moved directly into the posix
subdirectory because it can be implemented directly using POSIX
functionality. It resides in libc because it is needed by both
librt and nptl/htl.
In the sem_open implementation, tmpfname is initialized directly
from a string constant. This happens to remove one alloca call.
Checked on x86_64-linux-gnu.
This change adds new test to assess ppoll()'s timeout related
functionality (the struct pollfd does not provide valid fd to wait
for - just wait for timeout).
To be more specific - two use cases are checked:
- if ppoll() times out immediately when passed struct timespec has zero
values of tv_nsec and tv_sec.
- if ppoll() times out after timeout specified in passed argument
This change adds new test to assess functionality of timerfd_*
functions.
It creates new timer (operates on its file descriptor) and checks
if time before and after sleep is between expected values.
1. Add CPUID_INDEX_14_ECX_0 for CPUID leaf 0x14 to detect PTWRITE feature
in EBX of CPUID leaf 0x14 with ECX == 0.
2. Add PTWRITE detection to CPU feature tests.
3. Add 2 static CPU feature tests.
Before the change nss_database_check_reload_and_get() did not populate
the '*result' value when it returned success in a case of chroot
detection. This caused initgroups() to use garage pointer in the
following test (extracted from unbound):
```
int main() {
// load some NSS modules
struct passwd * pw = getpwnam("root");
chdir("/tmp");
chroot("/tmp");
chdir("/");
// access nsswitch.conf in a chroot
initgroups("root", 0);
}
```
Reviewed-by: DJ Delorie <dj@redhat.com>
The printf tests have no coverage for long double. Duplicate the
double tests so that we have some basic coverage.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This fixes a Gnulib test-argp-2.sh test failure on macOS and FreeBSD.
Reported by Jeffrey Walton <noloader@gmail.com> in
<https://lists.gnu.org/archive/html/bug-gnulib/2020-03/msg00085.html>.
* argp/argp-help.c (group_cmp): Remove third argument.
(hol_sibling_cluster_cmp, hol_cousin_cluster_cmp): New functions, based
upon hol_cluster_cmp.
(hol_cluster_cmp): Use hol_cousin_cluster_cmp.
(hol_entry_cmp): Rewritten to implement a total order.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* lib/argp-help.c (SKIPWS): Cast character to 'unsigned char' before passing it
to isspace().
(fill_in_uparams): Likewise for isalpha(), isalnum(), isdigit().
(canon_doc_option): Likewise for isspace(), isalnum().
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Patch by Eric Blake
<https://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg00287.html>.
* argp/argp-help.c (hol_entry_cmp): Don't use _tolower on values that are
not upper-case. Pass correct range to tolower.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* argp/argp-help.c (hol_append): Don't subtract pointers to
different arrays, as this can run afoul of -fcheck-pointer-bounds.
See the thread containing Bruno Haible's report in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00171.html
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The struct tag is actually entry (not ENTRY). The data member has
type void *, and it can point to binary data. Only the key member is
required to be a null-terminated string.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
It is effectively used, unexcept for pthread_cond_destroy, where we do
not want it; see bug 27304. The internal locks do not support a
process-shared mode.
This fixes commit dc6cfdc934 ("nptl:
Move pthread_cond_destroy implementation into libc").
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
After 04986243d1 ("Remove internal usage of extensible stat functions")
linking the __stat64 symbol in getaddrinfo for this test fails with the
below error:
[...] or1k-smh-linux-gnu/bin/ld: [...]/posix/tst-rfc3484.o: in function `gaiconf_reload':
[...]/sysdeps/posix/getaddrinfo.c:2136: undefined reference to `__stat64'
collect2: error: ld returned 1 exit status
This is because __stat64 is a local symbol, the test includes the
getaddrinfo directly and fails to link against the local symbol. Fix
this by setting up an alias to the global stat64 symbol name like is
done for other local symbol usage.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The shmmax expected value is tricky to check because kernel clamps it
to INT_MAX in two cases:
1. Compat symbols with IPC_64, i.e, 32-bit binaries running on 64-bit
kernels.
2. Default symbol without IPC_64 (defined as IPC_OLD within Linux) and
glibc always use IPC_64 for 32-bit ABIs (to support 64-bit time_t).
It means that 32-bit binaries running on 32-bit kernels will not see
shmmax being clamped.
And finding out whether the compat symbol is used would require checking
the underlying kernel against the current ABI. The shmall and shmmni
already provided enough coverage.
Checked on x86_64-linux-gnu and i686-linux-gnu. It should fix the
tst-sysvshm-linux failures on 32-bit kernels.
In the process of optimizing memcpy for AMD machines, we have found the
vector move operations are outperforming enhanced REP MOVSB for data
transfers above the L2 cache size on Zen3 architectures.
To handle this use case, we are adding an upper bound parameter on
enhanced REP MOVSB:'__x86_rep_movsb_stop_threshold'.
As per large-bench results, we are configuring this parameter to the
L2 cache size for AMD machines and applicable from Zen3 architecture
supporting the ERMS feature.
For architectures other than AMD, it is the computed value of
non-temporal threshold parameter.
Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com>
