[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74cac804-27b5-4d25-9055-5e4b85be20d6@davidwei.uk>
Date: Tue, 28 Oct 2025 07:54:59 -0700
From: David Wei <dw@...idwei.uk>
To: Pavel Begunkov <asml.silence@...il.com>, io-uring@...r.kernel.org,
netdev@...r.kernel.org
Cc: Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v3 1/3] io_uring/rsrc: rename and export
io_lock_two_rings()
On 2025-10-27 03:04, Pavel Begunkov wrote:
> On 10/26/25 17:34, David Wei wrote:
>> Rename lock_two_rings() to io_lock_two_rings() and export. This will be
>> used when sharing a src ifq owned by one ring with another ring. During
>> this process both rings need to be locked in a deterministic order,
>> similar to the current user io_clone_buffers().
>
> unlock();
> double_lock();
>
> It's quite a bad pattern just like any temporary unlocks in the
> registration path, it gives a lot of space for exploitation.
>
> Ideally, it'd be
>
> lock(ctx1);
> zcrx = grab_zcrx(ctx1, id); // with some refcounting inside
> unlock(ctx1);
>
> lock(ctx2);
> install(ctx2, zcrx);
> unlock(ctx2);
Thanks, I've refactored this to lock rings in sequence instead of both
rings.
>
> And as discussed, we need to think about turning it into a temp
> file, bc of sync, and it's also hard to send an io_uring fd.
> Though, that'd need moving bits around to avoid refcounting
> cycles.
>
My next version of this adds a refcount to ifq and decouple its lifetime
from ring ctx as a first step. Could we defer turning ifq into a file as
a follow up?
Powered by blists - more mailing lists