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

["Gary Guo" <gary@garyguo.net>]

On Tue Sep 29, 2026 at 2:51 PM BST, Al Viro wrote:
> On Tue, Sep 29, 2026 at 01:24:45PM +0100, Gary Guo wrote:
>
>> > 	In particular, ->release() mentioned upthread should not be allowed
>> > to access _anything_ hanging off current, not just descriptor table.  Note
>> > that the last reference to an opened file might be sitting in an SCM_RIGHTS
>> > datagram pruned by AF_UNIX garbage collector; as far as the method is concerned,
>> > it might be called from random thread.
>> 
>> This part is protected -- we mark FileDescriptionReservation as `!Send` which
>> prevents it being moved to another task. We also take care to make sure that
>> the task returned `current!()` is not allowed to be used outside the current
>> task.
>
> Not the point - ->release() can't make any assumptions regarding which thread
> it will be run in.  current won't change under it, but there's nothing
> useful you could want with it.  If it has non-NULL ->files (or ->mm, or...),
> that reference will also remain stable, but any attempt to do anything with
> it would be a bug.

What I am saying is that due to FileDescriptorReservation being `!Send`, it
cannot make its way to ->release() from another thread. So
FileDescriptorReservation::drop will guarantee that it is on the same task that
created it.

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.

For fget/get_unused_fd_flags I already mentioned that I agree it's a bug, but
checking that statically would require codify the concept of syscall context in
a static analysis.

Best,
Gary