Both new tests io/tst-stat and io/tst-stat-lfs (_FILE_OFFSET_BITS=64)
are comparing the nanosecond fields with the statx result. Unfortunately
on s390(31bit) those fields are always zero if old KABI with non-LFS
support is used. With _FILE_OFFSET_BITS=64 stat is using statx internally.
As suggested by Adhemerval this patch disables the nanosecond check for
s390(31bit).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Some Linux filesystems might not fully support 64 bit timestamps [1],
which make some Linux specific tests to fail when they check for the
functionality.
This patch adds a new libsupport function, support_path_support_time64,
that returns whether the target file supports or not 64 bit timestamps.
The support is checked by issuing a utimensat and verifying both the
last access and last modification time against a statx call.
The tests that might fail are also adjusted to check the file support
as well:
$ dd if=/dev/zero of=loopbackfile.img bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0,0589568 s, 1,8 GB/s
$ sudo losetup -fP loopbackfile.img
$ mkfs.xfs loopbackfile.img
meta-data=loopbackfile.img isize=512 agcount=4, agsize=6400 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1
data = bsize=4096 blocks=25600, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=1368, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ mkdir loopfs
$ sudo mount -o loop /dev/loop0 loopfs/
$ sudo chown -R azanella:azanella loopfs
$ TMPDIR=loopfs/ ./testrun.sh misc/tst-utimes
error: ../sysdeps/unix/sysv/linux/tst-utimes.c:55: File loopfs//utimesfECsK1 does not support 64-bit timestamps
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1795576
There's a small chance that a fresh checkout will result in some of
the test-specific container files will have the same timestamp and
size, which breaks the rsync logic in test-container, resulting in
tests running with the wrong support files.
This patch changes the rsync logic to always copy the test-specific
files, which normally would always be copied anyway. The rsync logic
for the testroot itself is unchanged.
The xclock_settime is a wrapper function on the clock_settime syscall
to be used in the test code.
It checks if the GLIBC_TEST_ALLOW_TIME_SETTING env variable is defined
in the environment in which test is executed. If it is not - the test
ends as unsupported. Otherwise, the clock-settime is executed and return
value is assessed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
For configurations with cross-compiling equal to 'maybe' or 'no',
ldconfig will not run and thus the ld.so.cache will not be created
on the container testroot.pristine.
This lead to failures on both tst-glibc-hwcaps-prepend-cache and
tst-ldconfig-ld_so_conf-update on environments where the same
compiler can be used to build different ABIs (powerpc and x86 for
instance).
This patch addas a new test-container hook, ldconfig.run, that
triggers a ldconfig execution prior the test execution.
Checked on x86_64-linux-gnu and i686-linux-gnu.
POSIX states that system returned code for failure to execute the shell
shall be as if the shell had terminated using _exit(127). This
behaviour was removed with 5fb7fc9635.
Checked on x86_64-linux-gnu.
I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 6694 files FOO.
I then removed trailing white space from benchtests/bench-pthread-locks.c
and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this
diagnostic from Savannah:
remote: *** pre-commit check failed ...
remote: *** error: lines with trailing whitespace found
remote: error: hook declined to update refs/heads/master
Tests such as posix/tst-waitid.c make heavy use of
support_process_state_wait, and thus on non-Linux where it falls back
to sleeping, a 2s sleep makes such test time out, while 1s remains
fine enough.
commit 04deeaa9ea
Author: Lucas A. M. Magalhaes <lamm@linux.ibm.com>
Date: Fri Jul 10 19:41:06 2020 -0300
Fix time/tst-cpuclock1 intermitent failures
has 2 issues:
1. It assumes time_t == long which is false on x32.
2. tst-timespec.c is compiled without -fexcess-precision=standard which
generates incorrect results on i686 in support_timespec_check_in_range:
double ratio = (double)observed_norm / expected_norm;
return (lower_bound <= ratio && ratio <= upper_bound);
This patch does
1. Compile tst-timespec.c with -fexcess-precision=standard.
2. Replace long with time_t.
3. Replace LONG_MIN and LONG_MAX with TYPE_MINIMUM (time_t) and
TYPE_MAXIMUM (time_t).
This test fails intermittently in systems with heavy load as
CLOCK_PROCESS_CPUTIME_ID is subject to scheduler pressure. Thus the
test boundaries were relaxed to keep it from failing on such systems.
A refactor of the spent time checking was made with some support
functions. With the advantage to representing time jitter in percent
of the target.
The values used by the test boundaries are all empirical.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
and s390x-linux-gnu.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
When detecting hole support, we write at 16MiB, and filesystems will
typically need two levels of data to record that. On filesystems with
8KB block, the two indirection blocks will require a total of 16KB
overhead, thus 32 512-byte sectors.
Spotted on GNU/Hurd with a 4KB blocks filesystem, but also happens on Linux
with 4KB or 8KB blocks filesystems.
* support/support_descriptor_supports_holes.c
(support_descriptor_supports_holes): Set block_headroom to 32.
In test-conainer we should set errno to 0 before calling strtol,
and check after with TEST_COMPARE.
In tst-support_capture_subprocess we should set errno to 0 before
checking it after the call to strtol.
Tested on x86_64.
Reviewed-by: DJ Delorie <dj@redhat.com>
Expand the support infrastructure:
- Create $(complocaledir) in the testroot.pristine to support localedef.
- Add the variable $complocaledir to script support.
- Add the script command 'mkdirp'.
All localedef tests which run with default paths need to have the
$(complocaledir) created in testroot.pristine. The localedef binary
will not by itself create the default path, but it will write into
the path. By adding this we can simplify the localedef tests.
The variable $complocaledir is the value of the configured
$(complocaledir) which is the location of the compiled locales that
will be searched by the runtime by default.
The command mkdirp will be available in script setup and will
be equivalent to running `mkdir -p`.
The variable and command can be used to write more complex tests.
Reviewed-by: DJ Delorie <dj@redhat.com>
During testing of localedef running in a minimal container
there were several error cases which were hard to diagnose
since they appeared as strerror (errno) values printed by the
higher level functions. This change adds three new verbose
messages for potential failure paths. The new messages give
the user the opportunity to use -v and display additional
information about why localedef might be failing. I found
these messages useful myself while writing a localedef
container test for --no-hard-links.
Since the changes cleanup the code that handle codeset
normalization we add tst-localedef-path-norm which contains
many sub-tests to verify the correct expected normalization of
codeset strings both when installing to default paths (the
only time normalization is enabled) and installing to absolute
paths. During the refactoring I created at least one
buffer-overflow which valgrind caught, but these tests did not
catch because the exec in the container had a very clean heap
with zero-initialized memory. However, between valgrind and
the tests the results are clean.
The new tst-localedef-path-norm passes without regression on
x86_64.
Change-Id: I28b9f680711ff00252a2cb15625b774cc58ecb9d
The advantage is that the buffer will always contain the number
of characters as returned from the function, which allows one to use
a sequence like
/* No more audit module output. */
line_length = xgetline (&buffer, &buffer_length, fp);
TEST_COMPARE_BLOB ("", 0, buffer, line_length);
to check for an expected EOF, while also reporting any unexpected
extra data encountered.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
I'm debugging a situation where lots of tests using test-container fail
and it's possible knowing errno would help understand why.
Reviewed-by: DJ Delorie <dj@redhat.com>
It allows parent process to wait for child state using a polling
strategy over procfs on Linux. The polling is used over ptrace to
avoid the need to handle signals on the target pid and to handle some
system specific limitation (such as YAMA).
The polling has some limitations, such as resource consumption due
the procfs read in a loop and the lack of synchronization after the
state is obtained.
The interface idea is to simplify some sleep synchronization waitid
tests and is to reduce timeouts by replacing arbitrary waits.
exec <path_to_test_binary> [optional_argv_0]
copies test binary to specified location and runs it from
there. If the second argument is provided, that will
be used for argv[0]
cwd <directory>
attempts to chdir(directory) before running test
Note: "cwd" not "cd" as it takes effect just before the
test binary runs, not when it's encountered in the script,
so it can't be used as a path shortcut like "cd" would imply.
cleanup: use xstrdup() instead of strdup()
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This introduces a concept of trusted name servers, for which the
AD bit is passed through to applications. For untrusted name
servers (the default), the AD bit in responses are cleared, to
provide a safe default.
This approach is very similar to the one suggested by Pavel Šimerda
in <https://bugzilla.redhat.com/show_bug.cgi?id=1164339#c15>.
The DNS test framework in support/ is enhanced with support for
setting the AD bit in responses.
Tested on x86_64-linux-gnu.
Change-Id: Ibfe0f7c73ea221c35979842c5c3b6ed486495ccc
PTHREAD_STACK_MIN comes from <limits.h>, so include it explicitly.
However, it is not defined on Hurd, so compensate for that as well.
Built on x86_64-linux-gnu, i686-linux-gnu, i686-gnu.
Change-Id: Ifacc888ef86731c2639721b0932ae59583bd6b3e
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Since gettimeofday will shortly be implemented in terms of
clock_gettime on all platforms, internal code should use clock_gettime
directly; in addition to removing a layer of indirection, this will
allow us to remove the PLT-bypass gunk for gettimeofday. (We can't
quite do that yet, but it'll be coming later in this patch series.)
In many cases, the changed code does fewer conversions.
The changed code always assumes __clock_gettime (CLOCK_REALTIME)
cannot fail. Most of the call sites were assuming gettimeofday could
not fail, but a few places were checking for errors. POSIX says
clock_gettime can only fail if the clock constant is invalid or
unsupported, and CLOCK_REALTIME is the one and only clock constant
that's required to be supported. For consistency I grepped the entire
source tree for any other places that checked for errors from
__clock_gettime (CLOCK_REALTIME), found one, and changed it too.
(For the record, POSIX also says gettimeofday can never fail.)
(It would be nice if we could declare that GNU systems will always
support CLOCK_MONOTONIC as well as CLOCK_REALTIME; there are several
places where we are using CLOCK_REALTIME where _MONOTONIC would be
more appropriate, and/or trying to use _MONOTONIC and then falling
back to _REALTIME. But the Hurd doesn't support CLOCK_MONOTONIC yet,
and it looks like adding it would involve substantial changes to
gnumach's internals and API. Oh well.)
A few Hurd-specific files were changed to use __host_get_time instead
of __clock_gettime, as this seemed tidier. We also assume this cannot
fail. Skimming the code in gnumach leads me to believe the only way
it could fail is if __mach_host_self also failed, and our
Hurd-specific code consistently assumes that can't happen, so I'm
going with that.
With the exception of support/support_test_main.c, test cases are not
modified, mainly because I didn't want to have to figure out which
test cases were testing gettimeofday specifically.
The definition of GETTIME in sysdeps/generic/memusage.h had a typo and
was not reading tv_sec at all. I fixed this. It appears nobody has been
generating malloc traces on a machine that doesn't have a superseding
definition.
There are a whole bunch of places where the code could be simplified
by factoring out timespec subtraction and/or comparison logic, but I
want to keep this patch as mechanical as possible.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
If WAIT_FOR_DEBUGGER is set to a non-zero value in the environment,
any test that runs will print some useful gdb information and wait
for gdb to attach to it and clear the "wait_for_debugger" variable.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
On i686-gnu the build is broken:
In file included from support_ptrace.c:22:
../include/sys/prctl.h:2:15: fatal error: sys/prctl.h: No such file or directory
#include_next <sys/prctl.h>
This patch just removes the unused prctl.h inclusion.
ChangeLog:
* support/support_ptrace.c: Remove inclusion of sys/prctl.h.
The testcase forks a child process and runs pldd with PID of
this child. On systems where /proc/sys/kernel/yama/ptrace_scope
differs from zero, pldd will fail with
/usr/bin/pldd: cannot attach to process 3: Operation not permitted
This patch checks if ptrace_scope exists, is zero "classic ptrace permissions"
or one "restricted ptrace". If ptrace_scope exists and has a higher
restriction, then the test is marked as UNSUPPORTED.
The case "restricted ptrace" is handled by rearranging the processes involved
during the test. Now we have the following process tree:
-parent: do_test (performs output checks)
--subprocess 1: pldd_process (becomes pldd via execve)
---subprocess 2: target_process (ptraced via pldd)
ChangeLog:
* elf/tst-pldd.c (do_test): Add UNSUPPORTED check.
Rearrange subprocesses.
(pldd_process): New function.
* support/Makefile (libsupport-routines): Add support_ptrace.
* support/xptrace.h: New file.
* support/support_ptrace.c: Likewise.
