Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <cover.1602093760.git.yuleixzhang@tencent.com> <aa553faf9e97ee9306ecd5a67d3324a34f9ed4be.1602093760.git.yuleixzhang@tencent.com>
 <20201110200411.GU3576660@ZenIV.linux.org.uk>
In-Reply-To: <20201110200411.GU3576660@ZenIV.linux.org.uk>
From:   yulei zhang <yulei.kernel@gmail.com>
Date:   Wed, 11 Nov 2020 16:53:00 +0800
Message-ID: <CACZOiM1L2W+neaF-rd=k9cJTnQfNBLx2k9GLZydYuQiJqr=iXg@mail.gmail.com>
Subject: Re: [PATCH 01/35] fs: introduce dmemfs module
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        kvm <kvm@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
        Wanpeng Li <kernellwp@gmail.com>,
        Haiwei Li <lihaiwei.kernel@gmail.com>,
        Yulei Zhang <yuleixzhang@tencent.com>,
        Xiao Guangrong <gloryxiao@tencent.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Nov 11, 2020 at 4:04 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, Oct 08, 2020 at 03:53:51PM +0800, yulei.kernel@gmail.com wrote:
>
> > +static struct inode *
> > +dmemfs_get_inode(struct super_block *sb, const struct inode *dir, umode_t mode,
> > +              dev_t dev);
>
> WTF is 'dev' for?
>
> > +static int
> > +dmemfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, dev_t dev)
> > +{
> > +     struct inode *inode = dmemfs_get_inode(dir->i_sb, dir, mode, dev);
> > +     int error = -ENOSPC;
> > +
> > +     if (inode) {
> > +             d_instantiate(dentry, inode);
> > +             dget(dentry);   /* Extra count - pin the dentry in core */
> > +             error = 0;
> > +             dir->i_mtime = dir->i_ctime = current_time(inode);
> > +     }
> > +     return error;
> > +}
>
> ... same here, seeing that you only call that thing from the next two functions
> and you do *not* provide ->mknod() as a method (unsurprisingly - what would
> device nodes do there?)
>

Thanks for pointing this out. we may need support the mknod method, otherwise
the dev is redundant  and need to be removed.

> > +static int dmemfs_create(struct inode *dir, struct dentry *dentry,
> > +                      umode_t mode, bool excl)
> > +{
> > +     return dmemfs_mknod(dir, dentry, mode | S_IFREG, 0);
> > +}
> > +
> > +static int dmemfs_mkdir(struct inode *dir, struct dentry *dentry,
> > +                     umode_t mode)
> > +{
> > +     int retval = dmemfs_mknod(dir, dentry, mode | S_IFDIR, 0);
> > +
> > +     if (!retval)
> > +             inc_nlink(dir);
> > +     return retval;
> > +}
>
> > +int dmemfs_file_mmap(struct file *file, struct vm_area_struct *vma)
> > +{
> > +     return 0;
> > +}
> > +
> > +static const struct file_operations dmemfs_file_operations = {
> > +     .mmap = dmemfs_file_mmap,
> > +};
>
> Er...  Is that a placeholder for later in the series?  Because as it is,
> it makes no sense whatsoever - "it can be mmapped, but any access to the
> mapped area will segfault".
>

Yes, we seperate the full implementation for dmemfs_file_mmap into
patch 05/35, it
will assign the interfaces to handle the page fault.

> > +struct inode *dmemfs_get_inode(struct super_block *sb,
> > +                            const struct inode *dir, umode_t mode, dev_t dev)
> > +{
> > +     struct inode *inode = new_inode(sb);
> > +
> > +     if (inode) {
> > +             inode->i_ino = get_next_ino();
> > +             inode_init_owner(inode, dir, mode);
> > +             inode->i_mapping->a_ops = &empty_aops;
> > +             mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
> > +             mapping_set_unevictable(inode->i_mapping);
> > +             inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
> > +             switch (mode & S_IFMT) {
> > +             default:
> > +                     init_special_inode(inode, mode, dev);
> > +                     break;
> > +             case S_IFREG:
> > +                     inode->i_op = &dmemfs_file_inode_operations;
> > +                     inode->i_fop = &dmemfs_file_operations;
> > +                     break;
> > +             case S_IFDIR:
> > +                     inode->i_op = &dmemfs_dir_inode_operations;
> > +                     inode->i_fop = &simple_dir_operations;
> > +
> > +                     /*
> > +                      * directory inodes start off with i_nlink == 2
> > +                      * (for "." entry)
> > +                      */
> > +                     inc_nlink(inode);
> > +                     break;
> > +             case S_IFLNK:
> > +                     inode->i_op = &page_symlink_inode_operations;
> > +                     break;
>
> Where would symlinks come from?  Or anything other than regular files and
> directories, for that matter...

You are right, so far it just supports regular files and directories.