From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
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-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: [GIT PULL] fscrypt updates for 5.11
Date: Sun, 13 Dec 2020 21:50:19 -0800 [thread overview]
Message-ID: <X9b9G8p8AiRAzDwV@sol.localdomain> (raw)
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt-for-linus
for you to fetch changes up to a14d0b6764917b21ee6fdfd2a8a4c2920fbefcce:
fscrypt: allow deleting files with unsupported encryption policy (2020-12-02 18:25:01 -0800)
----------------------------------------------------------------
This release there are some fixes for longstanding problems, as well as
some cleanups:
- Fix a race condition where a duplicate filename could be created in an
encrypted directory if a syscall that creates a new filename raced
with the directory's encryption key being added.
- Allow deleting files that use an unsupported encryption policy.
- Simplify the locking for 'struct fscrypt_master_key'.
- Remove kernel-internal constants from the UAPI header.
As usual, all these patches have been in linux-next with no reported
issues, and I've tested them with xfstests.
----------------------------------------------------------------
Eric Biggers (16):
fscrypt: remove kernel-internal constants from UAPI header
fscrypt: add fscrypt_is_nokey_name()
ext4: prevent creating duplicate encrypted filenames
f2fs: prevent creating duplicate encrypted filenames
ubifs: prevent creating duplicate encrypted filenames
fscrypt: remove unnecessary calls to fscrypt_require_key()
fscrypt: simplify master key locking
ext4: remove ext4_dir_open()
f2fs: remove f2fs_dir_open()
ubifs: remove ubifs_dir_open()
ext4: don't call fscrypt_get_encryption_info() from dx_show_leaf()
fscrypt: introduce fscrypt_prepare_readdir()
fscrypt: move body of fscrypt_prepare_setattr() out-of-line
fscrypt: move fscrypt_require_key() to fscrypt_private.h
fscrypt: unexport fscrypt_get_encryption_info()
fscrypt: allow deleting files with unsupported encryption policy
fs/crypto/fname.c | 8 +++-
fs/crypto/fscrypt_private.h | 56 +++++++++++++++-------
fs/crypto/hooks.c | 55 +++++++++++----------
fs/crypto/keyring.c | 10 +---
fs/crypto/keysetup.c | 44 +++++++++++------
fs/crypto/policy.c | 27 +++++++----
fs/ext4/dir.c | 16 ++-----
fs/ext4/namei.c | 13 ++---
fs/f2fs/dir.c | 10 +---
fs/f2fs/f2fs.h | 2 +
fs/ubifs/dir.c | 28 +++++------
include/linux/fscrypt.h | 112 ++++++++++++++++++++++++++++---------------
include/uapi/linux/fscrypt.h | 5 +-
13 files changed, 227 insertions(+), 159 deletions(-)
next reply other threads:[~2020-12-14 5:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-14 5:50 Eric Biggers [this message]
2020-12-14 20:56 ` [GIT PULL] fscrypt updates for 5.11 pr-tracker-bot
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=X9b9G8p8AiRAzDwV@sol.localdomain \
--to=ebiggers@kernel.org \
--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=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=torvalds@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox