linux-next: manual merge of the ext4 tree with the fscrypt tree

linux-next: manual merge of the ext4 tree with the fscrypt tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

Hi Theodore,

Today's linux-next merge of the ext4 tree got a conflict in:

  fs/ext4/inode.c

between commit:

  2ee6a576be564272 ("fs, fscrypt: add an S_ENCRYPTED inode flag")

from the fscrypt tree and commit:

  d4e50e6d43b2620f ("ext4: add ext4_should_use_dax()")

from the ext4 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc fs/ext4/inode.c
index 617c7feced24,9f836e2ec18c..000000000000
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -4572,6 -4610,21 +4610,23 @@@ int ext4_get_inode_loc(struct inode *in
  		!ext4_test_inode_state(inode, EXT4_STATE_XATTR));
  }
  
+ static bool ext4_should_use_dax(struct inode *inode)
+ {
++	unsigned int flags = EXT4_I(inode)->i_flags;
++
+ 	if (!test_opt(inode->i_sb, DAX))
+ 		return false;
+ 	if (!S_ISREG(inode->i_mode))
+ 		return false;
+ 	if (ext4_should_journal_data(inode))
+ 		return false;
+ 	if (ext4_has_inline_data(inode))
+ 		return false;
 -	if (ext4_encrypted_inode(inode))
++	if (flags & EXT4_ENCRYPT_FL)
+ 		return false;
+ 	return true;
+ }
+ 
  void ext4_set_inode_flags(struct inode *inode)
  {
  	unsigned int flags = EXT4_I(inode)->i_flags;
@@@ -4587,15 -4640,10 +4642,13 @@@
  		new_fl |= S_NOATIME;
  	if (flags & EXT4_DIRSYNC_FL)
  		new_fl |= S_DIRSYNC;
- 	if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode) &&
- 	    !ext4_should_journal_data(inode) && !ext4_has_inline_data(inode) &&
- 	    !(flags & EXT4_ENCRYPT_FL))
+ 	if (ext4_should_use_dax(inode))
  		new_fl |= S_DAX;
 +	if (flags & EXT4_ENCRYPT_FL)
 +		new_fl |= S_ENCRYPTED;
  	inode_set_flags(inode, new_fl,
 -			S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
 +			S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX|
 +			S_ENCRYPTED);
  }
  
  static blkcnt_t ext4_inode_blocks(struct ext4_inode *raw_inode,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ext4 tree with the fscrypt tree

[Stephen Rothwell]

Hi all,

On Mon, 30 Oct 2017 14:48:04 +0000 Mark Brown <broonie@kernel.org> wrote:
>
> Today's linux-next merge of the ext4 tree got a conflict in:
> 
>   fs/ext4/inode.c
> 
> between commit:
> 
>   2ee6a576be564272 ("fs, fscrypt: add an S_ENCRYPTED inode flag")
> 
> from the fscrypt tree and commit:
> 
>   d4e50e6d43b2620f ("ext4: add ext4_should_use_dax()")
> 
> from the ext4 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc fs/ext4/inode.c
> index 617c7feced24,9f836e2ec18c..000000000000
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@@ -4572,6 -4610,21 +4610,23 @@@ int ext4_get_inode_loc(struct inode *in
>   		!ext4_test_inode_state(inode, EXT4_STATE_XATTR));
>   }
>   
> + static bool ext4_should_use_dax(struct inode *inode)
> + {
> ++	unsigned int flags = EXT4_I(inode)->i_flags;
> ++
> + 	if (!test_opt(inode->i_sb, DAX))
> + 		return false;
> + 	if (!S_ISREG(inode->i_mode))
> + 		return false;
> + 	if (ext4_should_journal_data(inode))
> + 		return false;
> + 	if (ext4_has_inline_data(inode))
> + 		return false;
>  -	if (ext4_encrypted_inode(inode))
> ++	if (flags & EXT4_ENCRYPT_FL)
> + 		return false;
> + 	return true;
> + }
> + 
>   void ext4_set_inode_flags(struct inode *inode)
>   {
>   	unsigned int flags = EXT4_I(inode)->i_flags;
> @@@ -4587,15 -4640,10 +4642,13 @@@
>   		new_fl |= S_NOATIME;
>   	if (flags & EXT4_DIRSYNC_FL)
>   		new_fl |= S_DIRSYNC;
> - 	if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode) &&
> - 	    !ext4_should_journal_data(inode) && !ext4_has_inline_data(inode) &&
> - 	    !(flags & EXT4_ENCRYPT_FL))
> + 	if (ext4_should_use_dax(inode))
>   		new_fl |= S_DAX;
>  +	if (flags & EXT4_ENCRYPT_FL)
>  +		new_fl |= S_ENCRYPTED;
>   	inode_set_flags(inode, new_fl,
>  -			S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
>  +			S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX|
>  +			S_ENCRYPTED);
>   }
>   
>   static blkcnt_t ext4_inode_blocks(struct ext4_inode *raw_inode,

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the ext4 tree with the fscrypt tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

Hi all,

Today's linux-next merge of the ext4 tree got a conflict in:

  fs/ext4/super.c

between commit:

  ed318a6cc0b6 ("fscrypt: support test_dummy_encryption=v2")

from the fscrypt tree and commit:

  e0198aff3ae3 ("ext4: reject mount options not supported when remounting in handle_mount_opt()")

from the ext4 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/ext4/super.c
index 4a3d21972011,62e6ebc0c0ae..000000000000
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@@ -1819,8 -1817,8 +1820,8 @@@ static const struct mount_opts 
  	{Opt_jqfmt_vfsv0, QFMT_VFS_V0, MOPT_QFMT},
  	{Opt_jqfmt_vfsv1, QFMT_VFS_V1, MOPT_QFMT},
  	{Opt_max_dir_size_kb, 0, MOPT_GTE0},
 -	{Opt_test_dummy_encryption, 0, MOPT_GTE0},
 +	{Opt_test_dummy_encryption, 0, MOPT_STRING},
- 	{Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET},
+ 	{Opt_nombcache, EXT4_MOUNT_NO_MBCACHE, MOPT_SET | MOPT_NO_REMOUNT},
  	{Opt_err, 0, 0}
  };
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ext4 tree with the fscrypt tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]

Hi all,

Today's linux-next merge of the ext4 tree got a conflict in:

  fs/ext4/ioctl.c

between commit:

  29b3692e6dbf ("ext4: wire up new fscrypt ioctls")

from the fscrypt tree and commits:

  b0c013e2928d ("ext4: add a new ioctl EXT4_IOC_CLEAR_ES_CACHE")
  1ad3ea6e0a69 ("ext4: add a new ioctl EXT4_IOC_GETSTATE")
  bb5835edcdf8 ("ext4: add new ioctl EXT4_IOC_GET_ES_CACHE")

from the ext4 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc fs/ext4/ioctl.c
index fe5a4b13f939,d6242b7b8718..000000000000
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@@ -1115,31 -1183,33 +1183,58 @@@ resizefs_out
  	case EXT4_IOC_GET_ENCRYPTION_POLICY:
  		return fscrypt_ioctl_get_policy(filp, (void __user *)arg);
  
 +	case FS_IOC_GET_ENCRYPTION_POLICY_EX:
 +		if (!ext4_has_feature_encrypt(sb))
 +			return -EOPNOTSUPP;
 +		return fscrypt_ioctl_get_policy_ex(filp, (void __user *)arg);
 +
 +	case FS_IOC_ADD_ENCRYPTION_KEY:
 +		if (!ext4_has_feature_encrypt(sb))
 +			return -EOPNOTSUPP;
 +		return fscrypt_ioctl_add_key(filp, (void __user *)arg);
 +
 +	case FS_IOC_REMOVE_ENCRYPTION_KEY:
 +		if (!ext4_has_feature_encrypt(sb))
 +			return -EOPNOTSUPP;
 +		return fscrypt_ioctl_remove_key(filp, (void __user *)arg);
 +
 +	case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
 +		if (!ext4_has_feature_encrypt(sb))
 +			return -EOPNOTSUPP;
 +		return fscrypt_ioctl_remove_key_all_users(filp,
 +							  (void __user *)arg);
 +	case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
 +		if (!ext4_has_feature_encrypt(sb))
 +			return -EOPNOTSUPP;
 +		return fscrypt_ioctl_get_key_status(filp, (void __user *)arg);
 +
+ 	case EXT4_IOC_CLEAR_ES_CACHE:
+ 	{
+ 		if (!inode_owner_or_capable(inode))
+ 			return -EACCES;
+ 		ext4_clear_inode_es(inode);
+ 		return 0;
+ 	}
+ 
+ 	case EXT4_IOC_GETSTATE:
+ 	{
+ 		__u32	state = 0;
+ 
+ 		if (ext4_test_inode_state(inode, EXT4_STATE_EXT_PRECACHED))
+ 			state |= EXT4_STATE_FLAG_EXT_PRECACHED;
+ 		if (ext4_test_inode_state(inode, EXT4_STATE_NEW))
+ 			state |= EXT4_STATE_FLAG_NEW;
+ 		if (ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY))
+ 			state |= EXT4_STATE_FLAG_NEWENTRY;
+ 		if (ext4_test_inode_state(inode, EXT4_STATE_DA_ALLOC_CLOSE))
+ 			state |= EXT4_STATE_FLAG_DA_ALLOC_CLOSE;
+ 
+ 		return put_user(state, (__u32 __user *) arg);
+ 	}
+ 
+ 	case EXT4_IOC_GET_ES_CACHE:
+ 		return ext4_ioctl_get_es_cache(filp, arg);
+ 
  	case EXT4_IOC_FSGETXATTR:
  	{
  		struct fsxattr fa;
@@@ -1256,13 -1326,11 +1351,16 @@@ long ext4_compat_ioctl(struct file *fil
  	case EXT4_IOC_SET_ENCRYPTION_POLICY:
  	case EXT4_IOC_GET_ENCRYPTION_PWSALT:
  	case EXT4_IOC_GET_ENCRYPTION_POLICY:
 +	case FS_IOC_GET_ENCRYPTION_POLICY_EX:
 +	case FS_IOC_ADD_ENCRYPTION_KEY:
 +	case FS_IOC_REMOVE_ENCRYPTION_KEY:
 +	case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
 +	case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
  	case EXT4_IOC_SHUTDOWN:
  	case FS_IOC_GETFSMAP:
+ 	case EXT4_IOC_CLEAR_ES_CACHE:
+ 	case EXT4_IOC_GETSTATE:
+ 	case EXT4_IOC_GET_ES_CACHE:
  		break;
  	default:
  		return -ENOIOCTLCMD;


-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]