From: Eric Biggers <ebiggers@kernel.org>
To: linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Gabriel Krisman Bertazi <krisman@suse.de>
Subject: [PATCH 1/3] ext4: reject casefold inode flag without casefold feature
Date: Mon, 14 Aug 2023 11:29:01 -0700 [thread overview]
Message-ID: <20230814182903.37267-2-ebiggers@kernel.org> (raw)
In-Reply-To: <20230814182903.37267-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@google.com>
It is invalid for the casefold inode flag to be set without the casefold
superblock feature flag also being set. e2fsck already considers this
case to be invalid and handles it by offering to clear the casefold flag
on the inode. __ext4_iget() also already considered this to be invalid,
sort of, but it only got so far as logging an error message; it didn't
actually reject the inode. Make it reject the inode so that other code
doesn't have to handle this case. This matches what f2fs does.
Note: we could check 's_encoding != NULL' instead of
ext4_has_feature_casefold(). This would make the check robust against
the casefold feature being enabled by userspace writing to the page
cache of the mounted block device. However, it's unsolvable in general
for filesystems to be robust against concurrent writes to the page cache
of the mounted block device. Though this very particular scenario
involving the casefold feature is solvable, we should not pretend that
we can support this model, so let's just check the casefold feature.
tune2fs already forbids enabling casefold on a mounted filesystem.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
fs/ext4/inode.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 43775a6ca505..390dedbb7e8a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4940,9 +4940,12 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
"iget: bogus i_mode (%o)", inode->i_mode);
goto bad_inode;
}
- if (IS_CASEFOLDED(inode) && !ext4_has_feature_casefold(inode->i_sb))
+ if (IS_CASEFOLDED(inode) && !ext4_has_feature_casefold(inode->i_sb)) {
ext4_error_inode(inode, function, line, 0,
"casefold flag without casefold feature");
+ ret = -EFSCORRUPTED;
+ goto bad_inode;
+ }
if ((err_str = check_igot_inode(inode, flags)) != NULL) {
ext4_error_inode(inode, function, line, 0, err_str);
ret = -EFSCORRUPTED;
--
2.41.0
next prev parent reply other threads:[~2023-08-14 18:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 18:29 [PATCH 0/3] Simplify rejection of unexpected casefold inode flag Eric Biggers
2023-08-14 18:29 ` Eric Biggers [this message]
2023-08-14 19:09 ` [PATCH 1/3] ext4: reject casefold inode flag without casefold feature Gabriel Krisman Bertazi
2023-08-14 19:24 ` Eric Biggers
2023-08-14 19:52 ` Gabriel Krisman Bertazi
2023-08-14 18:29 ` [PATCH 2/3] ext4: remove redundant checks of s_encoding Eric Biggers
2023-08-14 18:29 ` [PATCH 3/3] libfs: " Eric Biggers
2023-08-24 4:53 ` [PATCH 0/3] Simplify rejection of unexpected casefold inode flag Theodore Ts'o
2023-09-04 18:11 ` [f2fs-dev] " patchwork-bot+f2fs
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=20230814182903.37267-2-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=krisman@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).