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

[Sam James]

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