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] [day] [month] [year] [list]

Message-ID: <hfc7hcs72ugsuqhmta23ykjxomiuavsuynylj54muq7qbzrs3m@yvyypsaqftua>
Date: Tue, 2 Sep 2025 12:36:19 +0200
From: Jan Kara <jack@...e.cz>
To: Alexander Monakov <amonakov@...ras.ru>
Cc: Jan Kara <jack@...e.cz>, 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 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@...e.com>
SUSE Labs, CR