On Sun, Dec 13, 2020 at 04:45:39PM -0800, Linus Torvalds wrote: > On Sun, Dec 13, 2020 at 2:50 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > > > > Only O_CREAT | O_TRUNC should matter, since those are the ones that > > > > cause writes as part of the *open*. > > > > And __O_TMPFILE, which is the same as O_CREAT. > > This made me go look at the code, but we seem to be ok here - > __O_TMPFILE should never get to the do_open() logic at all, because it > gets caught before that and does off to do_tmpfile() and then > vfs_tmpfile() instead. > > And then it's up to the filesystem to do the inode locking if it needs > to - it has a separate i_io->tempfile function for that. Sure, and then it blocks. Guaranteed, for the same reasons that O_CREAT will block when calling ->create() after the path lookup: the filesystem runs a transaction to allocate an inode and track it on the orphan list so that it gets cleaned up by recovery after a crash while the tmpfile is still open. So it doesn't matter if the lookup is non-blocking, the tmpfile creation is guaranteed to block for the same reason O_CREAT and O_TRUNCATE will block.... > From a LOOKUP_NONBLOCK standpoint, I think we should just disallow > O_TMPFILE the same way Jens disallowed O_TRUNCATE. *nod* I just don't think it makes sense to try to make any of the filesystem level stuff open() might do non-blocking. The moment we start a filesystem modification, we have to be able to block because it is the only way to guarantee forwards progress. So if we know we are going to call into the filesystem to make a modification if the pathwalk is successful, why even bother starting the pathwalk? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
