Re: [PATCH RFC v7 00/16] fuse: fuse-over-io-uring

Bernd Schubert
2024-12-09T08:02:14Z

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!