Re: [RFC] problems with alloc_file_pseudo() use in __nfs42_ssc_open()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 17, 2022 at 6:18 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
>         My apologies for having missed that back when the SSC
> patchset had been done (and missing the problems after it got
> merged, actually).
>
> 1) if this
>         r_ino = nfs_fhget(ss_mnt->mnt_sb, src_fh, fattr);
> in __nfs42_ssc_open() yields a directory inode, we are screwed
> as soon as it's passed to alloc_file_pseudo() - a *lot* of places
> in dcache handling would break if we do that.  It's not too
> nice for a regular file from non-cooperating filesystem, but for
> directory ones it's deadly.

This inode is created to make an appearance of an opened file to do
(an NFS) read, it's never a directory.

> 2) if alloc_file_pseudo() fails there, we get an inode leak.  It
> needs an iput() for that case.  As in
>         if (IS_ERR(filep)) {
>                 res = ERR_CAST(filep);
>                 iput(r_ino);
>                 goto out_free_name;
>         }
>
> But I'd like to point out that alloc_file_pseudo() is not inteded for
> use on normal filesystem's inodes - the use here *mostly* works
> (directories aside), but...  Use it on filesystem with non-trivial
> default dentry_operations and things will get interesting, etc.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux