From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Carlos Maiolino <cem@kernel.org>, xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] misc: test the dir/attr hash before formatting or repairing fs
Date: Sat, 18 Mar 2023 11:47:30 +1100 [thread overview]
Message-ID: <ZBUKIjpwiPMzLp2s@destitution> (raw)
In-Reply-To: <20230316165246.GO11376@frogsfrogsfrogs>
On Thu, Mar 16, 2023 at 09:52:46AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> Back in the 6.2-rc1 days, Eric Whitney reported a fstests regression in
> ext4 against generic/454. The cause of this test failure was the
> unfortunate combination of setting an xattr name containing UTF8 encoded
> emoji, an xattr hash function that accepted a char pointer with no
> explicit signedness, signed type extension of those chars to an int, and
> the 6.2 build tools maintainers deciding to mandate -funsigned-char
> across the board. As a result, the ondisk extended attribute structure
> written out by 6.1 and 6.2 were not the same.
>
> This discrepancy, in fact, had been noticeable if a filesystem with such
> an xattr were moved between any two architectures that don't employ the
> same signedness of a raw "char" declaration. The only reason anyone
> noticed is that x86 gcc defaults to signed, and no such -funsigned-char
> update was made to e2fsprogs, so e2fsck immediately started reporting
> data corruption.
>
> After a day and a half of discussing how to handle this use case (xattrs
> with bit 7 set anywhere in the name) without breaking existing users,
> Linus merged his own patch and didn't tell the mailing list. None of
> the developers noticed until AUTOSEL made an announcement.
>
> In the end, this problem could have been detected much earlier if there
> had been any useful tests of hash function(s) in use inside ext4 to make
> sure that they always produce the same outputs given the same inputs.
>
> The XFS dirent/xattr name hash takes a uint8_t*, so I don't think it's
> vulnerable to this problem. However, let's avoid all this drama by
> adding our own self test to check that the da hash produces the same
> outputs for a static pile of inputs on various platforms. This
> corresponds to the similar patch for the kernel.
>
> Link: https://lore.kernel.org/linux-ext4/Y8bpkm3jA3bDm3eL@debian-BULLSEYE-live-builder-AMD64/
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
> libfrog/Makefile | 1
> libfrog/crc32cselftest.h | 17 ++---
> libfrog/dahashselftest.h | 172 ++++++++++++++++++++++++++++++++++++++++++++++
> mkfs/xfs_mkfs.c | 8 ++
> repair/init.c | 5 +
> 5 files changed, 195 insertions(+), 8 deletions(-)
> create mode 100644 libfrog/dahashselftest.h
Looks good.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-03-18 0:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 16:51 [PATCH 1/2] libfrog: move crc32c selftest buffer into a separate file Darrick J. Wong
2023-03-16 16:52 ` [PATCH 2/2] misc: test the dir/attr hash before formatting or repairing fs Darrick J. Wong
2023-03-18 0:47 ` Dave Chinner [this message]
2023-03-18 0:47 ` [PATCH 1/2] libfrog: move crc32c selftest buffer into a separate file Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2023-04-06 0:07 [PATCHSET 0/2] xfsprogs: test the dir/attr hash function Darrick J. Wong
2023-04-06 0:08 ` [PATCH 2/2] misc: test the dir/attr hash before formatting or repairing fs Darrick J. Wong
2023-04-11 5:00 ` Christoph Hellwig
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=ZBUKIjpwiPMzLp2s@destitution \
--to=david@fromorbit.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox