From: Jens Axboe <axboe@kernel.dk>
To: Bertie Tryner <bertietryner@gmail.com>, io-uring@vger.kernel.org
Cc: asml.silence@gmail.com, Bertie Tryner <Bertie.Tryner@warwick.ac.uk>
Subject: Re: [PATCH] io_uring/zcrx: reorder fd allocation and disclosure in zcrx_export()
Date: Mon, 6 Apr 2026 10:20:07 -0600 [thread overview]
Message-ID: <7e4d8e97-850a-40e7-94e8-e82dd56c0386@kernel.dk> (raw)
In-Reply-To: <20260405235330.49287-1-Bertie.Tryner@warwick.ac.uk>
On 4/5/26 5:53 PM, Bertie Tryner wrote:
> Currently, zcrx_export() allocates and discloses a file descriptor to
> userspace before the backing file is successfully created. If file
> creation fails, the fd is released back to the pool, but the number
> has already been written to the user-provided control structure.
>
> While this requires a misbehaving or racing userspace to trigger,
> it is better practice to ensure the file descriptor is only
> disclosed once the operation is guaranteed to succeed. This aligns
> the ZCRX export logic with the standard patterns used in the VFS
> layer and other fd-publishing paths.
Like I explained earlier, there's no "race" here at all. The file is
never visible until fd_install() has been done. Any attempt to use the
fd before that happens will get a NULL file in the kernel, and the IO
operation failed.
The operation clearly fails, and the error is returned to the
application. If the application is so buggy that it ignores that and
wants to use the 'fd' value, then it's just buggy. Simple as that, do
stupid things and win stupid prizes.
As a cleanup, this is fine. But the commit message is horribly
(deliberately?) misleading and that should get fixed. I'll let Pavel
decide what to do with this change.
--
Jens Axboe
next prev parent reply other threads:[~2026-04-06 16:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 23:53 [PATCH] io_uring/zcrx: reorder fd allocation and disclosure in zcrx_export() Bertie Tryner
2026-04-06 16:20 ` Jens Axboe [this message]
[not found] ` <VE1PR01MB12289E1FFAD5D850361B58232B15DA@VE1PR01MB12289.eurprd01.prod.exchangelabs.com>
2026-04-06 17:11 ` TRYNER, BERTIE (UG)
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=7e4d8e97-850a-40e7-94e8-e82dd56c0386@kernel.dk \
--to=axboe@kernel.dk \
--cc=Bertie.Tryner@warwick.ac.uk \
--cc=asml.silence@gmail.com \
--cc=bertietryner@gmail.com \
--cc=io-uring@vger.kernel.org \
/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