From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH] fscrypt: simplify master key locking
Date: Tue, 24 Nov 2020 15:42:22 -0800 [thread overview]
Message-ID: <X72aXth+cz3k7uvD@sol.localdomain> (raw)
In-Reply-To: <20201117032626.320275-1-ebiggers@kernel.org>
On Mon, Nov 16, 2020 at 07:26:26PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> The stated reasons for separating fscrypt_master_key::mk_secret_sem from
> the standard semaphore contained in every 'struct key' no longer apply.
>
> First, due to commit a992b20cd4ee ("fscrypt: add
> fscrypt_prepare_new_inode() and fscrypt_set_context()"),
> fscrypt_get_encryption_info() is no longer called from within a
> filesystem transaction.
>
> Second, due to commit d3ec10aa9581 ("KEYS: Don't write out to userspace
> while holding key semaphore"), the semaphore for the "keyring" key type
> no longer ranks above page faults.
>
> That leaves performance as the only possible reason to keep the separate
> mk_secret_sem. Specifically, having mk_secret_sem reduces the
> contention between setup_file_encryption_key() and
> FS_IOC_{ADD,REMOVE}_ENCRYPTION_KEY. However, these ioctls aren't
> executed often, so this doesn't seem to be worth the extra complexity.
>
> Therefore, simplify the locking design by just using key->sem instead of
> mk_secret_sem.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> fs/crypto/fscrypt_private.h | 19 ++++++-------------
> fs/crypto/hooks.c | 8 +++++---
> fs/crypto/keyring.c | 8 +-------
> fs/crypto/keysetup.c | 20 +++++++++-----------
> 4 files changed, 21 insertions(+), 34 deletions(-)
Applied to fscrypt.git#master for 5.11.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] fscrypt: simplify master key locking
Date: Tue, 24 Nov 2020 15:42:22 -0800 [thread overview]
Message-ID: <X72aXth+cz3k7uvD@sol.localdomain> (raw)
In-Reply-To: <20201117032626.320275-1-ebiggers@kernel.org>
On Mon, Nov 16, 2020 at 07:26:26PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> The stated reasons for separating fscrypt_master_key::mk_secret_sem from
> the standard semaphore contained in every 'struct key' no longer apply.
>
> First, due to commit a992b20cd4ee ("fscrypt: add
> fscrypt_prepare_new_inode() and fscrypt_set_context()"),
> fscrypt_get_encryption_info() is no longer called from within a
> filesystem transaction.
>
> Second, due to commit d3ec10aa9581 ("KEYS: Don't write out to userspace
> while holding key semaphore"), the semaphore for the "keyring" key type
> no longer ranks above page faults.
>
> That leaves performance as the only possible reason to keep the separate
> mk_secret_sem. Specifically, having mk_secret_sem reduces the
> contention between setup_file_encryption_key() and
> FS_IOC_{ADD,REMOVE}_ENCRYPTION_KEY. However, these ioctls aren't
> executed often, so this doesn't seem to be worth the extra complexity.
>
> Therefore, simplify the locking design by just using key->sem instead of
> mk_secret_sem.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> fs/crypto/fscrypt_private.h | 19 ++++++-------------
> fs/crypto/hooks.c | 8 +++++---
> fs/crypto/keyring.c | 8 +-------
> fs/crypto/keysetup.c | 20 +++++++++-----------
> 4 files changed, 21 insertions(+), 34 deletions(-)
Applied to fscrypt.git#master for 5.11.
- Eric
_______________________________________________
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: linux-fscrypt@vger.kernel.org
Cc: linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] fscrypt: simplify master key locking
Date: Tue, 24 Nov 2020 15:42:22 -0800 [thread overview]
Message-ID: <X72aXth+cz3k7uvD@sol.localdomain> (raw)
In-Reply-To: <20201117032626.320275-1-ebiggers@kernel.org>
On Mon, Nov 16, 2020 at 07:26:26PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> The stated reasons for separating fscrypt_master_key::mk_secret_sem from
> the standard semaphore contained in every 'struct key' no longer apply.
>
> First, due to commit a992b20cd4ee ("fscrypt: add
> fscrypt_prepare_new_inode() and fscrypt_set_context()"),
> fscrypt_get_encryption_info() is no longer called from within a
> filesystem transaction.
>
> Second, due to commit d3ec10aa9581 ("KEYS: Don't write out to userspace
> while holding key semaphore"), the semaphore for the "keyring" key type
> no longer ranks above page faults.
>
> That leaves performance as the only possible reason to keep the separate
> mk_secret_sem. Specifically, having mk_secret_sem reduces the
> contention between setup_file_encryption_key() and
> FS_IOC_{ADD,REMOVE}_ENCRYPTION_KEY. However, these ioctls aren't
> executed often, so this doesn't seem to be worth the extra complexity.
>
> Therefore, simplify the locking design by just using key->sem instead of
> mk_secret_sem.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> fs/crypto/fscrypt_private.h | 19 ++++++-------------
> fs/crypto/hooks.c | 8 +++++---
> fs/crypto/keyring.c | 8 +-------
> fs/crypto/keysetup.c | 20 +++++++++-----------
> 4 files changed, 21 insertions(+), 34 deletions(-)
Applied to fscrypt.git#master for 5.11.
- Eric
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-11-24 23:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 3:26 [PATCH] fscrypt: simplify master key locking Eric Biggers
2020-11-17 3:26 ` Eric Biggers
2020-11-17 3:26 ` [f2fs-dev] " Eric Biggers
2020-11-24 23:42 ` Eric Biggers [this message]
2020-11-24 23:42 ` Eric Biggers
2020-11-24 23:42 ` [f2fs-dev] " 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=X72aXth+cz3k7uvD@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-mtd@lists.infradead.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.