From: Khalid Aziz <khalid.aziz@oracle.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: akpm@linux-foundation.org, willy@infradead.org,
aneesh.kumar@linux.ibm.com, arnd@arndb.de, 21cnbao@gmail.com,
corbet@lwn.net, dave.hansen@linux.intel.com, david@redhat.com,
ebiederm@xmission.com, hagen@jauu.net, jack@suse.cz,
keescook@chromium.org, kirill@shutemov.name, kucharsk@gmail.com,
linkinjeon@kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
longpeng2@huawei.com, luto@kernel.org, markhemm@googlemail.com,
pcc@google.com, rppt@kernel.org, sieberf@amazon.com,
sjpark@amazon.de, surenb@google.com, tst@schoebel-theuer.de,
yzaikin@google.com
Subject: Re: [PATCH v2 3/9] mm/mshare: make msharefs writable and support directories
Date: Fri, 1 Jul 2022 18:22:09 -0600 [thread overview]
Message-ID: <bd424825-5d19-a569-d267-0f9dcf382358@oracle.com> (raw)
In-Reply-To: <Yr4tM2oOF9rlwWdV@ZenIV>
On 6/30/22 17:09, Al Viro wrote:
> On Wed, Jun 29, 2022 at 04:53:54PM -0600, Khalid Aziz wrote:
>
>> +static int
>> +msharefs_open(struct inode *inode, struct file *file)
>> +{
>> + return simple_open(inode, file);
>> +}
>
> Again, whatever for? >
>> +static struct dentry
>> +*msharefs_alloc_dentry(struct dentry *parent, const char *name)
>> +{
>> + struct dentry *d;
>> + struct qstr q;
>> + int err;
>> +
>> + q.name = name;
>> + q.len = strlen(name);
>> +
>> + err = msharefs_d_hash(parent, &q);
>> + if (err)
>> + return ERR_PTR(err);
>> +
>> + d = d_alloc(parent, &q);
>> + if (d)
>> + return d;
>> +
>> + return ERR_PTR(-ENOMEM);
>> +}
>
> And it's different from d_alloc_name() how, exactly?
By making minor changes to my other code, I was able to use all of the standard functions you pointed out. That
simplified my patch quite a bit. Thank you!
>
>> + case S_IFLNK:
>> + inode->i_op = &page_symlink_inode_operations;
>> + break;
>
> Really? You've got symlinks here?
I intended to support symlinks on msharefs but I am not sure if I see a use case at this time. I can drop support for
symlinks and add it in future if there is a use case.
>
>> + default:
>> + discard_new_inode(inode);
>> + inode = NULL;
>
> That's an odd way to spell BUG()...
I think what you are saying is this default case represents a bug and I should report it as such. Is that right, or
should I not have a default case at all (which is what I am seeing in some of the other places)?
>
>> +static int
>> +msharefs_mknod(struct user_namespace *mnt_userns, struct inode *dir,
>> + struct dentry *dentry, umode_t mode, dev_t dev)
>> +{
>> + struct inode *inode;
>> + int err = 0;
>> +
>> + inode = msharefs_get_inode(dir->i_sb, dir, mode);
>> + if (IS_ERR(inode))
>> + return PTR_ERR(inode);
>> +
>> + d_instantiate(dentry, inode);
>> + dget(dentry);
>> + dir->i_mtime = dir->i_ctime = current_time(dir);
>> +
>> + return err;
>> +}
>
> BTW, what's the point of having device nodes on that thing?
There will be no device nodes on msharefs. Are you referring to the dev_t parameter in msharefs_mknod() declaration? If
so, I am following the prototype declaration for that function from fs.h:
int (*mknod) (struct user_namespace *, struct inode *,struct dentry *,
umode_t,dev_t);
If I am misunderstanding, please correct me.
>
>> +static int
>> +msharefs_create(struct user_namespace *mnt_userns, struct inode *dir,
>> + struct dentry *dentry, umode_t mode, bool excl)
>> +{
>> + return msharefs_mknod(&init_user_ns, dir, dentry, mode | S_IFREG, 0);
>> +}
>> +
>> +static int
>> +msharefs_mkdir(struct user_namespace *mnt_userns, struct inode *dir,
>> + struct dentry *dentry, umode_t mode)
>> +{
>> + int ret = msharefs_mknod(&init_user_ns, dir, dentry, mode | S_IFDIR, 0);
>> +
>> + if (!ret)
>> + inc_nlink(dir);
>> + return ret;
>> +}
>> +
>> +static const struct inode_operations msharefs_file_inode_ops = {
>> + .setattr = simple_setattr,
>> + .getattr = simple_getattr,
>> +};
>> +static const struct inode_operations msharefs_dir_inode_ops = {
>> + .create = msharefs_create,
>> + .lookup = simple_lookup,
>> + .link = simple_link,
>> + .unlink = simple_unlink,
>> + .mkdir = msharefs_mkdir,
>> + .rmdir = simple_rmdir,
>> + .mknod = msharefs_mknod,
>> + .rename = simple_rename,
>> +};
>> +
>> static void
>> mshare_evict_inode(struct inode *inode)
>> {
>> @@ -58,7 +175,7 @@ mshare_info_read(struct file *file, char __user *buf, size_t nbytes,
>> {
>> char s[80];
>>
>> - sprintf(s, "%ld", PGDIR_SIZE);
>> + sprintf(s, "%ld\n", PGDIR_SIZE);
>> return simple_read_from_buffer(buf, nbytes, ppos, s, strlen(s));
>> }
>>
>> @@ -72,6 +189,38 @@ static const struct super_operations mshare_s_ops = {
>> .evict_inode = mshare_evict_inode,
>> };
>>
>> +static int
>> +prepopulate_files(struct super_block *s, struct inode *dir,
>> + struct dentry *root, const struct tree_descr *files)
>> +{
>> + int i;
>> + struct inode *inode;
>> + struct dentry *dentry;
>> +
>> + for (i = 0; !files->name || files->name[0]; i++, files++) {
>> + if (!files->name)
>> + continue;
>> +
>> + dentry = msharefs_alloc_dentry(root, files->name);
>> + if (!dentry)
>> + return -ENOMEM;
>> +
>> + inode = msharefs_get_inode(s, dir, S_IFREG | files->mode);
>> + if (!inode) {
>> + dput(dentry);
>> + return -ENOMEM;
>> + }
>> + inode->i_mode = S_IFREG | files->mode;
>> + inode->i_atime = inode->i_mtime = inode->i_ctime
>> + = current_time(inode);
>> + inode->i_fop = files->ops;
>> + inode->i_ino = i;
>> + d_add(dentry, inode);
>> + }
>> +
>> + return 0;
>> +}
>
> Looks remarkably similar to something I've seen somewhere... fs/libfs.c,
> if I'm not mistaken...
>
> Sarcasm aside, what's wrong with using simple_fill_super()?
I started out using simple_fill_super() in patch 1. I found that when I use simple_fill_super(), I end up with a
filesystem that userspace can not create a file in. I looked at other code like shmfs and efivarfs and wrote similar
code which got me a writable filesystem. I might be missing something basic and if there is a way to use
simple_fill_super() and be able to support file creation from userspace, I would much rather use simple_fill_super().
Thanks,
Khalid
next prev parent reply other threads:[~2022-07-02 0:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 22:53 [PATCH v2 0/9] Add support for shared PTEs across processes Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 1/9] mm: Add msharefs filesystem Khalid Aziz
2022-06-30 21:53 ` Darrick J. Wong
2022-07-01 16:05 ` Khalid Aziz
2022-06-30 22:57 ` Al Viro
2022-07-01 16:08 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 2/9] mm/mshare: pre-populate msharefs with information file Khalid Aziz
2022-06-30 21:37 ` Darrick J. Wong
2022-06-30 22:54 ` Khalid Aziz
2022-06-30 23:01 ` Al Viro
2022-07-01 16:11 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 3/9] mm/mshare: make msharefs writable and support directories Khalid Aziz
2022-06-30 21:34 ` Darrick J. Wong
2022-06-30 22:49 ` Khalid Aziz
2022-06-30 23:09 ` Al Viro
2022-07-02 0:22 ` Khalid Aziz [this message]
2022-06-29 22:53 ` [PATCH v2 4/9] mm/mshare: Add a read operation for msharefs files Khalid Aziz
2022-06-30 21:27 ` Darrick J. Wong
2022-06-30 22:27 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 5/9] mm/mshare: Add vm flag for shared PTE Khalid Aziz
2022-06-30 14:59 ` Mark Hemment
2022-06-30 15:46 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 6/9] mm/mshare: Add mmap operation Khalid Aziz
2022-06-30 21:44 ` Darrick J. Wong
2022-06-30 23:30 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 7/9] mm/mshare: Add unlink and munmap support Khalid Aziz
2022-06-30 21:50 ` Darrick J. Wong
2022-07-01 15:58 ` Khalid Aziz
2022-06-29 22:53 ` [PATCH v2 8/9] mm/mshare: Add basic page table sharing support Khalid Aziz
2022-07-07 9:13 ` Xin Hao
2022-07-07 15:33 ` Khalid Aziz
2022-06-29 22:54 ` [PATCH v2 9/9] mm/mshare: Enable mshare region mapping across processes Khalid Aziz
2022-06-30 11:57 ` [PATCH v2 0/9] Add support for shared PTEs " Mark Hemment
2022-06-30 15:39 ` Khalid Aziz
2022-07-02 4:24 ` Andrew Morton
2022-07-06 19:26 ` Khalid Aziz
2022-07-08 11:47 ` David Hildenbrand
2022-07-08 19:36 ` Khalid Aziz
2022-07-13 14:00 ` David Hildenbrand
2022-07-13 17:58 ` Mike Kravetz
2022-07-13 18:03 ` David Hildenbrand
2022-07-14 22:02 ` Khalid Aziz
2022-07-18 12:59 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd424825-5d19-a569-d267-0f9dcf382358@oracle.com \
--to=khalid.aziz@oracle.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hagen@jauu.net \
--cc=jack@suse.cz \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=kucharsk@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longpeng2@huawei.com \
--cc=luto@kernel.org \
--cc=markhemm@googlemail.com \
--cc=pcc@google.com \
--cc=rppt@kernel.org \
--cc=sieberf@amazon.com \
--cc=sjpark@amazon.de \
--cc=surenb@google.com \
--cc=tst@schoebel-theuer.de \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox