From: Jann Horn <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Pavel Begunkov <[email protected]>,
[email protected], [email protected]
Subject: Re: [PATCH] io_uring/rsrc: Simplify buffer cloning by locking both rings
Date: Wed, 15 Jan 2025 21:20:12 +0100 [thread overview]
Message-ID: <CAG48ez3RG5iDrK4UWCjBWw9FTPCQK8NXK1wADo_VWWBatVpXBw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
On Wed, Jan 15, 2025 at 6:18 PM Jens Axboe <[email protected]> wrote:
> On 1/15/25 9:25 AM, Jann Horn wrote:
> > The locking in the buffer cloning code is somewhat complex because it goes
> > back and forth between locking the source ring and the destination ring.
> >
> > Make it easier to reason about by locking both rings at the same time.
> > To avoid ABBA deadlocks, lock the rings in ascending kernel address order,
> > just like in lock_two_nondirectories().
> >
> > Signed-off-by: Jann Horn <[email protected]>
> > ---
> > Just an idea for how I think io_clone_buffers() could be changed so it
> > becomes slightly easier to reason about.
> > I left the out_unlock jump label with its current name for now, though
> > I guess that should probably be adjusted.
>
> Looks pretty clean to me, and does make it easier to reason about. Only
> thing that stuck out to me was:
>
> > @@ -1067,7 +1060,18 @@ int io_register_clone_buffers(struct io_ring_ctx *ctx, void __user *arg)
> > file = io_uring_register_get_file(buf.src_fd, registered_src);
> > if (IS_ERR(file))
> > return PTR_ERR(file);
> > - ret = io_clone_buffers(ctx, file->private_data, &buf);
> > + src_ctx = file->private_data;
> > + if (src_ctx == ctx) {
> > + ret = -ELOOP;
> > + goto out_put;
> > + }
>
> which is a change, as previously it would've been legal to do something ala:
>
> struct io_uring ring;
> struct iovec vecs[2];
>
> vecs[0] = real_buffer;
> vecs[1] = sparse_buffer;
>
> io_uring_register_buffers(&ring, vecs, 2);
>
> io_uring_clone_buffers_offset(&ring, &ring, 1, 0, 1, IORING_REGISTER_DST_REPLACE);
>
> and clone vecs[0] into slot 1. With the patch, that'll return -ELOOP instead.
>
> Maybe something like the below incremental, to just make the unlock +
> double lock depending on whether they are different or not? And also
> cleaning up the label naming at the same time.
Yeah, looks good to me. If nobody else has review feedback, do you
want to fold that in locally? If there's more feedback, I'll fold that
incremental into my v2.
next prev parent reply other threads:[~2025-01-15 20:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 16:25 [PATCH] io_uring/rsrc: Simplify buffer cloning by locking both rings Jann Horn
2025-01-15 17:18 ` Jens Axboe
2025-01-15 20:20 ` Jann Horn [this message]
2025-01-15 20:22 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAG48ez3RG5iDrK4UWCjBWw9FTPCQK8NXK1wADo_VWWBatVpXBw@mail.gmail.com \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox