From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Satya Tangirala <satyat@google.com>,
Paul Crowley <paulcrowley@google.com>,
Paul Lawrence <paullawrence@google.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies
Date: Wed, 6 Nov 2019 21:49:19 -0500 [thread overview]
Message-ID: <20191107024919.GH26959@mit.edu> (raw)
In-Reply-To: <20191106040519.GA705@sol.localdomain>
On Tue, Nov 05, 2019 at 08:05:19PM -0800, Eric Biggers wrote:
> If we really wanted to optimize fscrypt_get_encryption_info(), I think we
> probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather
> take advantage of the fact that fscrypt_has_permitted_context() already ran.
> E.g., we could cache the xattr, or skip both the keyring lookup and
> fscrypt_supported_policy() by grabbing them from the parent directory.
Yes, good point. Certainly, if the parent is encrypted, given that we
force files to have the same policy as the containing directory,
there's no point calling fscrypt_supported_policy. And if we're using
a policy which isn't using per-inode keys, then we can certainly just
grab the key from the parent directory.
- Ted
next prev parent reply other threads:[~2019-11-07 2:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers
2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers
2019-10-29 17:47 ` Paul Crowley
2019-11-06 3:35 ` Theodore Y. Ts'o
2019-11-06 4:05 ` Eric Biggers
2019-11-07 2:49 ` Theodore Y. Ts'o [this message]
2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers
2019-11-06 3:26 ` Theodore Y. Ts'o
2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers
2019-11-01 18:33 ` Jaegeuk Kim
2019-11-01 18:02 ` [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers
2019-11-06 21:04 ` 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=20191107024919.GH26959@mit.edu \
--to=tytso@mit.edu \
--cc=jaegeuk@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=paulcrowley@google.com \
--cc=paullawrence@google.com \
--cc=satyat@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).