Commit Graph

37908 Commits

Author SHA1 Message Date
Hans-Peter Nilsson
85b24f9694 timezone: handle truncated timezones from tzcode-2021d and later (BZ #28707)
When using a timezone file with a truncated starting time,
generated by the zic in IANA tzcode-2021d a.k.a. tzlib-2021d
(also in tzlib-2021e; current as of this writing), glibc
asserts in __tzfile_read (on e.g. tzset() for this file) and
you may find lines matching "tzfile.c:435: __tzfile_read:
Assertion `num_types == 1' failed" in your syslog.

One example of such a file is the tzfile for Asuncion
generated by tzlib-2021e as follows, using the tzlib-2021e zic:
"zic -d DEST -r @1546300800 -L /dev/null -b slim
SOURCE/southamerica".  Note that in its type 2 header, it has
two entries in its "time-types" array (types), but only one
entry in its "transition types" array (type_idxs).

This is valid and expected already in the published RFC8536, and
not even frowned upon: "Local time for timestamps before the
first transition is specified by the first time type (time type
0)" ... "every nonzero local time type index SHOULD appear at
least once in the transition type array".  Note the "nonzero ...
index".  Until the 2021d zic, index 0 has been shared by the
first valid transition but with 2021d it's separate, set apart
as a placeholder and only "implicitly" indexed.  (A draft update
of the RFC mandates that the entry at index 0 is a placeholder
in this case, hence can no longer be shared.)

	* time/tzfile.c (__tzfile_read): Don't assert when no transitions
	are found.

Co-authored-by: Christopher Wong <Christopher.Wong@axis.com>
(cherry picked from commit c36f64aa6d)
2022-01-07 10:20:58 +01:00
Paul Eggert
515a6f53cd Fix subscript error with odd TZif file [BZ #28338]
* time/tzfile.c (__tzfile_compute): Fix unlikely off-by-one bug
that accessed before start of an array when an oddball-but-valid
TZif file was queried with an unusual time_t value.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit 645277434a)
2022-01-07 10:20:02 +01:00
Wilco Dijkstra
217b84127b AArch64: Check for SVE in ifuncs [BZ #28744]
Add a check for SVE in the A64FX ifuncs for memcpy, memset and memmove.
This fixes BZ #28744.

(cherry picked from commit e5fa62b8db)
2022-01-07 10:10:27 +01:00
Andrea Monaco
41fddc064d intl/plural.y: Avoid conflicting declarations of yyerror and yylex
bison-3.8 includes these lines in the generated intl/plural.c:

  #if !defined __gettexterror && !defined YYERROR_IS_DECLARED
  void __gettexterror (struct parse_args *arg, const char *msg);
  #endif
  #if !defined __gettextlex && !defined YYLEX_IS_DECLARED
  int __gettextlex (YYSTYPE *yylvalp, struct parse_args *arg);
  #endif

Those default prototypes provided by bison conflict with the
declarations later on in plural.y.  This patch solves the issue.

Reviewed-by: Arjun Shankar <arjun@redhat.com>
(cherry picked from commit c6d7d6312c)
2021-12-23 13:48:04 +01:00
maminjie
8ad6d6d8ed Linux: Fix 32-bit vDSO for clock_gettime on powerpc32
When the clock_id is CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID,
on the 5.10 kernel powerpc 32-bit, the 32-bit vDSO is executed successfully (
because the __kernel_clock_gettime in arch/powerpc/kernel/vdso32/gettimeofday.S
does not support these two IDs, the 32-bit time_t syscall will be used),
but tp32.tv_sec is equal to 0, causing the 64-bit time_t syscall to continue to be used,
resulting in two system calls.

Fix commit 72e84d1db2.

Signed-off-by: maminjie  <maminjie2@huawei.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

(cherry picked from commit e0fc721ce6)
2021-12-21 09:50:25 -03:00
Adhemerval Zanella
1d9764aba8 linux: Add sparck brk implementation
It turned that the generic implementation of brk() does not work
for sparc, since on failure kernel will just return the previous
input value without setting the conditional register.

This patches adds back a sparc32 and sparc64 implementation removed
by 720480934a.

Checked on sparc64-linux-gnu and sparcv9-linux-gnu.

(cherry picked from commit 5b86241a03)
2021-12-19 22:56:33 +01:00
Adhemerval Zanella
e94544c82f Update sparc libm-test-ulps
(cherry picked from commit c52eb066bc)
2021-12-18 23:45:53 +01:00
John David Anglin
4029747c59 Update hppa libm-test-ulps
(cherry picked from commit d8cf84ac7e)
2021-12-17 23:51:39 +01:00
Aurelien Jarno
aa3a97496c riscv: align stack before calling _dl_init [BZ #28703]
Align the stack pointer to 128 bits during the call to _dl_init() as
specified by the RISC-V ABI [1]. This fixes the elf/tst-align2 test.

Fixes bug 28703.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc

(cherry picked from commit 225da459ce)
2021-12-17 22:50:13 +01:00
Aurelien Jarno
9de8011c32 riscv: align stack in clone [BZ #28702]
The RISC-V ABI [1] mandates that "the stack pointer shall be aligned to
a 128-bit boundary upon procedure entry". This as not the case in clone.

This fixes the misc/tst-misalign-clone-internal and
misc/tst-misalign-clone tests.

Fixes bug 28702.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc

(cherry picked from commit d2e594d715)
2021-12-17 22:48:41 +01:00
Matheus Castanho
5daf13b1e6 powerpc64[le]: Allocate extra stack frame on syscall.S
The syscall function does not allocate the extra stack frame for scv like other
assembly syscalls using DO_CALL_SCV. So after commit d120fb9941 changed the
offset that is used to save LR, syscall ended up using an invalid offset,
causing regressions on powerpc64. So make sure the extra stack frame is
allocated in syscall.S as well to make it consistent with other uses of
DO_CALL_SCV and avoid similar issues in the future.

Tested on powerpc, powerpc64, and powerpc64le (with and without scv)

Reviewed-by: Raphael M Zinsly <rzinsly@linux.ibm.com>

(cherry picked from commit ae91d3df24)
2021-12-17 17:19:22 -03:00
Aurelien Jarno
03de6917bd elf: Fix tst-cpu-features-cpuinfo for KVM guests on some AMD systems [BZ #28704]
On KVM guests running on some AMD systems, the IBRS feature is reported
as a synthetic feature using the Intel feature, while the cpuinfo entry
keeps the same. Handle that by first checking the presence of the Intel
feature on AMD systems.

Fixes bug 28704.

(cherry picked from commit 94058f6cde)
2021-12-17 20:35:45 +01:00
Florian Weimer
dc9b69d533 nss: Use "files dns" as the default for the hosts database (bug 28700)
This matches what is currently in nss/nsswitch.conf.  The new ordering
matches what most distributions use in their installed configuration
files.

It is common to add localhost to /etc/hosts because the name does not
exist in the DNS, but is commonly used as a host name.

With the built-in "dns [!UNAVAIL=return] files" default, dns is
searched first and provides an answer for "localhost" (NXDOMAIN).
We never look at the files database as a result, so the contents of
/etc/hosts is ignored.  This means that "getent hosts localhost"
fail without a /etc/nsswitch.conf file, even though the host name
is listed in /etc/hosts.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit b99b0f93ee)
2021-12-17 12:17:18 +01:00
Florian Weimer
93aabf891e arm: Guard ucontext _rtld_global_ro access by SHARED, not PIC macro
Due to PIE-by-default, PIC is now defined in more cases.  libc.a
does not have _rtld_global_ro, and statically linking setcontext
fails.  SHARED is the right condition to use, so that libc.a
references _dl_hwcap instead of _rtld_global_ro.

For static PIE support, the !SHARED case would still have to be made
PIC.  This patch does not achieve that.

Fixes commit 23645707f1
("Replace --enable-static-pie with --disable-default-pie").

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
(cherry picked from commit ce1e5b1122)
2021-12-17 12:16:13 +01:00
Xi Ruoyao
4db172a54d mips: increase stack alignment in clone to match the ABI
In "mips: align stack in clone [BZ #28223]"
(commit 1f51cd9a86) I made a mistake: I
misbelieved one "word" was 2-byte and "doubleword" should be 4-byte.
But in MIPS ABI one "word" is defined 32-bit (4-byte), so "doubleword" is
8-byte [1], and "quadword" is 16-byte [2].

[1]: "System V Application Binary Interface: MIPS(R) RISC Processor
      Supplement, 3rd edition", page 3-31
[2]: "MIPSpro(TM) 64-Bit Porting and Transition Guide", page 23

(cherry picked from commit 0f62fe0532)
2021-12-14 22:57:43 +01:00
Xi Ruoyao
7af07fe795 mips: align stack in clone [BZ #28223]
The MIPS O32 ABI requires 4 byte aligned stack, and the MIPS N64 and N32
ABI require 8 byte aligned stack.  Previously if the caller passed an
unaligned stack to clone the the child misbehaved.

Fixes bug 28223.

(cherry picked from commit 1f51cd9a86)
2021-12-14 22:57:39 +01:00
Stafford Horne
0686586515 pthread/tst-cancel28: Fix barrier re-init race condition
When running this test on the OpenRISC port I am working on this test
fails with a timeout.  The test passes when being straced or debugged.
Looking at the code there seems to be a race condition in that:

  1 main thread: calls xpthread_cancel
  2 sub thread : receives cancel signal
  3 sub thread : cleanup routine waits on barrier
  4 main thread: re-inits barrier
  5 main thread: waits on barrier

After getting to 5 the main thread and sub thread wait forever as the 2
barriers are no longer the same.

Removing the barrier re-init seems to fix this issue.  Also, the barrier
does not need to be reinitialized as that is done by default.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit 9874ca536b)
2021-12-14 10:07:27 +05:30
Joseph Myers
1fe4b8d693 Use $(pie-default) with conformtest
My glibc bot showed that my conformtest changes fail the build of the
conformtest execution tests for x86_64-linux-gnu-static-pie, because
linking the newly built object with the newly built libc and the
associated options normally used for linking requires it to be built
as PIE.  Add $(pie-default) to the compiler command used so that PIE
options are used when required.

There's a case for using the whole of $(CFLAGS-.o) (which includes
$(pie-default)), but that raises questions of any impact from using
optimization flags from CFLAGS in these tests.  So for now just use
$(pie-default) as the key part of $(CFLAGS-.o) that's definitely
needed.

Tested with build-many-glibcs.py for x86_64-linux-gnu-static-pie.

(cherry picked from commit 885762aa31)
2021-12-13 20:59:48 +05:30
Joseph Myers
0dcbf4c870 Run conform/ tests using newly built libc
Although the conform/ header tests are built using the headers of the
glibc under test, the execution tests from conformtest (a few tests of
the values of macros evaluating to string constants) are linked and
run with system libc, not the newly built libc.

Apart from preventing testing in cross environments, this can be a
problem even for native testing.  Specifically, it can be useful to do
native testing when building with a cross compiler that links with a
libc that is not the system libc; for example, on x86_64, you can test
all three ABIs that way if the kernel support is present, even if the
host OS lacks 32-bit or x32 libraries or they are older than the
libraries in the sysroot used by the compiler used to build glibc.
This works for almost all tests, but not for these conformtest tests.

Arrange for conformtest to link and run test programs similarly to
other tests, with consequent refactoring of various variables in
Makeconfig to allow passing relevant parts of the link-time command
lines down to conformtest.  In general, the parts of the link command
involving $@ or $^ are separated out from the parts that should be
passed to conformtest (the variables passed to conformtest still
involve various variables whose names involve $(@F), but those
variables simply won't be defined for the conformtest makefile rules
and I think their presence there is harmless).

This is also most of the support that would be needed to allow running
those tests of string constants for cross testing when test-wrapper is
defined.  That will also need changes to where conformtest.py puts the
test executables, so it puts them in the main object directory
(expected to be shared with a test system in cross testing) rather
than /tmp (not expected to be shared) as at present.

Tested for x86_64.

(cherry picked from commit f3eef96390)
2021-12-13 09:07:38 +05:30
Florian Weimer
e9f81c261a nptl: Add one more barrier to nptl/tst-create1
Without the bar_ctor_finish barrier, it was possible that thread2
re-locked user_lock before ctor had a chance to lock it.  ctor then
blocked in its locking operation, xdlopen from the main thread
did not return, and thread2 was stuck waiting in bar_dtor:

thread 1: started.
thread 2: started.
thread 2: locked user_lock.
constructor started: 0.
thread 1: in ctor: started.
thread 3: started.
thread 3: done.
thread 2: unlocked user_lock.
thread 2: locked user_lock.

Fixes the test in commit 83b5323261
("elf: Avoid deadlock between pthread_create and ctors [BZ #28357]").

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
(cherry picked from commit 5cc3385654)
2021-12-10 11:56:06 +01:00
Matheus Castanho
387bff63dc powerpc64[le]: Fix CFI and LR save address for asm syscalls [BZ #28532]
Syscalls based on the assembly templates are missing CFI for r31, which gets
clobbered when scv is used, and info for LR is inaccurate, placed in the wrong
LOC and not using the proper offset. LR was also being saved to the callee's
frame, while the ABI mandates it to be saved to the caller's frame. These are
fixed by this commit.

After this change:

$ readelf -wF libc.so.6 | grep 0004b9d4.. -A 7 && objdump --disassemble=kill libc.so.6
00004a48 0000000000000020 00004a4c FDE cie=00000000 pc=000000000004b9d4..000000000004ba3c
   LOC           CFA      r31   ra
000000000004b9d4 r1+0     u     u
000000000004b9e4 r1+48    u     u
000000000004b9e8 r1+48    c-16  u
000000000004b9fc r1+48    c-16  c+16
000000000004ba08 r1+48    c-16
000000000004ba18 r1+48    u
000000000004ba1c r1+0     u

libc.so.6:     file format elf64-powerpcle

Disassembly of section .text:

000000000004b9d4 <kill>:
   4b9d4:       1f 00 4c 3c     addis   r2,r12,31
   4b9d8:       2c c3 42 38     addi    r2,r2,-15572
   4b9dc:       25 00 00 38     li      r0,37
   4b9e0:       d1 ff 21 f8     stdu    r1,-48(r1)
   4b9e4:       20 00 e1 fb     std     r31,32(r1)
   4b9e8:       98 8f ed eb     ld      r31,-28776(r13)
   4b9ec:       10 00 ff 77     andis.  r31,r31,16
   4b9f0:       1c 00 82 41     beq     4ba0c <kill+0x38>
   4b9f4:       a6 02 28 7d     mflr    r9
   4b9f8:       40 00 21 f9     std     r9,64(r1)
   4b9fc:       01 00 00 44     scv     0
   4ba00:       40 00 21 e9     ld      r9,64(r1)
   4ba04:       a6 03 28 7d     mtlr    r9
   4ba08:       08 00 00 48     b       4ba10 <kill+0x3c>
   4ba0c:       02 00 00 44     sc
   4ba10:       00 00 bf 2e     cmpdi   cr5,r31,0
   4ba14:       20 00 e1 eb     ld      r31,32(r1)
   4ba18:       30 00 21 38     addi    r1,r1,48
   4ba1c:       18 00 96 41     beq     cr5,4ba34 <kill+0x60>
   4ba20:       01 f0 20 39     li      r9,-4095
   4ba24:       40 48 23 7c     cmpld   r3,r9
   4ba28:       20 00 e0 4d     bltlr+
   4ba2c:       d0 00 63 7c     neg     r3,r3
   4ba30:       08 00 00 48     b       4ba38 <kill+0x64>
   4ba34:       20 00 e3 4c     bnslr+
   4ba38:       c8 32 fe 4b     b       2ed00 <__syscall_error>
        ...
   4ba44:       40 20 0c 00     .long 0xc2040
   4ba48:       68 00 00 00     .long 0x68
   4ba4c:       06 00 5f 5f     rlwnm   r31,r26,r0,0,3
   4ba50:       6b 69 6c 6c     xoris   r12,r3,26987

(cherry picked from commit d120fb9941)
2021-11-30 15:34:03 -03:00
Adhemerval Zanella
f988b7f228 linux: Use /proc/stat fallback for __get_nprocs_conf (BZ #28624)
The /proc/statm fallback was removed by f13fb81ad3 if sysfs is
not available, reinstate it.

Checked on x86_64-linux-gnu.
(cherry-picked from commit 137ed5ac44)
2021-11-25 14:02:51 -03:00
Florian Weimer
bfe68fe3c4 nptl: Do not set signal mask on second setjmp return [BZ #28607]
__libc_signal_restore_set was in the wrong place: It also ran
when setjmp returned the second time (after pthread_exit or
pthread_cancel).  This is observable with blocked pending
signals during thread exit.

Fixes commit b3cae39dcb
("nptl: Start new threads with all signals blocked [BZ #25098]").

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit e186fc5a31)
2021-11-24 09:22:10 +01:00
Florian Weimer
a4f3bc2346 s390: Use long branches across object boundaries (jgh instead of jh)
Depending on the layout chosen by the linker, the 16-bit displacement
of the jh instruction is insufficient to reach the target label.

Analysis of the linker failure was carried out by Nick Clifton.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Stefan Liebler <stli@linux.ibm.com>
(cherry picked from commit 98966749f2)
2021-11-10 15:22:24 +01:00
Florian Weimer
cf8c6a634c elf: Earlier missing dynamic segment check in _dl_map_object_from_fd
Separated debuginfo files have PT_DYNAMIC with p_filesz == 0.  We
need to check for that before the _dl_map_segments call because
that could attempt to write to mappings that extend beyond the end
of the file, resulting in SIGBUS.

Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit ea32ec354c)
2021-11-05 19:36:06 +01:00
Nikita Popov
f411207a83 gconv: Do not emit spurious NUL character in ISO-2022-JP-3 (bug 28524)
Bugfix 27256 has introduced another issue:
In conversion from ISO-2022-JP-3 encoding, it is possible
to force iconv to emit extra NUL character on internal state reset.
To do this, it is sufficient to feed iconv with escape sequence
which switches active character set.
The simplified check 'data->__statep->__count != ASCII_set'
introduced by the aforementioned bugfix picks that case and
behaves as if '\0' character has been queued thus emitting it.

To eliminate this issue, these steps are taken:
* Restore original condition
'(data->__statep->__count & ~7) != ASCII_set'.
It is necessary since bits 0-2 may contain
number of buffered input characters.
* Check that queued character is not NUL.
Similar step is taken for main conversion loop.

Bundled test case follows following logic:
* Try to convert ISO-2022-JP-3 escape sequence
switching active character set
* Reset internal state by providing NULL as input buffer
* Ensure that nothing has been converted.

Signed-off-by: Nikita Popov <npv1310@gmail.com>
(cherry picked from commit ff012870b2)
2021-11-04 21:28:43 +01:00
H.J. Lu
6548a9bdba Avoid warning: overriding recipe for .../tst-ro-dynamic-mod.so
Add tst-ro-dynamic-mod to modules-names-nobuild to avoid

../Makerules:767: warning: ignoring old recipe for target '.../elf/tst-ro-dynamic-mod.so'

This updates BZ #28340 fix.

(cherry picked from commit 15e6d6785a)
2021-11-03 10:21:04 +01:00
H.J. Lu
5f36e5c701 ld.so: Initialize bootstrap_map.l_ld_readonly [BZ #28340]
1. Define DL_RO_DYN_SECTION to initalize bootstrap_map.l_ld_readonly
before calling elf_get_dynamic_info to get dynamic info in bootstrap_map,
2. Define a single

static inline bool
dl_relocate_ld (const struct link_map *l)
{
  /* Don't relocate dynamic section if it is readonly  */
  return !(l->l_ld_readonly || DL_RO_DYN_SECTION);
}

This updates BZ #28340 fix.

(cherry picked from commit 2ec99d8c42)
2021-11-03 07:53:12 +01:00
H.J. Lu
f42373f911 ld.so: Replace DL_RO_DYN_SECTION with dl_relocate_ld [BZ #28340]
We can't relocate entries in dynamic section if it is readonly:

1. Add a l_ld_readonly field to struct link_map to indicate if dynamic
section is readonly and set it based on p_flags of PT_DYNAMIC segment.
2. Replace DL_RO_DYN_SECTION with dl_relocate_ld to decide if dynamic
section should be relocated.
3. Remove DL_RO_DYN_TEMP_CNT.
4. Don't use a static dynamic section to make readonly dynamic section
in vDSO writable.
5. Remove the temp argument from elf_get_dynamic_info.

This fixes BZ #28340.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
(cherry picked from commit b413280cfb)
2021-11-03 07:50:30 +01:00
Siddhesh Poyarekar
01bffc013c Handle NULL input to malloc_usable_size [BZ #28506]
Hoist the NULL check for malloc_usable_size into its entry points in
malloc-debug and malloc and assume non-NULL in all callees.  This fixes
BZ #28506

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit 88e316b064)
2021-10-29 14:56:53 +05:30
Szabolcs Nagy
024a7640ab elf: Avoid deadlock between pthread_create and ctors [BZ #28357]
The fix for bug 19329 caused a regression such that pthread_create can
deadlock when concurrent ctors from dlopen are waiting for it to finish.
Use a new GL(dl_load_tls_lock) in pthread_create that is not taken
around ctors in dlopen.

The new lock is also used in __tls_get_addr instead of GL(dl_load_lock).

The new lock is held in _dl_open_worker and _dl_close_worker around
most of the logic before/after the init/fini routines.  When init/fini
routines are running then TLS is in a consistent, usable state.
In _dl_open_worker the new lock requires catching and reraising dlopen
failures that happen in the critical section.

The new lock is reinitialized in a fork child, to keep the existing
behaviour and it is kept recursive in case malloc interposition or TLS
access from signal handlers can retake it.  It is not obvious if this
is necessary or helps, but avoids changing the preexisting behaviour.

The new lock may be more appropriate for dl_iterate_phdr too than
GL(dl_load_write_lock), since TLS state of an incompletely loaded
module may be accessed.  If the new lock can replace the old one,
that can be a separate change.

Fixes bug 28357.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit 83b5323261)
2021-10-19 14:21:14 +02:00
Stafford Horne
cb9b8b5d76 timex: Use 64-bit fields on 32-bit TIMESIZE=64 systems (BZ #28469)
This was found when testing the OpenRISC port I am working on.  These
two tests fail with SIGSEGV:

  FAIL: misc/tst-ntp_gettime
  FAIL: misc/tst-ntp_gettimex

This was found to be due to the kernel overwriting the stack space
allocated by the timex structure.  The reason for the overwrite being
that the kernel timex has 64-bit fields and user space code only
allocates enough stack space for timex with 32-bit fields.

On 32-bit systems with TIMESIZE=64 __USE_TIME_BITS64 is not defined.
This causes the timex structure to use 32-bit fields with type
__syscall_slong_t.

This patch adjusts the ifdef condition to allow 32-bit systems with
TIMESIZE=64 to use the 64-bit long long timex definition.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

(Cherry picked from commit 1d550265a7)
2021-10-18 17:45:42 -03:00
Adhemerval Zanella
76843f3b3e y2038: Use a common definition for stat for sparc32
The sparc32 misses support for support done by 4e8521333b.

Checked on sparcv9-linux-gnu.

(cherry picked from commit d2b1254db2)
2021-10-18 17:44:16 -03:00
H.J. Lu
79528414dc elf: Replace nsid with args.nsid [BZ #27609]
commit ec935dea63
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Apr 24 22:31:15 2020 +0200

    elf: Implement __libc_early_init

has

@@ -856,6 +876,11 @@ no more namespaces available for dlmopen()"));
   /* See if an error occurred during loading.  */
   if (__glibc_unlikely (exception.errstring != NULL))
     {
+      /* Avoid keeping around a dangling reference to the libc.so link
+   map in case it has been cached in libc_map.  */
+      if (!args.libc_already_loaded)
+  GL(dl_ns)[nsid].libc_map = NULL;
+

do_dlopen calls _dl_open with nsid == __LM_ID_CALLER (-2), which calls
dl_open_worker with args.nsid = nsid.  dl_open_worker updates args.nsid
if it is __LM_ID_CALLER.  After dl_open_worker returns, it is wrong to
use nsid.

Replace nsid with args.nsid after dl_open_worker returns.  This fixes
BZ #27609.

(cherry picked from commit 1e1ecea62e)
2021-10-13 05:03:44 -07:00
Stefan Liebler
cb44a620ef S390: Add PCI_MIO and SIE HWCAPs
Both new HWCAPs were introduced in these kernel commits:
- 7e8403ecaf884f307b627f3c371475913dd29292
  "s390: add HWCAP_S390_PCI_MIO to ELF hwcaps"
- 7e82523f2583e9813e4109df3656707162541297
  "s390/hwcaps: make sie capability regular hwcap"

Also note that the kernel commit 511ad531afd4090625def4d9aba1f5227bd44b8e
"s390/hwcaps: shorten HWCAP defines" has shortened the prefix of the macros
from "HWCAP_S390_" to "HWCAP_".  For compatibility reasons, we do not
change the prefix in public glibc header file.

(cherry picked from commit f2e06656d0)
2021-10-07 06:59:31 +02:00
Siddhesh Poyarekar
558168c78e support: Also return fd when it is 0
The fd validity check in open_dev_null checks if fd > 0, which would
lead to a leaked fd if it is == 0.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit 27b6edbb09)
2021-10-06 22:26:05 +05:30
Florian Weimer
a996d13b8a Add missing braces to bsearch inline implementation [BZ #28400]
GCC treats the pragma as a statement, so that the else branch only
consists of the pragma, not the return statement.

Fixes commit a725ff1de9 ("Suppress
-Wcast-qual warnings in bsearch").

Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 32b96d0dec)
2021-10-01 18:20:12 +02:00
Jonathan Wakely
80a009119b Suppress -Wcast-qual warnings in bsearch
The first cast to (void *) is redundant but should be (const void *)
anyway, because that's the type of the lvalue being assigned to.

The second cast is necessary and intentionally not const-correct, so
tell the compiler not to warn about it.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
(cherry picked from commit a725ff1de9)
2021-10-01 18:20:12 +02:00
Adhemerval Zanella
822662cf2a linux: Revert the use of sched_getaffinity on get_nproc (BZ #28310)
The use of sched_getaffinity on get_nproc and
sysconf (_SC_NPROCESSORS_ONLN) done in 903bc7dcc2 (BZ #27645)
breaks the top command in common hypervisor configurations and also
other monitoring tools.

The main issue using sched_getaffinity changed the symbols semantic
from system-wide scope of online CPUs to per-process one (which can
be changed with kernel cpusets or book parameters in VM).

This patch reverts mostly of the 903bc7dcc2, with the
exceptions:

  * No more cached values and atomic updates, since they are inherent
    racy.

  * No /proc/cpuinfo fallback, since /proc/stat is already used and
    it would require to revert more arch-specific code.

  * The alloca is replace with a static buffer of 1024 bytes.

So the implementation first consult the sysfs, and fallbacks to procfs.

Checked on x86_64-linux-gnu.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
(cherry picked from commit 342298278e)
2021-10-01 18:19:45 +02:00
Adhemerval Zanella
cda99af14e linux: Simplify get_nprocs
This patch simplifies the memory allocation code and uses the sched
routines instead of reimplement it.  This still uses a stack
allocation buffer, so it can be used on malloc initialization code.

Linux currently supports at maximum of 4096 cpus for most architectures:

$ find -iname Kconfig | xargs git grep -A10 -w NR_CPUS | grep -w range
arch/alpha/Kconfig-	range 2 32
arch/arc/Kconfig-	range 2 4096
arch/arm/Kconfig-	range 2 16 if DEBUG_KMAP_LOCAL
arch/arm/Kconfig-	range 2 32 if !DEBUG_KMAP_LOCAL
arch/arm64/Kconfig-	range 2 4096
arch/csky/Kconfig-	range 2 32
arch/hexagon/Kconfig-	range 2 6 if SMP
arch/ia64/Kconfig-	range 2 4096
arch/mips/Kconfig-	range 2 256
arch/openrisc/Kconfig-	range 2 32
arch/parisc/Kconfig-	range 2 32
arch/riscv/Kconfig-	range 2 32
arch/s390/Kconfig-	range 2 512
arch/sh/Kconfig-	range 2 32
arch/sparc/Kconfig-	range 2 32 if SPARC32
arch/sparc/Kconfig-	range 2 4096 if SPARC64
arch/um/Kconfig-	range 1 1
arch/x86/Kconfig-# [NR_CPUS_RANGE_BEGIN ... NR_CPUS_RANGE_END] range.
arch/x86/Kconfig-	range NR_CPUS_RANGE_BEGIN NR_CPUS_RANGE_END
arch/xtensa/Kconfig-	range 2 32

With x86 supporting 8192:

arch/x86/Kconfig
 976 config NR_CPUS_RANGE_END
 977         int
 978         depends on X86_64
 979         default 8192 if  SMP && CPUMASK_OFFSTACK
 980         default  512 if  SMP && !CPUMASK_OFFSTACK
 981         default    1 if !SMP

So using a maximum of 32k cpu should cover all cases (and I would
expect once we start to have many more CPUs that Linux would provide
a more straightforward way to query for such information).

A test is added to check if sched_getaffinity can successfully return
with large buffers.

Checked on x86_64-linux-gnu and i686-linux-gnu.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
(cherry picked from commit 33099d72e4)
2021-10-01 18:19:10 +02:00
Adhemerval Zanella
e870aac897 misc: Add __get_nprocs_sched
This is an internal function meant to return the number of avaliable
processor where the process can scheduled, different than the
__get_nprocs which returns a the system available online CPU.

The Linux implementation currently only calls __get_nprocs(), which
in tuns calls sched_getaffinity.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
(cherry picked from commit 11a02b035b)
2021-10-01 18:19:09 +02:00
Florian Weimer
40bade26d5 nptl: pthread_kill must send signals to a specific thread [BZ #28407]
The choice between the kill vs tgkill system calls is not just about
the TID reuse race, but also about whether the signal is sent to the
whole process (and any thread in it) or to a specific thread.

This was caught by the openposix test suite:

  LTP: openposix test suite - FAIL: SIGUSR1 is member of new thread pendingset.
  <https://gitlab.com/cki-project/kernel-tests/-/issues/764>

Fixes commit 526c3cf11e ("nptl: Fix race
between pthread_kill and thread exit (bug 12889)").

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit eae81d7057)
2021-10-01 18:18:15 +02:00
Florian Weimer
4bf7251998 support: Add check for TID zero in support_wait_for_thread_exit
Some kernel versions (observed with kernel 5.14 and earlier) can list
"0" entries in /proc/self/task.  This happens when a thread exits
while the task list is being constructed.  Treat this entry as not
present, like the proposed kernel patch does:

[PATCH] procfs: Do not list TID 0 in /proc/<pid>/task
<https://lore.kernel.org/all/8735pn5dx7.fsf@oldenburg.str.redhat.com/>

Fixes commit 032d74eaf6 ("support: Add
support_wait_for_thread_exit").

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 176c88f521)
2021-10-01 18:17:19 +02:00
Florian Weimer
33adeaa3e2 nptl: Avoid setxid deadlock with blocked signals in thread exit [BZ #28361]
As part of the fix for bug 12889, signals are blocked during
thread exit, so that application code cannot run on the thread that
is about to exit.  This would cause problems if the application
expected signals to be delivered after the signal handler revealed
the thread to still exist, despite pthread_kill can no longer be used
to send signals to it.  However, glibc internally uses the SIGSETXID
signal in a way that is incompatible with signal blocking, due to the
way the setxid handshake delays thread exit until the setxid operation
has completed.  With a blocked SIGSETXID, the handshake can never
complete, causing a deadlock.

As a band-aid, restore the previous handshake protocol by not blocking
SIGSETXID during thread exit.

The new test sysdeps/pthread/tst-pthread-setuid-loop.c is based on
a downstream test by Martin Osvald.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 2849e2f533)
2021-09-23 11:02:19 +02:00
Adhemerval Zanella
772e33411b Use support_open_dev_null_range io/tst-closefrom, misc/tst-close_range, and posix/tst-spawn5 (BZ #28260)
It ensures a continuous range of file descriptor and avoid hitting
the RLIMIT_NOFILE.

Checked on x86_64-linux-gnu.

(cherry picked from commit 6b20880b22)
2021-09-21 22:26:26 +12:00
Adhemerval Zanella
5ad589d63b support: Add support_open_dev_null_range
It returns a range of file descriptor referring to the '/dev/null'
pathname.  The function takes care of restarting the open range
if a file descriptor is found within the specified range and
also increases RLIMIT_NOFILE if required.

Checked on x86_64-linux-gnu.

(cherry picked from commit e814f4b04e)
2021-09-21 22:26:26 +12:00
Florian Weimer
8b8a1d0b73 nptl: Fix type of pthread_mutexattr_getrobust_np, pthread_mutexattr_setrobust_np (bug 28036)
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit f3e6645633)
2021-09-21 07:15:25 +02:00
Florian Weimer
73c7f5a879 nptl: pthread_kill needs to return ESRCH for old programs (bug 19193)
The fix for bug 19193 breaks some old applications which appear
to use pthread_kill to probe if a thread is still running, something
that is not supported by POSIX.

(cherry picked from commit 95dba35bf0)
2021-09-20 14:58:57 +02:00
Aurelien Jarno
433ec4f14a posix: Fix attribute access mode on getcwd [BZ #27476]
There is a GNU extension that allows to call getcwd(NULL, >0). It is
described in the documentation, but also directly in the unistd.h
header, just above the declaration.

Therefore the attribute access mode added in commit 06febd8c67
is not correct. Drop it.
2021-09-19 18:45:38 +02:00
Joseph Myers
4ed990e5b9 Add MADV_POPULATE_READ and MADV_POPULATE_WRITE from Linux 5.14 to bits/mman-linux.h
Linux 5.14 adds constants MADV_POPULATE_READ and MADV_POPULATE_WRITE
(with the same values on all architectures).  Add these to glibc's
bits/mman-linux.h.

Tested for x86_64.

(cherry picked from commit 3561106278)
2021-09-15 14:34:33 +02:00