[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201110200411.GU3576660@ZenIV.linux.org.uk>
Date: Tue, 10 Nov 2020 20:04:11 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: yulei.kernel@...il.com
Cc: akpm@...ux-foundation.org, naoya.horiguchi@....com,
pbonzini@...hat.com, linux-fsdevel@...r.kernel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
xiaoguangrong.eric@...il.com, kernellwp@...il.com,
lihaiwei.kernel@...il.com, Yulei Zhang <yuleixzhang@...cent.com>,
Xiao Guangrong <gloryxiao@...cent.com>
Subject: Re: [PATCH 01/35] fs: introduce dmemfs module
On Thu, Oct 08, 2020 at 03:53:51PM +0800, yulei.kernel@...il.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?)
> +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".
> +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...
Powered by blists - more mailing lists