From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: agruen@kernel.org, akpm@linux-foundation.org,
dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V6 09/26] vfs: Add delete child and delete self permission flags
Date: Wed, 7 Sep 2011 16:39:16 -0400 [thread overview]
Message-ID: <20110907203916.GE8074@fieldses.org> (raw)
In-Reply-To: <1315243548-18664-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Sep 05, 2011 at 10:55:31PM +0530, Aneesh Kumar K.V wrote:
> From: Andreas Gruenbacher <agruen@kernel.org>
>
> Normally, deleting a file requires write access to the parent directory.
> Some permission models use a different permission on the parent
> directory to indicate delete access. In addition, a process can have
> per-file delete access even without delete access on the parent
> directory.
>
> Introduce two new inode_permission() mask flags and use them in
> may_delete()
>
> Signed-off-by: Andreas Gruenbacher <agruen@kernel.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> fs/namei.c | 41 +++++++++++++++++++++++++++--------------
> include/linux/fs.h | 2 ++
> 2 files changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index d52a4cd..eacb530 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -337,7 +337,7 @@ static inline int do_inode_permission(struct inode *inode, int mask)
> * are used for other things.
> *
> * When checking for MAY_APPEND, MAY_CREATE_FILE, MAY_CREATE_DIR,
> - * MAY_WRITE must also be set in @mask.
> + * MAY_DELETE_CHILD, MAY_DELETE_SELF, MAY_WRITE must also be set in @mask.
> */
> int inode_permission(struct inode *inode, int mask)
> {
> @@ -1862,7 +1862,7 @@ static inline int check_sticky(struct inode *dir, struct inode *inode)
> return 0;
>
> other_userns:
> - return !ns_capable(inode_userns(inode), CAP_FOWNER);
> + return 1;
> }
>
> /*
> @@ -1884,30 +1884,43 @@ other_userns:
> * 10. We don't allow removal of NFS sillyrenamed files; it's handled by
> * nfs_async_unlink().
> */
> -static int may_delete(struct inode *dir,struct dentry *victim,int isdir)
> +static int may_delete(struct inode *dir, struct dentry *victim,
> + int isdir, int replace)
> {
> - int error;
> + int mask, error, is_sticky;
> + struct inode *inode = victim->d_inode;
>
> - if (!victim->d_inode)
> + if (!inode)
> return -ENOENT;
>
> BUG_ON(victim->d_parent->d_inode != dir);
> audit_inode_child(victim, dir);
>
> - error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
> + mask = MAY_WRITE | MAY_EXEC | MAY_DELETE_CHILD;
> + if (replace)
> + mask |= S_ISDIR(inode->i_mode) ?
> + MAY_CREATE_DIR : MAY_CREATE_FILE;
I'm having trouble understanding this next bit:
> + is_sticky = check_sticky(dir, inode);
> + error = inode_permission(dir, mask);
> + if ((error || is_sticky) && IS_RICHACL(inode) &&
> + !inode_permission(dir, mask & ~(MAY_WRITE | MAY_DELETE_CHILD)) &&
> + !inode_permission(inode, MAY_DELETE_SELF))
> + error = 0;
OK, so we can ignore the lack of write or delete permissions on the
parent if we have delete_self permissions on the child. I guess that's
right.
Why the "|| is_sticky" above?
Is there some less complicated why to write this?
--b.
> + else if (!error && is_sticky &&
> + !ns_capable(inode_userns(inode), CAP_FOWNER))
> + error = -EPERM;
> if (error)
> return error;
> if (IS_APPEND(dir))
> return -EPERM;
> - if (check_sticky(dir, victim->d_inode)||IS_APPEND(victim->d_inode)||
> - IS_IMMUTABLE(victim->d_inode) || IS_SWAPFILE(victim->d_inode))
> + if (IS_APPEND(inode) || IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
> return -EPERM;
> if (isdir) {
> - if (!S_ISDIR(victim->d_inode->i_mode))
> + if (!S_ISDIR(inode->i_mode))
> return -ENOTDIR;
> if (IS_ROOT(victim))
> return -EBUSY;
> - } else if (S_ISDIR(victim->d_inode->i_mode))
> + } else if (S_ISDIR(inode->i_mode))
> return -EISDIR;
> if (IS_DEADDIR(dir))
> return -ENOENT;
> @@ -2614,7 +2627,7 @@ void dentry_unhash(struct dentry *dentry)
>
> int vfs_rmdir(struct inode *dir, struct dentry *dentry)
> {
> - int error = may_delete(dir, dentry, 1);
> + int error = may_delete(dir, dentry, 1, 0);
>
> if (error)
> return error;
> @@ -2707,7 +2720,7 @@ SYSCALL_DEFINE1(rmdir, const char __user *, pathname)
>
> int vfs_unlink(struct inode *dir, struct dentry *dentry)
> {
> - int error = may_delete(dir, dentry, 0);
> + int error = may_delete(dir, dentry, 0, 0);
>
> if (error)
> return error;
> @@ -3101,14 +3114,14 @@ int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> if (old_dentry->d_inode == new_dentry->d_inode)
> return 0;
>
> - error = may_delete(old_dir, old_dentry, is_dir);
> + error = may_delete(old_dir, old_dentry, is_dir, 0);
> if (error)
> return error;
>
> if (!new_dentry->d_inode)
> error = may_create(new_dir, new_dentry, is_dir);
> else
> - error = may_delete(new_dir, new_dentry, is_dir);
> + error = may_delete(new_dir, new_dentry, is_dir, 1);
> if (error)
> return error;
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8707f43..c5c98c5 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -69,6 +69,8 @@ struct inodes_stat_t {
> #define MAY_NOT_BLOCK 0x00000080
> #define MAY_CREATE_FILE 0x00000100
> #define MAY_CREATE_DIR 0x00000200
> +#define MAY_DELETE_CHILD 0x00000400
> +#define MAY_DELETE_SELF 0x00000800
>
> /*
> * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
> --
> 1.7.4.1
>
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: "Aneesh Kumar K.V"
<aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: agruen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH -V6 09/26] vfs: Add delete child and delete self permission flags
Date: Wed, 7 Sep 2011 16:39:16 -0400 [thread overview]
Message-ID: <20110907203916.GE8074@fieldses.org> (raw)
In-Reply-To: <1315243548-18664-10-git-send-email-aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Mon, Sep 05, 2011 at 10:55:31PM +0530, Aneesh Kumar K.V wrote:
> From: Andreas Gruenbacher <agruen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Normally, deleting a file requires write access to the parent directory.
> Some permission models use a different permission on the parent
> directory to indicate delete access. In addition, a process can have
> per-file delete access even without delete access on the parent
> directory.
>
> Introduce two new inode_permission() mask flags and use them in
> may_delete()
>
> Signed-off-by: Andreas Gruenbacher <agruen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> ---
> fs/namei.c | 41 +++++++++++++++++++++++++++--------------
> include/linux/fs.h | 2 ++
> 2 files changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index d52a4cd..eacb530 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -337,7 +337,7 @@ static inline int do_inode_permission(struct inode *inode, int mask)
> * are used for other things.
> *
> * When checking for MAY_APPEND, MAY_CREATE_FILE, MAY_CREATE_DIR,
> - * MAY_WRITE must also be set in @mask.
> + * MAY_DELETE_CHILD, MAY_DELETE_SELF, MAY_WRITE must also be set in @mask.
> */
> int inode_permission(struct inode *inode, int mask)
> {
> @@ -1862,7 +1862,7 @@ static inline int check_sticky(struct inode *dir, struct inode *inode)
> return 0;
>
> other_userns:
> - return !ns_capable(inode_userns(inode), CAP_FOWNER);
> + return 1;
> }
>
> /*
> @@ -1884,30 +1884,43 @@ other_userns:
> * 10. We don't allow removal of NFS sillyrenamed files; it's handled by
> * nfs_async_unlink().
> */
> -static int may_delete(struct inode *dir,struct dentry *victim,int isdir)
> +static int may_delete(struct inode *dir, struct dentry *victim,
> + int isdir, int replace)
> {
> - int error;
> + int mask, error, is_sticky;
> + struct inode *inode = victim->d_inode;
>
> - if (!victim->d_inode)
> + if (!inode)
> return -ENOENT;
>
> BUG_ON(victim->d_parent->d_inode != dir);
> audit_inode_child(victim, dir);
>
> - error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
> + mask = MAY_WRITE | MAY_EXEC | MAY_DELETE_CHILD;
> + if (replace)
> + mask |= S_ISDIR(inode->i_mode) ?
> + MAY_CREATE_DIR : MAY_CREATE_FILE;
I'm having trouble understanding this next bit:
> + is_sticky = check_sticky(dir, inode);
> + error = inode_permission(dir, mask);
> + if ((error || is_sticky) && IS_RICHACL(inode) &&
> + !inode_permission(dir, mask & ~(MAY_WRITE | MAY_DELETE_CHILD)) &&
> + !inode_permission(inode, MAY_DELETE_SELF))
> + error = 0;
OK, so we can ignore the lack of write or delete permissions on the
parent if we have delete_self permissions on the child. I guess that's
right.
Why the "|| is_sticky" above?
Is there some less complicated why to write this?
--b.
> + else if (!error && is_sticky &&
> + !ns_capable(inode_userns(inode), CAP_FOWNER))
> + error = -EPERM;
> if (error)
> return error;
> if (IS_APPEND(dir))
> return -EPERM;
> - if (check_sticky(dir, victim->d_inode)||IS_APPEND(victim->d_inode)||
> - IS_IMMUTABLE(victim->d_inode) || IS_SWAPFILE(victim->d_inode))
> + if (IS_APPEND(inode) || IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
> return -EPERM;
> if (isdir) {
> - if (!S_ISDIR(victim->d_inode->i_mode))
> + if (!S_ISDIR(inode->i_mode))
> return -ENOTDIR;
> if (IS_ROOT(victim))
> return -EBUSY;
> - } else if (S_ISDIR(victim->d_inode->i_mode))
> + } else if (S_ISDIR(inode->i_mode))
> return -EISDIR;
> if (IS_DEADDIR(dir))
> return -ENOENT;
> @@ -2614,7 +2627,7 @@ void dentry_unhash(struct dentry *dentry)
>
> int vfs_rmdir(struct inode *dir, struct dentry *dentry)
> {
> - int error = may_delete(dir, dentry, 1);
> + int error = may_delete(dir, dentry, 1, 0);
>
> if (error)
> return error;
> @@ -2707,7 +2720,7 @@ SYSCALL_DEFINE1(rmdir, const char __user *, pathname)
>
> int vfs_unlink(struct inode *dir, struct dentry *dentry)
> {
> - int error = may_delete(dir, dentry, 0);
> + int error = may_delete(dir, dentry, 0, 0);
>
> if (error)
> return error;
> @@ -3101,14 +3114,14 @@ int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> if (old_dentry->d_inode == new_dentry->d_inode)
> return 0;
>
> - error = may_delete(old_dir, old_dentry, is_dir);
> + error = may_delete(old_dir, old_dentry, is_dir, 0);
> if (error)
> return error;
>
> if (!new_dentry->d_inode)
> error = may_create(new_dir, new_dentry, is_dir);
> else
> - error = may_delete(new_dir, new_dentry, is_dir);
> + error = may_delete(new_dir, new_dentry, is_dir, 1);
> if (error)
> return error;
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8707f43..c5c98c5 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -69,6 +69,8 @@ struct inodes_stat_t {
> #define MAY_NOT_BLOCK 0x00000080
> #define MAY_CREATE_FILE 0x00000100
> #define MAY_CREATE_DIR 0x00000200
> +#define MAY_DELETE_CHILD 0x00000400
> +#define MAY_DELETE_SELF 0x00000800
>
> /*
> * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-09-07 20:40 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 17:25 [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 01/26] vfs: Indicate that the permission functions take all the MAY_* flags Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 02/26] vfs: Add hex format for MAY_* flag values Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 03/26] vfs: Pass all mask flags down to iop->check_acl Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 04/26] vfs: Add a comment to inode_permission() Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 05/26] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 06/26] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 07/26] vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 08/26] vfs: Add new file and directory create permission flags Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-09 10:02 ` David Howells
2011-09-09 11:59 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 09/26] vfs: Add delete child and delete self " Aneesh Kumar K.V
2011-09-07 20:39 ` J. Bruce Fields [this message]
2011-09-07 20:39 ` J. Bruce Fields
2011-09-08 9:30 ` Aneesh Kumar K.V
2011-09-08 20:07 ` J. Bruce Fields
2011-09-08 22:02 ` J. Bruce Fields
2011-09-09 5:19 ` Aneesh Kumar K.V
2011-09-09 5:19 ` Aneesh Kumar K.V
2011-09-09 5:25 ` Aneesh Kumar K.V
2011-09-09 12:02 ` J. Bruce Fields
2011-09-09 5:14 ` Aneesh Kumar K.V
2011-09-09 5:14 ` Aneesh Kumar K.V
2011-09-09 10:12 ` David Howells
2011-09-09 10:12 ` David Howells
2011-09-09 11:55 ` Aneesh Kumar K.V
2011-09-09 11:55 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 10/26] vfs: Make the inode passed to inode_change_ok non-const Aneesh Kumar K.V
2011-09-07 20:43 ` J. Bruce Fields
2011-09-08 9:32 ` Aneesh Kumar K.V
2011-09-08 9:32 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 11/26] vfs: Add permission flags for setting file attributes Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-07 20:55 ` J. Bruce Fields
2011-09-08 9:36 ` Aneesh Kumar K.V
2011-09-08 20:08 ` J. Bruce Fields
2011-09-05 17:25 ` [PATCH -V6 12/26] vfs: Make acl_permission_check() work for richacls Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 13/26] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 14/26] richacl: Permission mapping functions Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-07 21:24 ` J. Bruce Fields
2011-09-08 10:27 ` Aneesh Kumar K.V
2011-09-09 10:36 ` David Howells
2011-09-09 11:54 ` Aneesh Kumar K.V
2011-09-09 11:54 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 15/26] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 16/26] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 17/26] richacl: Permission check algorithm Aneesh Kumar K.V
2011-09-07 21:50 ` J. Bruce Fields
2011-09-07 21:50 ` J. Bruce Fields
2011-09-08 10:34 ` Aneesh Kumar K.V
2011-09-08 10:34 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 18/26] richacl: Create-time inheritance Aneesh Kumar K.V
2011-09-09 12:14 ` David Howells
2011-09-09 12:14 ` David Howells
2011-09-05 17:25 ` [PATCH -V6 19/26] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 20/26] richacl: Automatic Inheritance Aneesh Kumar K.V
2011-09-07 21:56 ` J. Bruce Fields
2011-09-07 21:56 ` J. Bruce Fields
2011-09-05 17:25 ` [PATCH -V6 21/26] richacl: xattr mapping functions Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 22/26] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2011-09-09 12:37 ` David Howells
2011-09-09 12:37 ` David Howells
2011-09-05 17:25 ` [PATCH -V6 23/26] vfs: Add richacl permission check Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 24/26] ext4: Use IS_POSIXACL() to check for POSIX ACL support Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 25/26] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2011-09-09 12:45 ` David Howells
2011-09-13 4:25 ` Aneesh Kumar K.V
2011-09-13 4:25 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 26/26] ext4: Add temporary richacl mount option " Aneesh Kumar K.V
2011-09-05 17:25 ` Aneesh Kumar K.V
2011-09-05 22:42 ` [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability Casey Schaufler
2011-09-05 22:42 ` Casey Schaufler
2011-09-08 0:46 ` Valdis.Kletnieks
2011-09-08 0:46 ` Valdis.Kletnieks-PjAqaU27lzQ
2011-09-12 21:34 ` Casey Schaufler
2011-09-12 22:20 ` J. Bruce Fields
2011-09-12 22:38 ` Casey Schaufler
2011-09-12 22:38 ` Casey Schaufler
2011-09-12 22:43 ` J. Bruce Fields
2011-09-12 23:23 ` Casey Schaufler
2011-09-12 23:53 ` J. Bruce Fields
2011-09-12 23:53 ` J. Bruce Fields
2011-09-13 4:41 ` Aneesh Kumar K.V
2011-09-13 4:41 ` Aneesh Kumar K.V
2011-09-13 18:12 ` Valdis.Kletnieks
2011-09-06 9:41 ` Steven Whitehouse
2011-09-06 13:58 ` Aneesh Kumar K.V
2011-09-06 13:58 ` Aneesh Kumar K.V
2011-09-07 20:18 ` J. Bruce Fields
2011-09-07 23:44 ` J. Bruce Fields
2011-09-08 10:40 ` Aneesh Kumar K.V
2011-09-08 10:40 ` Aneesh Kumar K.V
2011-09-09 12:48 ` David Howells
2011-09-09 12:48 ` David Howells
2011-09-09 14:03 ` David Howells
2011-09-09 14:03 ` David Howells
2011-09-12 22:23 ` J. Bruce Fields
2011-09-12 22:23 ` J. Bruce Fields
2011-09-12 22:27 ` David Howells
2011-09-12 22:27 ` David Howells
2011-09-13 5:07 ` Aneesh Kumar K.V
2011-09-21 7:30 ` Aneesh Kumar K.V
2011-09-21 19:45 ` J. Bruce Fields
2011-09-21 19:45 ` J. Bruce Fields
2011-09-22 5:31 ` Aneesh Kumar K.V
2011-09-22 5:31 ` Aneesh Kumar K.V
2011-09-22 12:01 ` J. Bruce Fields
2011-09-22 12:01 ` J. Bruce Fields
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=20110907203916.GE8074@fieldses.org \
--to=bfields@fieldses.org \
--cc=agruen@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.