aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-01-30manual: Add links to POSIX Semaphores man-pages documentationArjun Shankar1-0/+21
The POSIX Semaphores functions are currently undocumented in our info pages. This commit adds links to the man-pages documentation for all the `sem_*' functions (except `sem_clockwait') so that they refer to some useful documentation instead of just being stubs. `sem_clockwait' isn't documented by man-pages but thankfully already has a small useful blurb in our own docs. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-30manual: Consolidate POSIX Semaphores docs in Threads chapterArjun Shankar2-78/+88
This commit moves the `sem_*' family of functions from the IPC chapter, replacing them with a reference to their new location in the Threads chapter. `sem_clockwait' is also moved out of the Non-POSIX Extensions subsection since it is now included in the standard since Issue 8: https://pubs.opengroup.org/onlinepubs/9799919799/functions/sem_clockwait.html Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-30ld.so: Decorate BSS mappingsPetr Malat5-16/+83
Decorate BSS mappings with [anon: glibc: .bss <file>], for example [anon: glibc: .bss /lib/libc.so.6]. The string ".bss" is already used by bionic so use the same, but add the filename as well. If the name would be longer than what the kernel allows, drop the directory part of the path. Refactor glibc.mem.decorate_maps check to a separate function and use it to avoid assembling a name, which would not be used later. Signed-off-by: Petr Malat <oss@malat.biz> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-30nptl: Add support for setup guard pages with MADV_GUARD_INSTALLAdhemerval Zanella10-95/+561
Linux 6.13 (662df3e5c3766) added a lightweight way to define guard areas through madvise syscall. Instead of PROT_NONE the guard region through mprotect, userland can madvise the same area with a special flag, and the kernel ensures that accessing the area will trigger a SIGSEGV (as for PROT_NONE mapping). The madvise way has the advantage of less kernel memory consumption for the process page-table (one less VMA per guard area), and slightly less contention on kernel (also due to the fewer VMA areas being tracked). The pthread_create allocates a new thread stack in two ways: if a guard area is set (the default) it allocates the memory range required using PROT_NONE and then mprotect the usable stack area. Otherwise, if a guard page is not set it allocates the region with the required flags. For the MADV_GUARD_INSTALL support, the stack area region is allocated with required flags and then the guard region is installed. If the kernel does not support it, the usual way is used instead (and MADV_GUARD_INSTALL is disabled for future stack creations). The stack allocation strategy is recorded on the pthread struct, and it is used in case the guard region needs to be resized. To avoid needing an extra field, the 'user_stack' is repurposed and renamed to 'stack_mode'. This patch also adds a proper test for the pthread guard. I checked on x86_64, aarch64, powerpc64le, and hppa with kernel 6.13.0-rc7. Reviewed-by: DJ Delorie <dj@redhat.com>
2025-01-29nptl: Correct stack size attribute when stack grows up [BZ #32574]John David Anglin1-2/+2
Set stack size attribute to the size of the mmap'd region only when the size of the remaining stack space is less than the size of the mmap'd region. This was reversed. As a result, the initial stack size was only 135168 bytes. On architectures where the stack grows down, the initial stack size is approximately 8384512 bytes with the default rlimit settings. The small main stack size on hppa broke applications like ruby that check for stack overflows. Signed-off-by: John David Anglin <dave.anglin@bell.net>
2025-01-29manual: Update compatibility note on flushing of line-oriented filesFlorian Weimer1-6/+12
Operation systems which represent text files in a line-oriented fashion (and not as byte streams with a character sequence reserved for line termination) logically cannot flush a buffer without also creating a terminated line. Update this portability note and move it to the Binary Streams section. Add another related compatibility concern, too.
2025-01-29htl: move pthread_setcanceltype into libc.gfleury10-11/+13
Message-ID: <20250103103750.870897-7-gfleury@disroot.org>
2025-01-29htl: move pthread_mutex_consistent, pthread_mutex_consistent_np into libc.gfleury8-11/+25
Message-ID: <20250103103750.870897-6-gfleury@disroot.org>
2025-01-29htl: move pthread_mutex_destroy into libc.gfleury11-16/+10
Message-ID: <20250103103750.870897-5-gfleury@disroot.org>
2025-01-29htl: move pthread_mutex_getprioceiling, pthread_mutex_setprioceiling into libcgfleury9-12/+37
Message-ID: <20250103103750.870897-4-gfleury@disroot.org>
2025-01-29htl: move pthread_mutex_{lock, unlock, trylock, timedlock, clocklock}gfleury18-66/+78
I haven't exposed _pthread_mutex_lock, _pthread_mutex_trylock and _pthread_mutex_unlock in GLIBC_PRIVATE since there aren't used in any code in libpthread Message-ID: <20250103103750.870897-3-gfleury@disroot.org>
2025-01-29htl: move pthread_mutex_init into libc.gfleury12-20/+13
Message-ID: <20250103103750.870897-2-gfleury@disroot.org>
2025-01-29htl: remove leftover for pthread_mutexattr_settypegfleury2-6/+0
from b386295727d35a83aa3d4750e198cbf8040c9a23
2025-01-28Add test of input file flushing / offset issuesJoseph Myers2-0/+561
Having fixed several bugs relating to flushing of FILE* streams (with fflush and other operations) and their offsets (both the file position indicator in the FILE*, and the offset in the underlying open file description), especially after ungetc but not limited to that case, add a test that more systematically covers different combinations of cases for such issues, with 57220 separate scenarios tested (which include examples of all the five separate fixed bugs), all of which pass given the five previous bug fixes. Tested for x86_64.
2025-01-28Fix fflush handling for mmap files after ungetc (bug 32535)Joseph Myers3-4/+59
As discussed in bug 32535, fflush fails on files opened for reading using mmap after ungetc. Fix the logic to handle this case and still compute the file offset correctly. Tested for x86_64.
2025-01-28Fix fseek handling for mmap files after ungetc or fflush (bug 32529)Joseph Myers3-1/+68
As discussed in bug 32529, fseek fails on files opened for reading using mmap after ungetc. The implementation of fseek for such files has an offset computation that's also incorrect after fflush. A combined fix addresses both problems (with tests for both included as well) and it seems reasonable to consider them a single bug. Tested for x86_64.
2025-01-28Make fflush (NULL) flush input files (bug 32369)Joseph Myers3-0/+102
As discussed in bug 32369 and required by POSIX, the POSIX feature fflush (NULL) should flush input files, not just output files. The POSIX requirement is that "fflush() shall perform this flushing action on all streams for which the behavior is defined above", and the definition for input files is for "a stream open for reading with an underlying file description, if the file is not already at EOF, and the file is one capable of seeking". Implement this requirement in glibc. (The underlying flushing implementation is what deals with avoiding errors for seeking on an unseekable file.) Tested for x86_64.
2025-01-28Make fclose seek input file to right offset (bug 12724)Joseph Myers3-5/+264
As discussed in bug 12724 and required by POSIX, before an input file (based on an underlying seekable file descriptor) is closed, fclose is sometimes required to seek that file descriptor to the correct offset, so that any other file descriptors sharing the underlying open file description are left at that offset (as a motivating example, a script could call a sequence of commands each of which processes some data from (seekable) stdin using stdio; fclose needs to do this so that each successive command can read exactly the data not handled by previous commands), but glibc fails to do this. The precise POSIX wording has changed a few times; in the 2024 edition it's "If the file is not already at EOF, and the file is one capable of seeking, the file offset of the underlying open file description shall be set to the file position of the stream if the stream is the active handle to the underlying file description.". Add appropriate logic to _IO_new_file_close_it to handle this case. I haven't made any attempt to test or change things in this area for the "old" functions. Note that there was a previous attempt to fix bug 12724, reverted in commit eb6cbd249f4465b01f428057bf6ab61f5f0c07e3. The fix version here addresses the original test in that bug report without breaking the one given in a subsequent comment in that bug report (which works with glibc before the patch, but maybe was broken by the original fix that was reverted). The logic here tries to take care not to seek the file, even to its newly computed current offset, if at EOF / possibly not the active handle; even seeking to the current offset would be problematic because of a potential race (fclose computes the current offset, another thread or process with the active handle does its own seek, fclose does a seek (not permitted by POSIX in this case) that loses the effect of the seek on the active handle in another thread or process). There are tests included for various cases of being or not being the active handle, though there aren't tests for the potential race condition. Tested for x86_64.
2025-01-28Fix fflush after ungetc on input file (bug 5994)Joseph Myers3-0/+70
As discussed in bug 5994 (plus duplicates), POSIX requires fflush after ungetc to discard pushed-back characters but preserve the file position indicator. For this purpose, each ungetc decrements the file position indicator by 1; it is unspecified after ungetc at the start of the file, and after ungetwc, so no special handling is needed for either of those cases. This is fixed with appropriate logic in _IO_new_file_sync. I haven't made any attempt to test or change things in this area for the "old" functions; the case of files using mmap is addressed in a subsequent patch (and there seem to be no problems in this area with files opened with fmemopen). Tested for x86_64.
2025-01-28libio: Add a new fwrite test that evaluates partial writesTulio Magno Quites Machado Filho2-0/+234
Test if the file-position is correctly updated when fwrite tries to flush its internal cache but is not able to completely write all items. Reviewed-by: DJ Delorie <dj@redhat.com>
2025-01-28libio: Start to return errors when flushing fwrite's buffer [BZ #29459]Tulio Magno Quites Machado Filho7-6/+304
When an error happens, fwrite is expected to return a value that is less than nmemb. If this error happens while flushing its internal buffer, fwrite is in a complex scenario: all the data might have been written to the buffer, indicating a successful copy, but the buffer is expected to be flushed and it was not. POSIX.1-2024 states the following about errors on fwrite: If an error occurs, the resulting value of the file-position indicator for the stream is unspecified. The fwrite() function shall return the number of elements successfully written, which may be less than nitems if a write error is encountered. With that in mind, this commit modifies _IO_new_file_write in order to return the total number of bytes written via the file pointer. It also modifies fwrite in order to use the new information and return the correct number of bytes written even when sputn returns EOF. Add 2 tests: 1. tst-fwrite-bz29459: This test is based on the reproducer attached to bug 29459. In order to work, it requires to pipe stdout to another process making it hard to reuse test-driver.c. This code is more specific to the issue reported. 2. tst-fwrite-pipe: Recreates the issue by creating a pipe that is shared with a child process. Reuses test-driver.c. Evaluates a more generic scenario. Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: DJ Delorie <dj@redhat.com>
2025-01-28Add new tests for fopenMartin Coufal4-0/+531
Adding some basic tests for fopen, testing different modes, stream positioning and concurrent read/write operation on files. Reviewed-by: DJ Delorie <dj@redhat.com>
2025-01-28Increase version to 2.41.9000, add new section to NEWSglibc-2.41.9000Andreas K. Hüttel2-2/+29
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-28Create ChangeLog.old/ChangeLog.30glibc-2.41Andreas K. Hüttel1-0/+13253
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-28Bump version to 2.41Andreas K. Hüttel2-3/+3
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-28po: update translations (final, only timestamp and line number changes)Andreas K. Hüttel38-91/+91
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-28libc.pot: regenerate (only line number changes)Andreas K. Hüttel1-3/+3
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-28INSTALL: update last tested version numbersAndreas K. Hüttel2-15/+15
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-27contrib.texi: minor improvementsAndreas K. Hüttel1-2/+3
Mention CORE-MATH developers by name Fix accent Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-27NEWS: Add some more news from the 2.41 cycleAndreas K. Hüttel1-8/+31
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-27contrib.texi: Update from 2.40..2.41 commit logAndreas K. Hüttel1-22/+78
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-26NEWS: Add reference to (single) advisoryAndreas K. Hüttel1-2/+3
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-26NEWS: Add list of bugs fixed in 2.41Andreas K. Hüttel1-2/+135
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-26NEWS: editorial changes (language, line breaks)Andreas K. Hüttel1-54/+62
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-26testsuite: Make stdio-common/tst-printf-format-*-mem UNSUPPORTED if the ↵Xi Ruoyao1-2/+5
mtrace output does not exist When gawk was not built with MPFR, there's no mtrace output and those tests FAIL. But we should make them UNSUPPORTED like other tst-printf-format-* tests in the case. Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Sam James <sam@gentoo.org> Reviewed-by: Andreas K Hüttel <dilfridge@gentoo.org>
2025-01-25elf: fix 'valgrind' typo in commentSam James1-1/+1
2025-01-25malloc: cleanup casts in tst-callocSam James1-2/+2
Followup to c3d1dac96bdd10250aa37bb367d5ef8334a093a1. As pointed out by Maciej W. Rozycki, the casts are obviously useless now. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-25stdlib: Test using setenv with updated environ [BZ #32588]H.J. Lu2-0/+37
Add a test for setenv with updated environ. Verify that BZ #32588 is fixed. Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2025-01-24LICENSES: update CORE-MATH copyrightAurelien Jarno1-4/+4
Many more files from the CORE-MATH have been added. Also update the authors and copyright years. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-24LICENSES: update location of getaddrinfo.c and getnameinfo.cAurelien Jarno1-2/+2
posix/getaddrinfo.c got moved into nss/getaddrinfo.c in commit 7f602256ab5b ("Move getaddrinfo from 'posix' into 'nss'") inet/getnameinfo.c got moved into nss/getnameinfo.c in commit 2f1c 6652 d7b3 ("Move getnameinfo from 'inet' to 'nss'") Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-24LICENSES: remove Intel License AgreementAurelien Jarno1-36/+0
The corresponding files are gone with the IA64 removal in commit 460860f457e2 ("Remove ia64-linux-gnu"). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-24stdlib: Re-implement free (environ) compatibility kludge for setenvFlorian Weimer8-17/+158
For the originally failing application (userhelper from usermode), it is not actually necessary to call realloc on the environ pointer. Yes, there will be a memory leak because the application assigns a heap-allocated pointer to environ that it never frees, but this leak was always there: the old realloc-based setenv had a hidden internal variable, last_environ, that was used in a similar way to __environ_array_list. The application is not impacted by the leak anyway because the relevant operations do not happen in a loop. The change here just uses a separte heap allocation and points environ to that. This means that if an application calls free (environ) and restores the environ pointer to the value at process start, and does not modify the environment further, nothing bad happens. This change should not invalidate any previous testing that went into the original getenv thread safety change, commit 7a61e7f557a97ab597d6 ("stdlib: Make getenv thread-safe in more cases"). The new test cases are modeled in part on the env -i use case from bug 32588 (with !DO_MALLOC && !DO_EARLY_SETENV), and the previous stdlib/tst-setenv-malloc test. The DO_MALLOC && !DO_EARLY_SETENV case in the new test should approximate what userhelper from the usermode package does. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2025-01-24Revert "stdlib: Support malloc-managed environ arrays for compatibility"Florian Weimer7-105/+33
This reverts commit b62759db04b8ed7f829c06f1d7c3b8fb70616493. Reason for revert: Incompatible with “env -i” and coreutils (bug 32588). Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
2025-01-23stdlib: Support malloc-managed environ arrays for compatibilityFlorian Weimer7-33/+105
Some applications set environ to a heap-allocated pointer, call setenv (expecting it to call realloc), free environ, and then restore the original environ pointer. This breaks after commit 7a61e7f557a97ab597d6fca5e2d1f13f65685c61 ("stdlib: Make getenv thread-safe in more cases") because after the setenv call, the environ pointer does not point to the start of a heap allocation. Instead, setenv creates a separate allocation and changes environ to point into that. This means that the free call in the application results in heap corruption. The interim approach was more compatible with other libcs because it does not assume that the incoming environ pointer is allocated as if by malloc (if it was written by the application). However, it seems to be more important to stay compatible with previous glibc version: assume the incoming pointer is heap allocated, and preserve this property after setenv calls. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2025-01-22po: Incorporate translationsAndreas K. Hüttel38-4950/+5090
be ca cs da de el eo es fi fr gl hr hu ia id it ja ka ko lt nb nl pl pt ro ru rw sk sl sr sv tr uk vi zh_CN zh_TW Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2025-01-22Update advisory GLIBC-SA-2025-0001 (2.40)Siddhesh Poyarekar1-0/+1
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2025-01-22Add advisory text for CVE-2025-0395Siddhesh Poyarekar1-0/+24
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-22Fix underallocation of abort_msg_s struct (CVE-2025-0395)Siddhesh Poyarekar2-2/+6
Include the space needed to store the length of the message itself, in addition to the message string. This resolves BZ #32582. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-01-21NEWS: Add note on Guarded Control Stack supportYury Khrustalev1-0/+10
Reviewed-by: Andreas K. Huettel <dilfridge@gentoo.org>
2025-01-21Fix typo: _POSIX_REATIME_SIGNALS -> _POSIX_REALTIME_SIGNALS [BZ# 32515]Paul Pluzhnikov1-1/+1
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>