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.
+++ 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
>
> cheers,
> Pádraig
signature.asc
Description: PGP signature
