From: Al Viro <viro@zeniv.linux.org.uk>
To: Gary Guo <gary@garyguo.net>
Cc: "Christian Brauner" <brauner@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Georgios Androutsopoulos" <georgeandrout13@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
linux-fsdevel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, "Al Viro" <viro@ftp.linux.org.uk>
Subject: Re: [PATCH v2] rust: file: handle fd table teardown in file descriptor APIs
Date: Tue, 29 Sep 2026 18:02:18 +0100 [thread overview]
Message-ID: <20260929170218.GD989762@ZenIV> (raw)
In-Reply-To: <DLRXHGLDR2QQ.WZVRWGY995BT@garyguo.net>
On Tue, Sep 29, 2026 at 05:07:40PM +0100, Gary Guo wrote:
> The reproducer that Georgios posted on GitHub is some cleanup job being added to
> task_work, which drops FileDescriptorReservation. And since exit_task_work()
> happens after exit_files(), put_unused_fd in that cleanup observe that
> current->files is NULL.
>
> So it's not from random thread, it's from the current task. And I find that
> particular case of doing per-task cleanup not unrealistic.
FWIW, descriptor reservation ought to be tied to specific files_struct
instance; note that dup_fd() can be called when there are outstanding
reservations and the copy does *NOT* have those reserved.
What rules would you suggest for such delayed put_unused_fd() wrt e.g.
files_struct unsharing?
next prev parent reply other threads:[~2026-09-29 17:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 2:23 [PATCH v2] rust: file: handle fd table teardown in file descriptor APIs Georgios Androutsopoulos
2026-09-24 8:39 ` Alice Ryhl
2026-09-24 16:06 ` Georgios Androutsopoulos
2026-09-24 16:18 ` Pedro Falcato
2026-09-25 16:00 ` Christian Brauner
2026-09-29 4:48 ` Al Viro
2026-09-29 8:49 ` Alice Ryhl
2026-09-29 13:28 ` Al Viro
2026-09-29 13:35 ` Alice Ryhl
2026-09-29 14:53 ` Al Viro
2026-09-29 12:24 ` Gary Guo
2026-09-29 13:51 ` Al Viro
2026-09-29 16:07 ` Gary Guo
2026-09-29 17:02 ` Al Viro [this message]
2026-09-29 18:22 ` Gary Guo
2026-09-29 19:47 ` Al Viro
2026-10-05 17:05 ` Georgios Androutsopoulos
2026-09-28 10:42 ` kernel test robot
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=20260929170218.GD989762@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=georgeandrout13@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=viro@ftp.linux.org.uk \
--cc=work@onurozkan.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.