On 9/10/24 9:37 AM, MOESSBAUER, Felix wrote: > On Tue, 2024-09-10 at 09:17 -0600, Jens Axboe wrote: >> On 9/10/24 9:08 AM, MOESSBAUER, Felix wrote: >>> On Tue, 2024-09-10 at 08:53 -0600, Jens Axboe wrote: >>>> On 9/10/24 8:33 AM, Felix Moessbauer wrote: >>>>> Hi, >>>>> >>>>> this series continues the affinity cleanup work started in >>>>> io_uring/sqpoll. It has been tested against the liburing >>>>> testsuite >>>>> (make runtests), whereby the read-mshot test always fails: >>>>> >>>>> Running test read-mshot.t >>>>> Buffer ring register failed -22 >>>>> test_inc 0 0 >>>>> failed >>>>> >>>>> >>>>> Test read-mshot.t failed with ret 1 >>>>> >>>>> However, this test also fails on a non-patched linux-next @ >>>>> bc83b4d1f086. >>>> >>>> That sounds very odd... What liburing are you using? On old >>>> kernels >>>> where provided buffer rings aren't available the test should just >>>> skip, >>>> new ones it should pass. Only thing I can think of is that your >>>> liburing >>>> repo isn't current? >>> >>> Hmm... I tested against >>> https://github.com/axboe/liburing/commit/74fefa1b51ee35a2014ca6e7667d7c10e9c5b06f >> >> That should certainly be fine. >> >>> I'll redo the test against the unpatched kernel to be 100% sure >>> that it >>> is not related to my patches. The -22 is likely an -EINVAL. >> >> I'd be highly surprised if it's related to your patches! Here's what >> I >> get on the current kernel: >> >> axboe@m2max-kvm ~/g/liburing (master)> test/read-mshot.t >> axboe@m2max-kvm ~/g/liburing (master)> echo $status > > Without your patches for liburing, this test definitely fails on linux- > next @ bc83b4d1f086 (in qemu). Same error as above. Some more > information: > $ uname -a > Linux test-iou 6.11.0-rc7 #1 SMP PREEMPT_DYNAMIC Thu, 01 Jan 1970 > 01:00:00 +0000 x86_64 GNU/Linux > > Strange... It could just be that I never tested that version on a kernel that has support for ring provided buffers, but not for incrementally consumed ones. Though that should be in -next for a while now, so even that doesn't make sense... Oh well, should work now. > By that, I assume my patches themselves are fine. I'll just update the > commit messages to fix the oddities and send a functionally identical > v2. Sounds good, thanks. -- Jens Axboe