On Tue, Nov 10, 2020 at 4:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, Nov 10, 2020 at 4:33 AM Chirantan Ekbote <chirantan@xxxxxxxxxxxx> wrote: > > > That's not the behavior I observed. Without this, the O_TMPFILE flag > > gets passed through to the server. The call stack is: > > > > - do_filp_open > > - path_openat > > - do_tmpfile > > - vfs_tmpfile > > - dir->i_op->tmpfile > > - finish_open > > - do_dentry_open > > - f->f_op->open > > > > and I didn't see O_TMPFILE being removed anywhere in there. > > Ah, indeed. > > The reason I missed this is because IMO the way it *should* work is > that FUSE_TMPFILE creates and opens the file in one go. We shouldn't > need two separate request. > > Not sure how we should go about this... The ->atomic_open() API is > sufficient, but maybe we want a new ->atomic_tmpfile(). > I think I agree with you that it should probably be a single request but at this point is it worth adding an ->atomic_tmpfile() that's only used by fuse? Unlike regular file creation, it's not like the tmpfile entry is accessible via any other mechanism so other than latency I don't think there's any real harm with having it be 2 separate requests.
