On 03/02/2022 16:58, Jens Axboe wrote:
On 2/3/22 9:49 AM, Usama Arif wrote:
One thing that both mine and your version suffers from is if someone
does an eventfd unregister, and then immediately does an eventfd
register. If the rcu grace period hasn't passed, we'll get -EBUSY on
trying to do that, when I think the right behavior there would be to
wait for the grace period to pass.
I do think we need to handle that gracefully, spurious -EBUSY is
impossible for an application to deal with.
I don't think my version would suffer from this as its protected by
locks? The mutex_unlock on ev_fd_lock in unregister happens only after
the call_rcu. And the mutex is locked in io_eventfd_register at the
start, so wouldnt get the -EBUSY if there is a register immediately
after unregister?
The call_rcu() just registers it for getting the callback when the grace
period has passed, it doesn't mean it's done by the time it returns.
Hence there's definitely a window where you can enter
io_uring_register() with the callback still being pending, and you'd get
-EBUSY from that.
Does using synchronize_rcu make sense? I have sent v3 with how that
would look. I have kept cq_ev_fd under io_ev_fd as it will be useful in
patch 3 when eventfd_async is added.
Thanks,
Usama
