Re: io_uring failure on parisc with VIPT caches

[Jens Axboe <axboe@kernel.dk>]

On 2/15/23 10:01?AM, Jens Axboe wrote:
> On 2/15/23 9:38?AM, John David Anglin wrote:
>> On 2023-02-15 10:56 a.m., Jens Axboe wrote:
>>>> Is there maybe somewhere a more detailled testcase which I could try too?
>>> Just git clone liburing:
>>>
>>> git clone git://git.kernel.dk/liburing
>>>
>>> and run make && make runtests in there, that'll go through the whole
>>> regression suite.
>> Here are test results for Debian liburing 2.3-3 (hppa) with Helge's original patch:
>> https://buildd.debian.org/status/fetch.php?pkg=liburing&arch=hppa&ver=2.3-3&stamp=1676478898&raw=0
> 
> Most of the test failures seem to be related to O_DIRECT opens, which
> I'm guessing is because it's run on an fs without O_DIRECT support?
> Outside of that, I think some of the syzbot cases are just generally
> broken on various archs.
> 
> Lastly, there's a few of these:
> 
> Running test buf-ring.t                                             bad run 0/0 = -233
> 
> and similar (like -223) which I really don't know what is, where do
> these values come from? Ah hang on, they are in the parisc errno,
> so that'd be -ENOBUFS and -EOPNOTSUPP. I wonder if there's some
> discrepancy between the kernel and user side errno values here?

I ran the tests in qemu, but didn't see the weird differences in errno
values here between the kernel and userspace. As an example of the above
one:

root@debian:~/liburing# test/buf-ring.t 
root@debian:~/liburing# echo $?
0

it runs fine here. The other failure cases:

917257daa0fe.t: this is due to syzbot using hard wired values, I changed
it to symbolic mmap flags, and ditto for all the other tests where that
was the issue.

accept.t: setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val));
fails here, no idea why.

xattr.t: works for me

The rest look like either errno value mismatches, or O_DIRECT not
working for you. This was tested with 6.2-rc7+ git, so a recent kernel.

-- 
Jens Axboe