linux-kernel - Re: ETXTBSY window in _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <68c99812-e933-ce93-17c0-3fe3ab01afb8@ispras.ru>
Date: Mon, 1 Sep 2025 20:53:38 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: Jan Kara <jack@...e.cz>
cc: Christian Brauner <brauner@...nel.org>, linux-fsdevel@...r.kernel.org, 
    Alexander Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: ETXTBSY window in __fput

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.

Alexander