[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils-9.1.198-e68b1.tar.xz on Linux/s390

From: Pádraig Brady
Subject: Re: coreutils-9.1.198-e68b1.tar.xz on Linux/s390
Date: Mon, 20 Mar 2023 03:29:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0

On 20/03/2023 01:31, Sam James wrote:

Pádraig Brady <> writes:

On 18/03/2023 23:39, Sam James wrote:
Pádraig Brady <> writes:

On 18/03/2023 22:55, Sam James wrote:
Pádraig Brady <> writes:

On 16/03/2023 20:44, Sam James wrote:
     # grep -rsin "FAIL:"
       8833:# XFAIL: 0
       8834:# FAIL:  3
       12578:FAIL: tests/misc/cksum-raw
       17775:FAIL: tests/df/df-symlink
       18973:FAIL: tests/dd/nocache_eof

For nocache_eof:
+ strace_dd if=in.f of=out.f bs=1M iflag=nocache oflag=nocache,sync
+ strace -o dd.strace -e fadvise64,fadvise64_64 dd status=none if=in.f
of=out.f bs=1M iflag=nocache oflag=nocache,sync
+ advised_to_eof
+ grep -F ' 0, POSIX_FADV_DONTNEED' dd.strace
+ fail=1

I suspect the fadvise64,fadvise64_64 strace filter isn't working on s390.
An unfiltered strace output from one of those dd commands would be useful.

See I chucked it in
for the other invocations too.

Interesting. So from strace's point of view
we're requesting POSIX_FADV_NORMAL rather than POSIX_FADV_DONTNEED.
POSIX_FADV_NORMAL is 0 which suggests to be some ABI issue
rather than an API or user logic issue.

For example perhaps there is some parameter conversion issue in the s390 kernel.
For e.g. the following bug fix may not have been applied to s390?

I also see in the glibc code that:
"s390 implements fadvice64_64 using a specific struct with arguments
packed inside.  This is the only implementation handled in arch-specific code."

The issue might even be in strace.

In any case nothing has changed on the coreutils side of things in this regard,
and there is no gnulib wrapping of this function either.

I suspect a separate simple C program that just calls posix_fadvise(...)
would be enough to repo, or if GNU dd is available the simplest check is:
   strace -e fadvise64,fadvise64_64 dd oflag=nocache if=/dev/null of=/dev/null 

I started to write up a report to the relevant kernel ML given:
(s390) # strace -e fadvise64,fadvise64_64 dd oflag=nocache if=/dev/null
of=/dev/null status=none
fadvise64_64(2142494232, 19186648160, 0, POSIX_FADV_NORMAL) = 0 # <--
POSIX_FADV_NORMAL is unexpected here! Should be POSIX_FADV_DONTNEED.

The initial args look messed up here also.

+++ exited with 0 +++

(s390x) # strace -e fadvise64,fadvise64_64 dd oflag=nocache if=/dev/null
of=/dev/null status=none
fadvise64(1, 0, 0, POSIX_FADV_DONTNEED) = 0
+++ exited with 0 +++

but when I tried to reproduce it in a small C program, I couldn't
(POSIX_FADV_DONTNEED) appeared as expected.

Would you mind crafting one that has the right expected behaviour?

I tried:
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int main() {
         char buf[1024];
         int fd = openat(AT_FDCWD, "/dev/null", O_CREAT|O_TRUNC, 0666);

         read(fd, buf, 1024);
         lseek(3, 512, SEEK_CUR);

         posix_fadvise(fd, 512, 1024, POSIX_FADV_DONTNEED);

openat(AT_FDCWD, "/dev/null", O_RDONLY|O_CREAT|O_TRUNC, 0666) = 3
read(3, "", 1024)                       = 0
_llseek(3, 512, [0], SEEK_CUR)          = 0
fadvise64(3, 512, 1024, POSIX_FADV_DONTNEED) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Mine didn't end up calling fadvise64_64, just fadvise64, so I imagine
that's the issue somehow. I'm guessing I'm missing something obvious
but I don't know what yet.


The difference I think is due to 32 compat mode
calling into the syscall supporting 64 bit offsets.
You can get that combo by compiling like this:
  gcc -m32 -D_FILE_OFFSET_BITS=64 pf.c

The 32 bit may be implicit on your system,
but on a standard 64 bit user space you need the explicit -m32
(which I enabled with `sudo dnf install /usr/include/gnu/stubs-32.h`)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]