[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils
Subject:    Re: coreutils-9.1.198-e68b1.tar.xz on Linux/s390
From:       Pádraig_Brady <P () draigBrady ! com>
Date:       2023-03-20 3:29:17
Message-ID: d2afca35-dbaf-b0bb-ada5-3b44e47951b0 () draigBrady ! com
[Download RAW message or body]

On 20/03/2023 01:31, Sam James wrote:
> 
> Pádraig Brady <P@draigBrady.com> writes:
> 
> > On 18/03/2023 23:39, Sam James wrote:
> > > Pádraig Brady <P@draigBrady.com> writes:
> > > 
> > > > On 18/03/2023 22:55, Sam James wrote:
> > > > > Pádraig Brady <P@draigBrady.com> writes:
> > > > > 
> > > > > > On 16/03/2023 20:44, Sam James wrote:
> > > > > > > # grep -rsin "FAIL:"
> > > > > > > /var/tmp/portage/sys-apps/coreutils-9.1_p20230313/temp/build.log
> > > > > > > 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 http://sprunge.us/G0TUET. 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?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e412ac4971d27ea84f3d63ce425c6ab2d6a67f23
> >  
> > 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 \
> > status=none
> 
> 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);
> }
> ```
> 
> with
> ```
> [...]
> 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.
> 
> best,
> sam

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`)

cheers,
Pádraig


[prev in list] [next in list] [prev in thread] [next in thread]