Re: [PATCH 4/5] fs: honor LOOKUP_NONBLOCK for the last part of file open

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com> 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@fromorbit.com