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()
if (need_cmd_done) {
io_uring_cmd_done(cmd, -ENOTCONN, 0, issue_flags);
} else {
/*
* We don't check for the actual state, but let io-uring
* layer handle if re-sending the IO_URING_F_CANCEL SQE is still
* needed.
*/
ret = -EAGAIN;
}
I.e. lets assume umount races with IO_URING_F_CANCEL (for example umount
triggers a daemon crash). The umount process/task could now already do
or start to do io_uring_cmd_done and just around the same time and
IO_URING_F_CANCEL comes in.
My question is if io-uring knows that re-sending the
IO_URING_F_CANCEL is still needed or will it avoid re-sending if
io_uring_cmd_done() was already done?
I could also add state checking in the fuse_uring_cancel function.
Thanks,
Bernd
