On 12/9/24 00:16, Pavel Begunkov wrote: > On 12/6/24 11:36, Bernd Schubert wrote: >> On 12/3/24 15:32, Bernd Schubert wrote: >>> On 12/3/24 15:24, Pavel Begunkov wrote: >>>> On 11/27/24 13:40, Bernd Schubert wrote: >>>>> [I removed RFC status as the design should be in place now >>>>> and as xfstests pass. I still reviewing patches myself, though >>>>> and also repeatings tests with different queue sizes.] >>>> >>>> I left a few comments, but it looks sane. At least on the io_uring >>>> side nothing weird caught my eye. Cancellations might be a bit >>>> worrisome as usual, so would be nice to give it a good run with >>>> sanitizers. >>> >>> Thanks a lot for your reviews, new series is in preparation, will >>> send it out tomorrow to give a test run over night. I'm >>> running xfstests on a kernel that has lockdep and ASAN enabled, which >>> is why it takes around 15 hours (with/without FOPEN_DIRECT_IO). >> >> I found a few issues myself and somehow xfstests take more >> than twice as long right with 6.13 *and a slightly different kernel >> config. Still waiting for test completion. >> >> >> I have a question actually regarding patch 15 that handles >> IO_URING_F_CANCEL. I think there there is a race in v7 and before, >> as the fuse entry state FRRS_WAIT might not have been reached _yet_ >> and then io_uring_cmd_done() would not be called. >> Can I do it like this in fuse_uring_cancel() > > A IO_URING_F_CANCEL doesn't cancel a request nor removes it > from io_uring's cancellation list, io_uring_cmd_done() does. > You might also be getting multiple IO_URING_F_CANCEL calls for > a request until the request is released. Perfect, thank you!
