Re: [PATCH v2] rust: file: handle fd table teardown in file descriptor APIs

[Al Viro]

On Tue, Sep 29, 2026 at 07:22:28PM +0100, Gary Guo wrote:
> On Tue Sep 29, 2026 at 6:02 PM BST, Al Viro wrote:
> > 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?
> 
> Ah, is this about `unshare(CLONE_FILES)`? For that case indeed our existing
> abstraction break down.

FWIW, the current rules are "you must not have any outstanding reservations when
you unshare descriptor table in any manner".  You are adding "... including the
ones that would be discarded by an already-scheduled task_work callback".

It's not just unshare(2) - there are more interesting callchains. For example,
unshare_files() from do_coredump(); this one should be fine in face of
put_unused_fd() in task_work, due to the task_work_run() in get_signal()
being upstream of vfs_coredump() call, but it needs to be considered.
Or begin_new_exec() - that has a lot more callchains leading to it.
It should be safe at the moment, but that needs to be demonstrated, etc.