All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: agruen@kernel.org, bfields@fieldses.org,
	akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
	dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V1 22/22] ext4: Add Ext4 compat richacl feature flag
Date: Thu, 01 May 2014 21:18:51 +0530	[thread overview]
Message-ID: <877g65biu4.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <88FB2DB7-126A-400E-9B44-19E99A553B2B@dilger.ca>

Andreas Dilger <adilger@dilger.ca> writes:

> On Apr 27, 2014, at 10:14 AM, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>> This feature flag can be used to enable richacl on
>> the file system. Once enabled the "acl" mount option
>> will enable richacl instead of posix acl
>
> I was going to complain about this patch, because re-using the "acl"
> mount option to specify richacl instead of POSIX ACL would be very
> confusing, since older kernels used the "acl" mount option to enable
> POSIX ACLs.
>
> Looking closer, I see that "acl" and "noacl" just means enable or disable
> the ACL functionality on the filesystem.  Please fix up the commit
> comment.

Will clarify in the commit message.

>
> Some more comments inline.
>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 6f9e6fadac04..2a0221652d79 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1274,6 +1274,30 @@ static ext4_fsblk_t get_sb_block(void **data)
>> 	return sb_block;
>> }
>> 
>> +static void enable_acl(struct super_block *sb)
>> +{
>> +#if !defined(CONFIG_EXT4_FS_POSIX_ACL) && !defined(CONFIG_EXT4_FS_RICHACL)
>> +	return;
>> +#endif
>> +	if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
>> +		sb->s_flags |= MS_RICHACL;
>> +		sb->s_flags &= ~MS_POSIXACL;
>> +	} else {
>> +		sb->s_flags |= MS_POSIXACL;
>> +		sb->s_flags &= ~MS_RICHACL;
>> +	}
>
> This should put the #ifdef around the code that is being enabled/disabled,
> otherwise it just becomes dead code:
>
> static int enable_acl(struct super_block *sb)
> {
> 	if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
> #if defined(CONFIG_EXT4_FS_RICHACL)
> 		sb->s_flags |= MS_RICHACL;
> 		sb->s_flags &= ~MS_POSIXACL;
> #else
> 		return -EOPNOTSUPP;
> #endif
> 	} else {
> #if defined(CONFIG_EXT4_FS_POSIX_ACL)
> 		sb->s_flags |= MS_POSIXACL;
> 		sb->s_flags &= ~MS_RICHACL;
> #else
> 		return -EOPNOTSUPP;
> #endif
> 	}
> 	return 0;
> }

That is too much #ifdef with no real benefit ?

>
>> +
>> +static void disable_acl(struct super_block *sb)
>> +{
>> +#if !defined(CONFIG_EXT4_FS_POSIX_ACL) && !defined(CONFIG_EXT4_FS_RICHACL)
>> +	return;
>> +#endif
>> +	sb->s_flags &= ~(MS_POSIXACL | MS_RICHACL);
>> +	return;
>> +}
>
> "return" is not needed at the end of void functions. Same comment on
> #ifdef:

ok

>
> static void disable_acl(struct super_block *sb)
> {
> #if defined(CONFIG_EXT4_FS_POSIX_ACL) || defined(CONFIG_EXT4_FS_RICHACL)
> 	sb->s_flags &= ~(MS_POSIXACL | MS_RICHACL);
> #endif
> }
>
>
>> +
>> #define DEFAULT_JOURNAL_IOPRIO (IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 3))
>> static char deprecated_msg[] = "Mount option \"%s\" will be removed by %s\n"
>> 	"Contact linux-ext4@vger.kernel.org if you think we should keep it.\n";
>> @@ -1417,9 +1441,9 @@ static const struct mount_opts {
>> 	 MOPT_NO_EXT2 | MOPT_DATAJ},
>> 	{Opt_user_xattr, EXT4_MOUNT_XATTR_USER, MOPT_SET},
>> 	{Opt_nouser_xattr, EXT4_MOUNT_XATTR_USER, MOPT_CLEAR},

....

>> 	if ((def_mount_opts & EXT4_DEFM_JMODE) == EXT4_DEFM_JMODE_DATA)
>> 		set_opt(sb, JOURNAL_DATA);
>> @@ -3569,8 +3593,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>> 			clear_opt(sb, DELALLOC);
>> 	}
>> 
>> -	sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
>> -		(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
>> +	/*
>> +	 * clear ACL flags
>> +	 */
>> +	disable_acl(sb);
>
> Is there any expectation that the flags would be set on a newly mounted
> filesystem?
>
>> +	if (test_opt(sb, ACL))
>> +		enable_acl(sb);
>> 
>> 	if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV &&
>> 	    (EXT4_HAS_COMPAT_FEATURE(sb, ~0U) ||
>> @@ -4844,8 +4872,9 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>> 	if (sbi->s_mount_flags & EXT4_MF_FS_ABORTED)
>> 		ext4_abort(sb, "Abort forced by user");
>> 
>> -	sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
>> -		(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
>> +	disable_acl(sb);
>> +	if (test_opt(sb, ACL))
>> +		enable_acl(sb);
>
> Similarly, it seems racy to me to disable ACL support and then re-enable
> it here during remount, since that might cause some concurrent operations
> to fail.  It seems like enable_acl() already handles clearing the flags
> correctly, so something like the following would be better:
>
> 	if (test_opt(sb, ACL))
> 		enable_acl(sb);
> 	else
> 		disable_acl(sb);
>
>

ok

-aneesh


WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
Cc: agruen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@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 -V1 22/22] ext4: Add Ext4 compat richacl feature flag
Date: Thu, 01 May 2014 21:18:51 +0530	[thread overview]
Message-ID: <877g65biu4.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <88FB2DB7-126A-400E-9B44-19E99A553B2B-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>

Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> writes:

> On Apr 27, 2014, at 10:14 AM, Aneesh Kumar K.V <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>> This feature flag can be used to enable richacl on
>> the file system. Once enabled the "acl" mount option
>> will enable richacl instead of posix acl
>
> I was going to complain about this patch, because re-using the "acl"
> mount option to specify richacl instead of POSIX ACL would be very
> confusing, since older kernels used the "acl" mount option to enable
> POSIX ACLs.
>
> Looking closer, I see that "acl" and "noacl" just means enable or disable
> the ACL functionality on the filesystem.  Please fix up the commit
> comment.

Will clarify in the commit message.

>
> Some more comments inline.
>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 6f9e6fadac04..2a0221652d79 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1274,6 +1274,30 @@ static ext4_fsblk_t get_sb_block(void **data)
>> 	return sb_block;
>> }
>> 
>> +static void enable_acl(struct super_block *sb)
>> +{
>> +#if !defined(CONFIG_EXT4_FS_POSIX_ACL) && !defined(CONFIG_EXT4_FS_RICHACL)
>> +	return;
>> +#endif
>> +	if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
>> +		sb->s_flags |= MS_RICHACL;
>> +		sb->s_flags &= ~MS_POSIXACL;
>> +	} else {
>> +		sb->s_flags |= MS_POSIXACL;
>> +		sb->s_flags &= ~MS_RICHACL;
>> +	}
>
> This should put the #ifdef around the code that is being enabled/disabled,
> otherwise it just becomes dead code:
>
> static int enable_acl(struct super_block *sb)
> {
> 	if (EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_RICHACL)) {
> #if defined(CONFIG_EXT4_FS_RICHACL)
> 		sb->s_flags |= MS_RICHACL;
> 		sb->s_flags &= ~MS_POSIXACL;
> #else
> 		return -EOPNOTSUPP;
> #endif
> 	} else {
> #if defined(CONFIG_EXT4_FS_POSIX_ACL)
> 		sb->s_flags |= MS_POSIXACL;
> 		sb->s_flags &= ~MS_RICHACL;
> #else
> 		return -EOPNOTSUPP;
> #endif
> 	}
> 	return 0;
> }

That is too much #ifdef with no real benefit ?

>
>> +
>> +static void disable_acl(struct super_block *sb)
>> +{
>> +#if !defined(CONFIG_EXT4_FS_POSIX_ACL) && !defined(CONFIG_EXT4_FS_RICHACL)
>> +	return;
>> +#endif
>> +	sb->s_flags &= ~(MS_POSIXACL | MS_RICHACL);
>> +	return;
>> +}
>
> "return" is not needed at the end of void functions. Same comment on
> #ifdef:

ok

>
> static void disable_acl(struct super_block *sb)
> {
> #if defined(CONFIG_EXT4_FS_POSIX_ACL) || defined(CONFIG_EXT4_FS_RICHACL)
> 	sb->s_flags &= ~(MS_POSIXACL | MS_RICHACL);
> #endif
> }
>
>
>> +
>> #define DEFAULT_JOURNAL_IOPRIO (IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 3))
>> static char deprecated_msg[] = "Mount option \"%s\" will be removed by %s\n"
>> 	"Contact linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org if you think we should keep it.\n";
>> @@ -1417,9 +1441,9 @@ static const struct mount_opts {
>> 	 MOPT_NO_EXT2 | MOPT_DATAJ},
>> 	{Opt_user_xattr, EXT4_MOUNT_XATTR_USER, MOPT_SET},
>> 	{Opt_nouser_xattr, EXT4_MOUNT_XATTR_USER, MOPT_CLEAR},

....

>> 	if ((def_mount_opts & EXT4_DEFM_JMODE) == EXT4_DEFM_JMODE_DATA)
>> 		set_opt(sb, JOURNAL_DATA);
>> @@ -3569,8 +3593,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>> 			clear_opt(sb, DELALLOC);
>> 	}
>> 
>> -	sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
>> -		(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
>> +	/*
>> +	 * clear ACL flags
>> +	 */
>> +	disable_acl(sb);
>
> Is there any expectation that the flags would be set on a newly mounted
> filesystem?
>
>> +	if (test_opt(sb, ACL))
>> +		enable_acl(sb);
>> 
>> 	if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV &&
>> 	    (EXT4_HAS_COMPAT_FEATURE(sb, ~0U) ||
>> @@ -4844,8 +4872,9 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>> 	if (sbi->s_mount_flags & EXT4_MF_FS_ABORTED)
>> 		ext4_abort(sb, "Abort forced by user");
>> 
>> -	sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
>> -		(test_opt(sb, POSIX_ACL) ? MS_POSIXACL : 0);
>> +	disable_acl(sb);
>> +	if (test_opt(sb, ACL))
>> +		enable_acl(sb);
>
> Similarly, it seems racy to me to disable ACL support and then re-enable
> it here during remount, since that might cause some concurrent operations
> to fail.  It seems like enable_acl() already handles clearing the flags
> correctly, so something like the following would be better:
>
> 	if (test_opt(sb, ACL))
> 		enable_acl(sb);
> 	else
> 		disable_acl(sb);
>
>

ok

-aneesh

--
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

  reply	other threads:[~2014-05-01 15:49 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-27 16:14 [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 01/22] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 02/22] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2014-04-27 16:14   ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 03/22] vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 04/22] vfs: check for directory early Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 05/22] vfs: Add new file and directory create permission flags Aneesh Kumar K.V
2014-04-28 11:23   ` Jeff Layton
2014-04-29  0:04     ` Dave Chinner
2014-04-29  0:04       ` Dave Chinner
2014-05-01 15:16       ` Aneesh Kumar K.V
2014-05-01 15:16         ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 06/22] vfs: Add delete child and delete self " Aneesh Kumar K.V
2014-04-29  0:07   ` Dave Chinner
2014-05-01 15:18     ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 07/22] vfs: Make the inode passed to inode_change_ok non-const Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 08/22] vfs: Add permission flags for setting file attributes Aneesh Kumar K.V
2014-04-29  0:17   ` Dave Chinner
2014-05-01 15:20     ` Aneesh Kumar K.V
2014-05-01 15:20       ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 09/22] vfs: Make acl_permission_check() work for richacls Aneesh Kumar K.V
2014-04-29  0:20   ` Dave Chinner
2014-05-01 15:39     ` Aneesh Kumar K.V
2014-05-01 15:39       ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 10/22] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2014-04-29  0:24   ` Dave Chinner
2014-05-01 15:42     ` Aneesh Kumar K.V
2014-05-06  9:35   ` Kinglong Mee
2014-05-06  9:35     ` Kinglong Mee
2014-04-27 16:14 ` [PATCH -V1 11/22] richacl: Permission mapping functions Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 12/22] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 13/22] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2014-04-27 16:14   ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 14/22] richacl: Permission check algorithm Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 15/22] richacl: Create-time inheritance Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 16/22] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 17/22] richacl: Automatic Inheritance Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 18/22] richacl: xattr mapping functions Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 19/22] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2014-04-27 16:14   ` Aneesh Kumar K.V
2014-04-29  0:52   ` Dave Chinner
2014-04-29  0:52     ` Dave Chinner
2014-04-29 12:16     ` Matthew Wilcox
2014-05-01 15:45     ` Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 20/22] vfs: Add richacl permission check Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 21/22] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2014-04-27 16:14 ` [PATCH -V1 22/22] ext4: Add Ext4 compat richacl feature flag Aneesh Kumar K.V
2014-04-28 21:31   ` Andreas Dilger
2014-04-28 21:31     ` Andreas Dilger
2014-05-01 15:48     ` Aneesh Kumar K.V [this message]
2014-05-01 15:48       ` Aneesh Kumar K.V
2014-05-01 17:52       ` Andreas Dilger
2014-04-27 22:20 ` [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability Dave Chinner
2014-04-27 22:20   ` Dave Chinner
2014-04-28  5:24   ` Aneesh Kumar K.V
2014-04-28  5:24     ` Aneesh Kumar K.V
2014-04-28 23:58     ` Dave Chinner
2014-05-01 15:49       ` Aneesh Kumar K.V
2014-05-01 15:49         ` Aneesh Kumar K.V
2014-04-28  4:39 ` Christoph Hellwig
2014-04-28  5:54   ` Aneesh Kumar K.V
2014-04-28  5:54     ` Aneesh Kumar K.V
2014-04-28  9:03     ` Christoph Hellwig
2014-04-28  9:03       ` Christoph Hellwig
2014-05-06 20:15 ` 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=877g65biu4.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@dilger.ca \
    --cc=agruen@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.