Received-SPF: softfail (google.com: domain of transitioning linux-ext4-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Gabriel Krisman Bertazi <krisman@collabora.com>
To:     "Stephen E. Baker" <baker.stephen.e@gmail.com>
Cc:     amstan@chromium.org, "Theodore Ts'o" <tytso@mit.edu>,
        linux-ext4@vger.kernel.org
Subject: Re: simplify ext4_sb_read_encoding regression
Organization: Collabora
References: <CAFDdnB38yRcZ+mQButh9UwGoh928xsZCgmjQ7r3HPEpEwdrZbg@mail.gmail.com>
        <87sfor85j1.fsf@collabora.com>
        <CAFDdnB3U67YJ7pivdHQaMB-CkdmvvTbcpxp1FXxBmFyAgJPknw@mail.gmail.com>
        <874k13t0tk.fsf@collabora.com>
        <CAFDdnB143WXo2sz5trAhh2nH=CJ50U3GgkgDe_YJ394=G6ongg@mail.gmail.com>
        <CAFDdnB0uH_KqpN12pE2pyfb-vh_6Uab8Xdcb=NzQQy8ATEL+gA@mail.gmail.com>
Date:   Sun, 05 Jun 2022 02:23:26 -0400
In-Reply-To: <CAFDdnB0uH_KqpN12pE2pyfb-vh_6Uab8Xdcb=NzQQy8ATEL+gA@mail.gmail.com>
        (Stephen E. Baker's message of "Sat, 4 Jun 2022 23:21:46 -0400")
Message-ID: <87tu8zsk69.fsf@collabora.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

"Stephen E. Baker" <baker.stephen.e@gmail.com> writes:

> On Sat, Jun 4, 2022 at 8:11 PM Stephen E. Baker
> <baker.stephen.e@gmail.com> wrote:
>>
>> I reached out on the archlinuxarm IRC room and amstan offered the use
>> of his device.
>>
>> When he boots my image he sees:
>> "EXT4-fs (sda2): can't mount with superblock charset: utf8-12.1.0 not
>> supported by the kernel. flags: 0x0."
>
> At amstan's request I created a new root filesystem without casefold,
> and created a loop device with casefold enabled. I am able to boot
> with that filesystem.
>
> zgrep UNICODE /proc/config
> CONFIG_UNICODE=y
> CONFIG_UNICODE_UTF8_DATA=y
> CONFIG_UNICODE_NORMALIZATION_SELFTEST=m
>
> mount /dev/loop0p1 /mnt
> [ 679.358591] EXT-fs (loop0p1): can't mount with superblock charset:
> utf8-12.1.0 not supported by the kernel. flags: 0x0

That is great news.  It should allow us to do more investigation.  This
message can unfortunately come from a few error cases, but, most likely,
it is from a failure to get the utf8_data_table symbol.

Since you don't need the module to boot this kernel anymore now that
your rootfs is no longer casefolded, can you try building with
CONFIG_UNICODE=m, modprobe the module, and see if you can mount
/dev/loop0p1 successfully?  If it works, we should be able to discard
the steps being done to generate the bootable uimg and the flashing from
the equation being done at [1].

I've built a vanilla aarch64 kernel and ran over qemu, but I haven't
been able to reproduce it, or notice anything out of the ordinary in the
symbols.  It makes this bug quite puzzling at the moment.

[1] https://github.com/archlinuxarm/PKGBUILDs/blob/30c181baea493effe3bea7b3a2c3ec6ee62b41ae/core/linux-aarch64/PKGBUILD#L201-L228.

-- 
Gabriel Krisman Bertazi