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;
Date:   Tue, 17 Jan 2023 13:31:46 -0500
From:   Eric Whitney <enwlinux@gmail.com>
To:     linux-ext4@vger.kernel.org
Subject: generic/454 regression in 6.2-rc1
Message-ID: <Y8bpkm3jA3bDm3eL@debian-BULLSEYE-live-builder-AMD64>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

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.

The test output indicates that the file system under test is inconsistent.
e2fsck reports:

*** 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

Extended attribute in inode 131074 has a hash (736302368) which is invalid
Clear? no

Extended attribute in inode 131074 has a hash (674453032) which is invalid
Clear? no

Extended attribute in inode 131074 has a hash (2299266654) which is invalid
Clear? no

Extended attribute in inode 131074 has a hash (3503002490) which is invalid
Clear? no

< and continues with more of the same >

The failure bisects to the following commit in -rc1:

3bc753c06dd0 ("kbuild: treat char as always unsigned")

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.

Eric