On Jan 17, 2023, at 11:31 AM, Eric Whitney <enwlinux@xxxxxxxxx> wrote:
>
> 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.
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 = 3;
else if ((i & EXT2_FLAGS_SIGNED_HASH) == 0) {
#ifdef __CHAR_UNSIGNED__
if (!sb_rdonly(sb))
es->s_flags |=
cpu_to_le32(EXT2_FLAGS_UNSIGNED_HASH);
sbi->s_hash_unsigned = 3;
#else
if (!sb_rdonly(sb))
es->s_flags |=
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:
>
> *** 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
>
Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
