Messages in this thread | | | Date | Mon, 14 Aug 2023 23:34:07 +0200 | Subject | Re: [REGRESSION] fuse: execve() fails with ETXTBSY due to async fuse_flush | From | Bernd Schubert <> |
| |
On 8/14/23 16:00, Tycho Andersen wrote: > On Mon, Aug 14, 2023 at 01:02:35PM +0200, Miklos Szeredi wrote: >> On Mon, 14 Aug 2023 at 08:03, Jürg Billeter <j@bitron.ch> wrote: >>> >>> Since v6.3-rc1 commit 5a8bee63b1 ("fuse: in fuse_flush only wait if >>> someone wants the return code") `fput()` is called asynchronously if a >>> file is closed as part of a process exiting, i.e., if there was no >>> explicit `close()` before exit. >>> >>> If the file was open for writing, also `put_write_access()` is called >>> asynchronously as part of the async `fput()`. >>> >>> If that newly written file is an executable, attempting to `execve()` >>> the new file can fail with `ETXTBSY` if it's called after the writer >>> process exited but before the async `fput()` has run. >> >> Thanks for the report. >> >> At this point, I think it would be best to revert the original patch, >> since only v6.4 has it. > > I agree. > >> The original fix was already a workaround, and I don't see a clear >> path forward in this direction. We need to see if there's better >> direction. >> >> Ideas? > > It seems like we really do need to wait here. I guess that means we > need some kind of exit-proof wait?
I'm not sure how hackish it is, if fuse_flush gets converted to queue_work() and with a new work-queue in struct fuse_inode. That work_queue could be flushed through a new inode operation from do_open_execat.
Bernd
| |