Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <7DE6598D-B60D-466F-8771-5FEC0FDEC57F@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_E6AB58D9-A35D-4999-8357-C3D05FF9EC98";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: generic/454 regression in 6.2-rc1
Date:   Tue, 17 Jan 2023 17:10:55 -0700
In-Reply-To: <Y8bpkm3jA3bDm3eL@debian-BULLSEYE-live-builder-AMD64>
Cc:     Ext4 Developers List <linux-ext4@vger.kernel.org>
To:     Eric Whitney <enwlinux@gmail.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>
References: <Y8bpkm3jA3bDm3eL@debian-BULLSEYE-live-builder-AMD64>
Precedence: bulk


--Apple-Mail=_E6AB58D9-A35D-4999-8357-C3D05FF9EC98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jan 17, 2023, at 11:31 AM, Eric Whitney <enwlinux@gmail.com> wrote:
>=20
> My 6.2-rc1 regression run on the current x86-64 test appliance =
revealed a new
> failure for generic/454 on the 4k file system configuration and all =
other
> configurations using a 4k block size.  This failure reproduces with =
100%
> reliability and continues to appear as of 6.2-rc4.
>=20
> The test output indicates that the file system under test is =
inconsistent.

There is actually support in the superblock for both signed and unsigned =
char
hash calculations, exactly because there was a bug like this in the =
past.
It looks like the ext4 code/build is still using the signed hash =
functions:


static int __ext4_fill_super(struct fs_context *fc, struct super_block =
*sb)
{
	:
	:
                if (i & EXT2_FLAGS_UNSIGNED_HASH)
                        sbi->s_hash_unsigned =3D 3;
                else if ((i & EXT2_FLAGS_SIGNED_HASH) =3D=3D 0) {
#ifdef __CHAR_UNSIGNED__
                        if (!sb_rdonly(sb))
                                es->s_flags |=3D
                                        =
cpu_to_le32(EXT2_FLAGS_UNSIGNED_HASH);
                        sbi->s_hash_unsigned =3D 3;
#else
                        if (!sb_rdonly(sb))
                                es->s_flags |=3D
                                        =
cpu_to_le32(EXT2_FLAGS_SIGNED_HASH);
#endif
                }

It looks like this *should* be detecting the unsigned/signed char type
automatically based on __CHAR_UNSIGNED__, but that isn't working =
properly
in this case.  I have no idea whether this is a compiler or kernel =
issue,
just thought I'd point out the background of what ext4 is doing here.

Cheers, Andreas

> e2fsck reports:
>=20
> *** fsck.ext4 output ***
> fsck from util-linux 2.36.1
> e2fsck 1.46.2 (28-Feb-2021)
> Pass 1: Checking inodes, blocks, and sizes
> Extended attribute in inode 131074 has a hash (857950233) which is =
invalid
> Clear? no
>=20
> Extended attribute in inode 131074 has a hash (736302368) which is =
invalid
> Clear? no
>=20
> Extended attribute in inode 131074 has a hash (674453032) which is =
invalid
> Clear? no
>=20
> Extended attribute in inode 131074 has a hash (2299266654) which is =
invalid
> Clear? no
>=20
> Extended attribute in inode 131074 has a hash (3503002490) which is =
invalid
> Clear? no
>=20
> < and continues with more of the same >
>=20
> The failure bisects to the following commit in -rc1:
>=20
> 3bc753c06dd0 ("kbuild: treat char as always unsigned")
>=20
> The comment for this commit suggests that it's likely to cause things =
to
> break where there has been type misuse for char;  presumably, that's =
what's
> happened here.
>=20
> Eric
>=20


Cheers, Andreas


--Apple-Mail=_E6AB58D9-A35D-4999-8357-C3D05FF9EC98
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmPHOQ8ACgkQcqXauRfM
H+A7ww/+KX8Ony4/A0QAS178SGdXM0nVqsMK0fahR+SWCiFNh/Q/2se6sJGgyEPf
8rEP2VRzvFuWRM8vF91QYSPRzuVHpm/pLqT9/yFb6+vvaqX5gyFhL9m9lq+bpKBI
cYiRgeC0lVujw7aYpPeTZwP0owmLkFxyVaBdOapAaNoqJMxcmxnJRlCzHAiCDyEU
q9KNzJk8q2NwVNu8GPDV3ivl5VOHoY+J3k8G/dcV1wbQVxBf6Ym2IOk6kNZQACuH
IflaXhwBPtg9PmUVPTY4dbkbC2/D0VudxMT+9KQkZ/5OkV1jJeuFF8GnfhG/1Z7W
YVJs02fphAT1jKjTXNdy4zEH/qDQT7QQdos4dQBqplmOhwfqHuruxS9sMb5H6ykg
dsQh2Me4Y6wzx/pMZRJbX5q82c6cb5o5l74RsFnG4AqHspeqMtRs37vvgsDh8Fwe
4D6SUxM/uIQ2aCTTN1RdUScuIG3zu43LIgLGrCAc7ptvMO7s2GxlhGc21e49edIf
WnLmvBjDnNiLGdAjnWbXaN70Y10xn2fzVX6VmaHQFVlsJk1vml1g7R4dg6gA1jgA
fSG4DedLhpu1yil5z+npo3ryd2Jua1KnYuHOGUaqs+1cnlgjQSpckNhidp3g5gm2
6tAkNtmCAIbXv4+TipA4XeNiLX7qxmSJcRR8NWYUeITSzT6Cfqg=
=ecss
-----END PGP SIGNATURE-----

--Apple-Mail=_E6AB58D9-A35D-4999-8357-C3D05FF9EC98--