Re: ETXTBSY window in __fput

[Alexander Monakov]

On Fri, 29 Aug 2025, Christian Brauner wrote:

> > > Even if we fix this there's no guarantee that the kernel will give that
> > > letting the close() of a writably opened file race against a concurrent
> > > exec of the same file will not result in EBUSY in some arcane way
> > > currently or in the future.
> > 
> > Forget Go and execve. Take the two-process scenario from my last email.
> > The program waiting on flock shouldn't be able to observe elevated
> > refcounts on the file after the lock is released. It matters not only
> > for execve, but also for unmounting the underlying filesystem, right?
> 
> What? No. How?: with details, please.

Apologies if there's a misunderstanding on my side, but put_file_access
does file_put_write_access, which in turn does

  mnt_put_write_access(file->f_path.mnt);

and I think elevated refcount on mnt will cause -EBUSY from mnt_hold_writers.
Which is then checked in mnt_make_readonly. I expect it affects unmount too,
just don't see exactly where.

(basically as remember non-lazy unmounting a filesystem with open files errors
out, right? as well as ro-remounting when some files are open for writing)

Alexander