On Fri, 16 Sept 2022 at 23:52, Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> 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
