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
