Re: [PATCH 8/8] fuse: implement ->tmpfile()

[Miklos Szeredi <miklos@szeredi.hu>]

On Fri, 16 Sept 2022 at 23:52, Bernd Schubert
<bernd.schubert@fastmail.fm> wrote:
>
>
>
> On 9/16/22 21:44, Miklos Szeredi wrote:
>
>
> > +static int fuse_tmpfile(struct user_namespace *mnt_userns, struct inode *dir,
> > +                     struct file *file, umode_t mode)
> > +{
> > +     struct fuse_conn *fc = get_fuse_conn(dir);
> > +     int err;
> > +
> > +     if (fc->no_tmpfile)
> > +             goto no_tmpfile;
> > +
> > +     err = fuse_create_open(dir, file->f_path.dentry, file, file->f_flags, mode, FUSE_TMPFILE);
> > +     if (err == -ENOSYS) {
> > +             fc->no_tmpfile = 1;
> > +no_tmpfile:
> > +             err = -EOPNOTSUPP;
> > +     }
> > +     return err;
> > +}
>
> A bit confusing part is that the other file systems are calling your new
> finish_tmpfile(), while fuse_create_open() calls finish_open() for
> tmpfiles as well. Seems to be identical but won't this easily miss
> possible changes done in the future to finish_tmpfile()?

There shouldn't be any such changes.  It's really just a shorthand
form of finish_open().

Would calling it finish_open_simple() help?   It really has nothing to
do with tmpfile and .atomic_open instances could call it as well.

Thanks,
Miklos