On Wed, 27 Aug 2025, Alexander Monakov wrote: > Dear fs hackers, > > I suspect there's an unfortunate race window in __fput where file locks are > dropped (locks_remove_file) prior to decreasing writer refcount > (put_file_access). If I'm not mistaken, this window is observable and it > breaks a solution to ETXTBSY problem on exec'ing a just-written file, explained > in more detail below. The race in __fput is a problem irrespective of how the testcase triggers it, right? It's just showing a real-world scenario. But the issue can be demonstrated without a multithreaded fork: imagine one process placing an exclusive lock on a file and writing to it, another process waiting on that lock and immediately execve'ing when the lock is released. Can put_file_access be moved prior to locks_remove_file in __fput? Alexander
