From: Mark Brown <broonie@kernel•org>
To: Theodore Ts'o <tytso@mit•edu>, Eric Biggers <ebiggers@google•com>
Cc: Linux Next Mailing List <linux-next@vger•kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>
Subject: linux-next: manual merge of the ext4 tree with Linus' tree
Date: Thu, 19 Sep 2019 12:44:17 +0100 [thread overview]
Message-ID: <20190919114417.GD3642@sirena.co.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]
Hi all,
Today's linux-next merge of the ext4 tree got a conflict in:
fs/ext4/ioctl.c
between commit:
29b3692e6dbf8226 ("ext4: wire up new fscrypt ioctls")
from Linus' tree and commits:
bb5835edcdf8bf7 ("ext4: add new ioctl EXT4_IOC_GET_ES_CACHE")
1ad3ea6e0a694b0 ("ext4: add a new ioctl EXT4_IOC_GETSTATE")
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 5444d49cbf09d,d6242b7b87182..0000000000000
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@@ -1113,35 -1181,35 +1181,62 @@@ resizefs_out
#endif
}
case EXT4_IOC_GET_ENCRYPTION_POLICY:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
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;
@@@ -1269,15 -1326,11 +1364,18 @@@ 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 FS_IOC_ENABLE_VERITY:
+ case FS_IOC_MEASURE_VERITY:
+ case EXT4_IOC_CLEAR_ES_CACHE:
+ case EXT4_IOC_GETSTATE:
+ case EXT4_IOC_GET_ES_CACHE:
break;
default:
return -ENOIOCTLCMD;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2019-09-19 11:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 11:44 Mark Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-06-27 0:39 linux-next: manual merge of the ext4 tree with Linus' tree Stephen Rothwell
2023-06-27 6:37 ` Christoph Hellwig
2023-06-27 7:26 ` Stephen Rothwell
2021-06-07 0:27 Stephen Rothwell
2020-12-17 23:12 Stephen Rothwell
2020-10-20 23:03 Stephen Rothwell
2016-03-21 0:29 Stephen Rothwell
2013-08-13 1:33 Stephen Rothwell
2011-03-25 1:56 Stephen Rothwell
2011-03-25 14:45 ` Tejun Heo
2011-03-25 16:30 ` Sedat Dilek
2011-03-25 19:58 ` Ted Ts'o
2011-02-14 2:19 Stephen Rothwell
2010-10-28 0:45 Stephen Rothwell
2010-05-22 5:50 Stephen Rothwell
2009-09-17 1:56 linux-next: manual merge of the ext4 tree with Linus tree Stephen Rothwell
2009-09-17 13:22 ` Theodore Tso
2009-09-17 13:30 ` Stephen Rothwell
2009-02-02 2:56 linux-next: manual merge of the ext4 tree with Linus' tree Stephen Rothwell
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=20190919114417.GD3642@sirena.co.uk \
--to=broonie@kernel$(echo .)org \
--cc=ebiggers@google$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=tytso@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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