about summary refs log tree commit diff
path: root/sysdeps
Commit message (Collapse)AuthorAgeFilesLines
* Use __nonnull for the epoll_wait(2) family of syscallsAlejandro Colomar2023-06-011-4/+4
| | | | | Signed-off-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Fix invalid use of NULL in epoll_pwait2(2) testAlejandro Colomar2023-06-011-1/+3
| | | | | | | | | epoll_pwait2(2)'s second argument should be nonnull. We're going to add __nonnull to the prototype, so let's fix the test accordingly. We can use a dummy variable to avoid passing NULL. Reported-by: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* getipv4sourcefilter: Get rid of allocaJoe Simmons-Talbott2023-06-011-17/+7
| | | | | | Use a scratch_buffer rather than alloca to avoid potential stack overflows. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* getsourcefilter: Get rid of alloca.Joe Simmons-Talbott2023-06-011-17/+7
| | | | | | Use a scratch_buffer rather than alloca to avoid potential stack overflows. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* tests: fix warn unused resultsFrédéric Bérat2023-06-012-3/+9
| | | | | | With fortification enabled, few function calls return result need to be checked, has they get the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* tests: replace write by xwriteFrédéric Bérat2023-06-017-11/+19
| | | | | | | Using write without cheks leads to warn unused result when __wur is enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* x86-64: Use YMM registers in memcmpeq-evex.SH.J. Lu2023-06-011-1/+1
| | | | | | | Since the assembly source file with -evex suffix should use YMM registers, not ZMM registers, include x86-evex256-vecs.h by default to use YMM registers in memcmpeq-evex.S Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* io: Fix F_GETLK, F_SETLK, and F_SETLKW for powerpc64Adhemerval Zanella2023-05-311-0/+6
| | | | | | | | | | | | | | | | | | Different than other 64 bit architectures, powerpc64 defines the LFS POSIX lock constants with values similar to 32 ABI, which are meant to be used with fcntl64 syscall. Since powerpc64 kABI does not have fcntl, the constants are adjusted with the FCNTL_ADJUST_CMD macro. The 4d0fe291aed3a476a changed the logic of generic constants LFS value are equal to the default values; which is now wrong for powerpc64. Fix the value by explicit define the previous glibc constants (powerpc64 does not need to use the 32 kABI value, but it simplifies the FCNTL_ADJUST_CMD which should be kept as compatibility). Checked on powerpc64-linux-gnu and powerpc-linux-gnu.
* Fix misspellings in sysdeps/ -- BZ 25337Paul Pluzhnikov2023-05-30153-214/+214
|
* io: Fix record locking contants on 32 bit arch with 64 bit default time_t ↵Adhemerval Zanella2023-05-301-1/+1
| | | | | | | | | | | | | | | | | | (BZ#30477) For architecture with default 64 bit time_t support, the kernel does not provide LFS and non-LFS values for F_GETLK, F_GETLK, and F_GETLK (the default value used for 64 bit architecture are used). This is might be considered an ABI break, but the currenct exported values is bogus anyway. The POSIX lockf is not affected since it is aliased to lockf64, which already uses the LFS values. Checked on i686-linux-gnu and the new tests on a riscv32. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* LoongArch: Fix inconsistency in SHMLBA macro values between glibc and kernelcaiyinyu2023-05-301-0/+24
| | | | | | | | | The LoongArch glibc was using the value of the SHMLBA macro from common code, which is __getpagesize() (16k), but this was inconsistent with the value of the SHMLBA macro in the kernel, which is SZ_64K (64k). This caused several shmat-related tests in LTP (Linux Test Project) to fail. This commit fixes the issue by ensuring that the glibc's SHMLBA macro value matches the value used in the kernel like other architectures.
* riscv: Add the clone3 wrapperAdhemerval Zanella2023-05-292-0/+80
| | | | | | | | | | | It follows the internal signature: extern int clone3 (struct clone_args *__cl_args, size_t __size, int (*__func) (void *__arg), void *__arg); Checked on riscv64-linux-gnu-rv64imafdc-lp64d. Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
* posix: Add error message for EAI_OVERFLOWDridi Boukelmoune2023-05-291-0/+1
| | | | | Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com> Reviewed-by: Arjun Shankar <arjun@redhat.com>
* setsourcefilter: Replace alloca with a scratch_buffer.Joe Simmons-Talbott2023-05-291-20/+7
| | | | | | | | Use a scratch_buffer rather than either alloca or malloc to reduce the possibility of a stack overflow. Suggested-by: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86: Use 64MB as nt-store threshold if no cacheinfo [BZ #30429]Noah Goldstein2023-05-271-1/+9
| | | | | | | | | | | | If `non_temporal_threshold` is below `minimum_non_temporal_threshold`, it almost certainly means we failed to read the systems cache info. In this case, rather than defaulting the minimum correct value, we should default to a value that gets at least reasonable performance. 64MB is chosen conservatively to be at the very high end. This should never cause non-temporal stores when, if we had read cache info, we wouldn't have otherwise. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* hurd: Fix setting up signal thread stack alignmentSamuel Thibault2023-05-281-7/+5
| | | | | x86_64 needs special alignment when calling functions, so we have to use MACHINE_THREAD_STATE_SETUP_CALL for the signal thread when forking.
* Add MFD_NOEXEC_SEAL, MFD_EXEC from Linux 6.3 to bits/mman-shared.hJoseph Myers2023-05-261-0/+4
| | | | | | | | | Linux 6.3 adds new constants MFD_NOEXEC_SEAL and MFD_EXEC. Add these to bits/mman-shared.h (conditional on MFD_NOEXEC_SEAL not already being defined, similar to the existing conditional on the older MFD_* macros). Tested for x86_64.
* Add IP_LOCAL_PORT_RANGE from Linux 6.3 to bits/in.hJoseph Myers2023-05-261-0/+1
| | | | | | | Linux 6.3 adds a new constant IP_LOCAL_PORT_RANGE. Add it to the corresponding bits/in.h in glibc. Tested for x86_64.
* setipv4sourcefilter: Avoid using alloca.Joe Simmons-Talbott2023-05-261-17/+7
| | | | | | | Use a scratch_buffer rather than alloca/malloc to avoid potential stack overflow. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* sysdeps/pthread/eintr.c: fix warn unused resultFrédéric Bérat2023-05-241-2/+4
| | | | | | | Fix unused result warnings, detected when _FORTIFY_SOURCE is enabled in glibc. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Regenerate configure fragment -- BZ 25337.Paul Pluzhnikov2023-05-231-1/+1
| | | | | | | In commit 0b25c28e028b63c95108c442d8112811107e4c13 I updated congure.ac but neglected to regenerate updated configure. Fix this here.
* Fix misspellings in sysdeps/powerpc -- BZ 25337Paul Pluzhnikov2023-05-2323-34/+34
| | | | | | | All fixes are in comments, so the binaries should be identical before/after this commit, but I can't verify this. Reviewed-by: Rajalakshmi Srinivasaraghavan <rajis@linux.ibm.com>
* Fix misspellings in sysdeps/unix -- BZ 25337Paul Pluzhnikov2023-05-2369-87/+87
| | | | | | | Applying this commit results in bit-identical rebuild of libc.so.6 math/libm.so.6 elf/ld-linux-x86-64.so.2 mathvec/libmvec.so.1 Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Fix misspellings in sysdeps/x86_64 -- BZ 25337.Paul Pluzhnikov2023-05-2337-105/+105
| | | | | | | Applying this commit results in bit-identical rebuild of libc.so.6 math/libm.so.6 elf/ld-linux-x86-64.so.2 mathvec/libmvec.so.1 Reviewed-by: Florian Weimer <fweimer@redhat.com>
* mach: Fix accessing mach_i386.hSamuel Thibault2023-05-234-4/+8
| | | | Fixes: 196358ae26aa ("mach: Fix installing mach_i386.h")
* Fix misspellings in sysdeps/x86_64/fpu/multiarch -- BZ 25337.Paul Pluzhnikov2023-05-23112-169/+169
| | | | | | | Applying this commit results in a bit-identical rebuild of mathvec/libmvec.so.1 (which is the only binary that gets rebuilt). Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* mach: Fix installing mach_i386.hSamuel Thibault2023-05-232-2/+2
| | | | | | We do not want mach_i386.h to get installed into machine/, but into i386/ or x86_64/ depending where mach_i386.defs was found, i.e. according to 32/64 bitness.
* hurd: Fix making ld.so run static binaries with retrySamuel Thibault2023-05-231-1/+1
| | | | We need O_EXEC for __rtld_execve
* Add voice-admit DSCP code point from RFC-5865Ronan Pigott2023-05-221-0/+5
|
* Remove last remnants of have-protectedAndreas Schwab2023-05-223-9/+1
|
* S390: Use compile-only instead of also link-tests in configure.Stefan Liebler2023-05-222-177/+109
| | | | | | | | | | | | | | | | | Some of the s390-specific configure checks are using compile and link configure tests. Now use only compile tests as the link tests fails when e.g. bootstrapping a cross-toolchain due to missing crt-files/libc.so. This is achieved by using AC_COMPILE_IFELSE in configure.ac file. This is observable e.g. when using buildroot which builds glibc only once or the build-many-glibcs.py script. Note that the latter one is building glibc twice in the compilers-step (configure-checks fails) and in the glibcs-step (configure-checks succeed). Note, that the s390 specific configure tests for static PIE have to link an executable to test binutils support. Thus we can't fix those tests.
* htl: Use __hurd_fail () instead of assigning errnoSergey Bugaev2023-05-204-18/+9
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230520115531.3911877-2-bugaevc@gmail.com>
* hurd: Use __hurd_fail () instead of assigning errnoSergey Bugaev2023-05-2044-242/+95
| | | | | | | | | | | | | | The __hurd_fail () inline function is the dedicated, idiomatic way of reporting errors in the Hurd part of glibc. Not only is it more concise than '{ errno = err; return -1; }', it is since commit 6639cc10029e24e06b34e169712b21c31b8cf213 "hurd: Mark error functions as __COLD" marked with the cold attribute, telling the compiler that this codepath is unlikely to be executed. In one case, use __hurd_dfail () over the plain __hurd_fail (). Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230520115531.3911877-1-bugaevc@gmail.com>
* powerpc:GCC(<10) doesn't allow -mlong-double-64 after -mabi=ieeelongdoubleMahesh Bodapati2023-05-191-0/+17
| | | | | Removed -mabi=ieeelongdouble on failing tests. It resolves the error. error: ‘-mabi=ieeelongdouble’ requires ‘-mlong-double-128’
* hurd: Fix using interposable hurd_thread_selfSergey Bugaev2023-05-194-4/+10
| | | | | | | | | | | | Create a private hidden __hurd_thread_self alias, and use that one. Fixes 2f8ecb58a59eb82c43214d000842d99644a662d1 "hurd: Fix x86_64 _hurd_tls_fork" and c7fcce38c83a2bb665ef5dc4981bf20c7e586123 "hurd: Make sure to not use tcb->self" Reported-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Fix __TIMESIZE on x86_64Sergey Bugaev2023-05-192-1/+5
| | | | | | | We had sizeof (time_t) == 8, but __TIMESIZE == 32. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230519171516.3698754-1-bugaevc@gmail.com>
* hurd: Fix expected c++ typesSamuel Thibault2023-05-191-19/+19
| | | | | 90604f670c10 ("hurd 64bit: Add data for check-c++-types") actually added the 32bit version. This fixes it into a 64bit version.
* Add HWCAP2_SME* from Linux 6.3 to AArch64 bits/hwcap.hJoseph Myers2023-05-181-0/+6
| | | | | | | Linux 6.3 adds six HWCAP2_SME* constants for AArch64; add them to the corresponding bits/hwcap.h in glibc. Tested with build-many-glibcs.py for aarch64-linux-gnu.
* hurd: Also make it possible to call strlen very earlySergey Bugaev2023-05-171-0/+3
| | | | | | | | | | | | strlen, which is another ifunc-selected function, is invoked during early static executable startup if the argv arrives from the exec server. Make it not crash. Checked on x86_64-gnu: statically linked executables launched after the exec server is up now start up successfully. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-10-bugaevc@gmail.com>
* hurd: Fix setting up pthreadsSergey Bugaev2023-05-172-1/+94
| | | | | | | | | | | | | | | | | | | | On x86_64, we have to pass function arguments in registers, not on the stack. We also have to align the stack pointer in a specific way. Since sharing the logic with i386 does not bring much benefit, split the file back into i386- and x86_64-specific versions, and fix the x86_64 version to set up the thread properly. Bonus: i386 keeps doing the extra RPC inside __thread_set_pcsptp to fetch the state of the thread before setting it; but x86_64 no lnoger does that. Checked on x86_64-gnu and i686-gnu. Fixes be6d002ca277ffc90058d382396150cb0e785b9c "hurd: Set up the basic tree for x86_64-gnu" Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-9-bugaevc@gmail.com>
* hurd: Fix x86_64 _hurd_tls_forkSergey Bugaev2023-05-171-6/+19
| | | | | | | | | | | | | | | It is illegal to call thread_get_state () on mach_thread_self (), so this codepath cannot be used as-is to fork the calling thread's TLS. Fortunately we can use THREAD_SELF (aka %fs:0x0) to find out the value of our fs_base without calling into the kernel. Fixes: f6cf701efc61c9ad910372bda14b9a235db310a8 "hurd: Implement TLS for x86_64" Checked on x86_64-gnu: fork () now works! Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-8-bugaevc@gmail.com>
* hurd: Make sure to not use tcb->selfSergey Bugaev2023-05-173-26/+14
| | | | | | | | | | | | | | | | | | | | Unlike sigstate->thread, tcb->self did not hold a Mach port reference on the thread port it names. This means that the port can be deallocated, and the name reused for something else, without anyone noticing. Using tcb->self will then lead to port use-after-free. Fortunately nothing was accessing tcb->self, other than it being intially set to then-valid thread port name upon TCB initialization. To assert that this keeps being the case without altering TCB layout, rename self -> self_do_not_use, and stop initializing it. Also, do not (re-)allocate a whole separate and unused stack for the main thread, and just exit __pthread_setup early in this case. Found upon attempting to use tcb->self and getting unexpected crashes. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-7-bugaevc@gmail.com>
* hurd: Use __mach_setup_thread_call ()Sergey Bugaev2023-05-172-7/+9
| | | | | | | | | | | ...instead of mach_setup_thread (), which is unsuitable for setting up function calls. Checked on x86_64-gnu: the signal thread no longer crashes upon trying to process a message. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-6-bugaevc@gmail.com>
* mach: Define MACHINE_THREAD_STATE_SETUP_CALLSergey Bugaev2023-05-172-0/+22
| | | | | | | | | | | | | | | | | | | | | The existing two macros, MACHINE_THREAD_STATE_SET_PC and MACHINE_THREAD_STATE_SET_SP, can be used to set program counter and the stack pointer registers in a machine-specific thread state structure. Useful as it is, this may not be enough to set up the thread to make a function call, because the machine-specific ABI may impose additional requirements. In particular, x86_64 ABI requires that upon function entry, the stack pointer is 8 less than 16-byte aligned (sp & 15 == 8). To deal with this, introduce a new macro, MACHINE_THREAD_STATE_SETUP_CALL (), which sets both stack and instruction pointers, and also applies any machine-specific requirements to make a valid function call. The default implementation simply forwards to MACHINE_THREAD_STATE_SET_PC and MACHINE_THREAD_STATE_SET_SP, but on x86_64 we additionally align the stack pointer. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230517191436.73636-3-bugaevc@gmail.com>
* Use TASK_THREAD_TIMES_INFO_COUNT when calling task_info with ↵Flavio Cruz2023-05-171-1/+1
| | | | | | | | | TASK_THREAD_TIMES_INFO This hasn't caused any problems yet but we are passing a pointer to struct task_thread_times_info which can cause problems if we populate over the existing size of the struct. Message-Id: <ZGRDDNcOM2hA3CuT@jupiter.tail36e24.ts.net>
* Update kernel version to 6.3 in header constant testsJoseph Myers2023-05-163-4/+4
| | | | | | | | | This patch updates the kernel version in the tests tst-mman-consts.py, tst-mount-consts.py and tst-pidfd-consts.py to 6.3. (There are no new constants covered by these tests in 6.3 that need any other header changes.) Tested with build-many-glibcs.py.
* i386: Use pthread_barrier for synchronization on tst-bz21269DJ Delorie2023-05-161-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | So I was able to reproduce the hangs in the original source, and debug it, and fix it. In doing so, I realized that we can't use anything complex to trigger the thread because that "anything" might also cause the expected segfault and force everything out of sync again. Here's what I ended up with, and it doesn't seem to hang where the original one hung quite often (in a tight while..end loop). The key changes are: 1. Calls to futex are error checked, with retries, to ensure that the futexes are actually doing what they're supposed to be doing. In the original code, nearly every futex call returned an error. 2. The main loop has checks for whether the thread ran or not, and "unlocks" the thread if it didn't (this is how the original source hangs). Note: the usleep() is not for timing purposes, but just to give the kernel an excuse to run the other thread at that time. The test will not hang without it, but is more likely to test the right bugfix if the usleep() is present.
* hurd: Fix computing user stack pointerSergey Bugaev2023-05-161-1/+1
| | | | | | | | | | Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0 "hurd: Implement sigreturn for x86_64" Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-5-bugaevc@gmail.com>
* hurd: Fix sc_i386_thread_state layoutSergey Bugaev2023-05-162-0/+14
| | | | | | | | | | | | | | | | | | | The real i386_thread_state Mach structure has an alignment of 8 on x86_64. However, in struct sigcontext, the compiler was packing sc_gs (which is the first member of sc_i386_thread_state) into the same 8-byte slot as sc_error; this resulted in the rest of sc_i386_thread_state members having wrong offsets relative to each other, and the overall sc_i386_thread_state layout mismatching that of i386_thread_state. Fix this by explicitly adding the required padding members, and statically asserting that this results in the desired alignment. The same goes for sc_i386_float_state. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-4-bugaevc@gmail.com>
* hurd: Align signal stack pointer after allocating stackframeSergey Bugaev2023-05-161-3/+2
| | | | | | | | | | | sizeof (*stackframe) appears to be divisible by 16, but we should not rely on that. So make sure to leave enough space for the stackframe first, and then align the final pointer at 16 bytes. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230515083323.1358039-3-bugaevc@gmail.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-07 10:58:55 +0000