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
