On Mon 01-09-25 20:53:38, Alexander Monakov wrote: > > On Fri, 29 Aug 2025, Jan Kara wrote: > > > Umount (may_umount_tree()) looks at mnt->mnt_count which is decremented by > > mntput() completely at the end of __fput(). I tend to agree with Christian > > here: We've never promised that all effects of open fd are cleaned up > > before the flock is released and as Christian explained it will be actually > > pretty hard to implement such behavior. So attempts to wait for fd to close > > by waiting for its flock are racy... > > (flock is not a Linux invention, if BSD implementations offered that guarantee, > I'd expect Linux to follow, but I'm not sure if they did) > > That's unfortunate. If the remount/unmount issues are not convincing, shall we > try to get this issue called out in the Linux man pages? Would you help me with > wordsmithing? > > How about adding the following to the NOTES section in flock.2? > > Releasing the lock when a file descriptor is closed is not sequenced > after all observable effects of close(). For example, when one process > places an exclusive lock on a file, writes to it, then closes it, and > another process waits on a shared lock for the file to be closed, it may > observe that subsequent execve() fails with ETXTBSY, and umount() of the > underlying filesystem fails with EBUSY, as if the file is still open in > the first process. The paragraph sounds good to me. Thanks for writing it! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
