From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
linux-api@vger.kernel.org, Satya Tangirala <satyat@google.com>,
Paul Crowley <paulcrowley@google.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Date: Wed, 14 Aug 2019 15:35:43 -0700 [thread overview]
Message-ID: <20190814223542.GE101319@gmail.com> (raw)
In-Reply-To: <20190813000644.GH28705@mit.edu>
On Mon, Aug 12, 2019 at 08:06:44PM -0400, Theodore Y. Ts'o wrote:
> > + /* Some inodes still reference this key; try to evict them. */
> > + if (try_to_lock_encrypted_files(sb, mk) != 0)
> > + status_flags |=
> > + FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
> > + }
>
> try_to_lock_encrypted_files() can return other errors besides -EBUSY;
> in particular sync_filesystem() can return other errors, such as -EIO
> or -EFSCORUPTED. In that case, I think we're better off returning the
> relevant status code back to the user. We will have already wiped the
> master key, but this situation will only happen in exceptional
> conditions (e.g., user has ejected the sdcard, etc.), so it's not
> worth it to try to undo the master key wipe to try to restore things
> to the pre-ioctl execution state.
>
> So I think we should capture the return code from
> try_to_lock_encrypted_files, and if it is EBUSY, we can set FILES_BUSY
> flag and return success. Otherwise, we should return the error.
>
> If you agree, please fix that up and then feel free to add:
>
> Reviewed-by: Theodore Ts'o <tytso@mit.edu>
>
> - Ted
Yes, that makes sense. I've made the following change to this patch:
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 9901593051424b..c3423f0edc7014 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -479,6 +479,7 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
struct key *key;
struct fscrypt_master_key *mk;
u32 status_flags = 0;
+ int err;
bool dead;
if (copy_from_user(&arg, uarg, sizeof(arg)))
@@ -514,11 +515,15 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* key object is free to be removed from the keyring.
*/
key_invalidate(key);
+ err = 0;
} else {
/* Some inodes still reference this key; try to evict them. */
- if (try_to_lock_encrypted_files(sb, mk) != 0)
+ err = try_to_lock_encrypted_files(sb, mk);
+ if (err == -EBUSY) {
status_flags |=
FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
+ err = 0;
+ }
}
/*
* We return 0 if we successfully did something: wiped the secret, or
@@ -527,7 +532,9 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* including all files locked.
*/
key_put(key);
- return put_user(status_flags, &uarg->removal_status_flags);
+ if (err == 0)
+ err = put_user(status_flags, &uarg->removal_status_flags);
+ return err;
}
EXPORT_SYMBOL_GPL(fscrypt_ioctl_remove_key);
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Date: Wed, 14 Aug 2019 15:35:43 -0700 [thread overview]
Message-ID: <20190814223542.GE101319@gmail.com> (raw)
In-Reply-To: <20190813000644.GH28705@mit.edu>
On Mon, Aug 12, 2019 at 08:06:44PM -0400, Theodore Y. Ts'o wrote:
> > + /* Some inodes still reference this key; try to evict them. */
> > + if (try_to_lock_encrypted_files(sb, mk) != 0)
> > + status_flags |=
> > + FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
> > + }
>
> try_to_lock_encrypted_files() can return other errors besides -EBUSY;
> in particular sync_filesystem() can return other errors, such as -EIO
> or -EFSCORUPTED. In that case, I think we're better off returning the
> relevant status code back to the user. We will have already wiped the
> master key, but this situation will only happen in exceptional
> conditions (e.g., user has ejected the sdcard, etc.), so it's not
> worth it to try to undo the master key wipe to try to restore things
> to the pre-ioctl execution state.
>
> So I think we should capture the return code from
> try_to_lock_encrypted_files, and if it is EBUSY, we can set FILES_BUSY
> flag and return success. Otherwise, we should return the error.
>
> If you agree, please fix that up and then feel free to add:
>
> Reviewed-by: Theodore Ts'o <tytso@mit.edu>
>
> - Ted
Yes, that makes sense. I've made the following change to this patch:
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 9901593051424b..c3423f0edc7014 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -479,6 +479,7 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
struct key *key;
struct fscrypt_master_key *mk;
u32 status_flags = 0;
+ int err;
bool dead;
if (copy_from_user(&arg, uarg, sizeof(arg)))
@@ -514,11 +515,15 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* key object is free to be removed from the keyring.
*/
key_invalidate(key);
+ err = 0;
} else {
/* Some inodes still reference this key; try to evict them. */
- if (try_to_lock_encrypted_files(sb, mk) != 0)
+ err = try_to_lock_encrypted_files(sb, mk);
+ if (err == -EBUSY) {
status_flags |=
FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
+ err = 0;
+ }
}
/*
* We return 0 if we successfully did something: wiped the secret, or
@@ -527,7 +532,9 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* including all files locked.
*/
key_put(key);
- return put_user(status_flags, &uarg->removal_status_flags);
+ if (err == 0)
+ err = put_user(status_flags, &uarg->removal_status_flags);
+ return err;
}
EXPORT_SYMBOL_GPL(fscrypt_ioctl_remove_key);
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Date: Wed, 14 Aug 2019 22:35:43 +0000 [thread overview]
Message-ID: <20190814223542.GE101319@gmail.com> (raw)
In-Reply-To: <20190813000644.GH28705@mit.edu>
On Mon, Aug 12, 2019 at 08:06:44PM -0400, Theodore Y. Ts'o wrote:
> > + /* Some inodes still reference this key; try to evict them. */
> > + if (try_to_lock_encrypted_files(sb, mk) != 0)
> > + status_flags |> > + FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
> > + }
>
> try_to_lock_encrypted_files() can return other errors besides -EBUSY;
> in particular sync_filesystem() can return other errors, such as -EIO
> or -EFSCORUPTED. In that case, I think we're better off returning the
> relevant status code back to the user. We will have already wiped the
> master key, but this situation will only happen in exceptional
> conditions (e.g., user has ejected the sdcard, etc.), so it's not
> worth it to try to undo the master key wipe to try to restore things
> to the pre-ioctl execution state.
>
> So I think we should capture the return code from
> try_to_lock_encrypted_files, and if it is EBUSY, we can set FILES_BUSY
> flag and return success. Otherwise, we should return the error.
>
> If you agree, please fix that up and then feel free to add:
>
> Reviewed-by: Theodore Ts'o <tytso@mit.edu>
>
> - Ted
Yes, that makes sense. I've made the following change to this patch:
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 9901593051424b..c3423f0edc7014 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -479,6 +479,7 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
struct key *key;
struct fscrypt_master_key *mk;
u32 status_flags = 0;
+ int err;
bool dead;
if (copy_from_user(&arg, uarg, sizeof(arg)))
@@ -514,11 +515,15 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* key object is free to be removed from the keyring.
*/
key_invalidate(key);
+ err = 0;
} else {
/* Some inodes still reference this key; try to evict them. */
- if (try_to_lock_encrypted_files(sb, mk) != 0)
+ err = try_to_lock_encrypted_files(sb, mk);
+ if (err = -EBUSY) {
status_flags | FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
+ err = 0;
+ }
}
/*
* We return 0 if we successfully did something: wiped the secret, or
@@ -527,7 +532,9 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* including all files locked.
*/
key_put(key);
- return put_user(status_flags, &uarg->removal_status_flags);
+ if (err = 0)
+ err = put_user(status_flags, &uarg->removal_status_flags);
+ return err;
}
EXPORT_SYMBOL_GPL(fscrypt_ioctl_remove_key);
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl
Date: Wed, 14 Aug 2019 15:35:43 -0700 [thread overview]
Message-ID: <20190814223542.GE101319@gmail.com> (raw)
In-Reply-To: <20190813000644.GH28705@mit.edu>
On Mon, Aug 12, 2019 at 08:06:44PM -0400, Theodore Y. Ts'o wrote:
> > + /* Some inodes still reference this key; try to evict them. */
> > + if (try_to_lock_encrypted_files(sb, mk) != 0)
> > + status_flags |=
> > + FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
> > + }
>
> try_to_lock_encrypted_files() can return other errors besides -EBUSY;
> in particular sync_filesystem() can return other errors, such as -EIO
> or -EFSCORUPTED. In that case, I think we're better off returning the
> relevant status code back to the user. We will have already wiped the
> master key, but this situation will only happen in exceptional
> conditions (e.g., user has ejected the sdcard, etc.), so it's not
> worth it to try to undo the master key wipe to try to restore things
> to the pre-ioctl execution state.
>
> So I think we should capture the return code from
> try_to_lock_encrypted_files, and if it is EBUSY, we can set FILES_BUSY
> flag and return success. Otherwise, we should return the error.
>
> If you agree, please fix that up and then feel free to add:
>
> Reviewed-by: Theodore Ts'o <tytso@mit.edu>
>
> - Ted
Yes, that makes sense. I've made the following change to this patch:
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 9901593051424b..c3423f0edc7014 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -479,6 +479,7 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
struct key *key;
struct fscrypt_master_key *mk;
u32 status_flags = 0;
+ int err;
bool dead;
if (copy_from_user(&arg, uarg, sizeof(arg)))
@@ -514,11 +515,15 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* key object is free to be removed from the keyring.
*/
key_invalidate(key);
+ err = 0;
} else {
/* Some inodes still reference this key; try to evict them. */
- if (try_to_lock_encrypted_files(sb, mk) != 0)
+ err = try_to_lock_encrypted_files(sb, mk);
+ if (err == -EBUSY) {
status_flags |=
FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY;
+ err = 0;
+ }
}
/*
* We return 0 if we successfully did something: wiped the secret, or
@@ -527,7 +532,9 @@ int fscrypt_ioctl_remove_key(struct file *filp, void __user *_uarg)
* including all files locked.
*/
key_put(key);
- return put_user(status_flags, &uarg->removal_status_flags);
+ if (err == 0)
+ err = put_user(status_flags, &uarg->removal_status_flags);
+ return err;
}
EXPORT_SYMBOL_GPL(fscrypt_ioctl_remove_key);
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-08-14 22:35 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 16:25 [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 01/20] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 02/20] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 03/20] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 04/20] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 05/20] fscrypt: rename fscrypt_master_key to fscrypt_direct_key Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 06/20] fscrypt: refactor key setup code in preparation for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 07/20] fscrypt: move v1 policy key setup to keysetup_v1.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 08/20] fscrypt: rename keyinfo.c to keysetup.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 09/20] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-14 22:35 ` Eric Biggers [this message]
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 11/20] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 12/20] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley
2019-08-05 16:25 ` [PATCH v8 13/20] fscrypt: v2 encryption policy support Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 15/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 16/20] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 17/20] ext4: wire up new fscrypt ioctls Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 18/20] f2fs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 19/20] ubifs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [PATCH v8 20/20] fscrypt: document the new ioctls and policy version Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-14 22:37 ` [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-14 22:37 ` [f2fs-dev] " Eric Biggers
2019-08-14 22:37 ` Eric Biggers
2019-08-14 22:37 ` Eric Biggers
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=20190814223542.GE101319@gmail.com \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
--cc=tytso@mit.edu \
/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.