Message-ID: <1f2b697ee10ba1b1ea2e2128697e1924d2479d4c.camel@xry111.site>
Subject: Re: "kernel ade access" oops on LoongArch
From:   Xi Ruoyao <xry111@xry111.site>
To:     Youling Tang <tangyouling@loongson.cn>
Cc:     Jinyang He <hejinyang@loongson.cn>, loongarch@lists.linux.dev,
        Huacai Chen <chenhuacai@kernel.org>,
        WANG Xuerui <kernel@xen0n.name>, linux-kernel@vger.kernel.org
Date:   Wed, 15 Feb 2023 21:06:21 +0800
In-Reply-To: <6268f221cfca8b7550ad0673246f09cd439ede05.camel@xry111.site>
References: <1e6f4d35946e4e2e7c7f5dcc7b69d5e609de8184.camel@xry111.site>
         <2e902dfa-cb84-7ef0-6b50-02b16354a139@loongson.cn>
         <511d385675ea7a846ff791974c6ae7feeeec2589.camel@xry111.site>
         <9a70e89c-0f3b-0660-501e-3292e410cfd8@loongson.cn>
         <5403e5eb-5792-7d6f-df74-ca3fab82ecd5@loongson.cn>
         <818419c03037bda833a5b281588a4b331c34ae8c.camel@xry111.site>
         <74fb1e24-36c0-c642-5bab-3646ba7790df@loongson.cn>
         <21b0e60dac8bedf9e389645ec103aa4241b35f8d.camel@xry111.site>
         <bf0e57db317d7061ecaaf928ce6cf40941b1740c.camel@xry111.site>
         <6268f221cfca8b7550ad0673246f09cd439ede05.camel@xry111.site>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-02-15 at 20:51 +0800, Xi Ruoyao wrote:
> On Wed, 2023-02-15 at 19:52 +0800, Xi Ruoyao wrote:
> > On Wed, 2023-02-15 at 16:35 +0800, Xi Ruoyao wrote:
> > > On Wed, 2023-02-15 at 16:25 +0800, Youling Tang wrote:
> > > > Can you modify the kernel as follows and test it, so as to avoid
> > > > possible relationship with the exception table data link
> > > > position
> > > > and
> > > > alignment rules (or use EXCEPTION_TABLE(12))?
> > > >=20
> > > > --- a/arch/loongarch/kernel/vmlinux.lds.S
> > > > +++ b/arch/loongarch/kernel/vmlinux.lds.S
> > > > @@ -4,7 +4,6 @@
> > > > =C2=A0 #include <asm/thread_info.h>
> > > >=20
> > > > =C2=A0 #define PAGE_SIZE _PAGE_SIZE
> > > > -#define RO_EXCEPTION_TABLE_ALIGN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 4
> > > >=20
> > > > =C2=A0 /*
> > > > =C2=A0=C2=A0 * Put .bss..swapper_pg_dir as the first thing in .bss.=
 This
> > > > will
> > > > @@ -54,6 +53,8 @@ SECTIONS
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . =3D ALIGN(PECOFF=
_SEGMENT_ALIGN);
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _etext =3D .;
> > > >=20
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EXCEPTION_TABLE(16)
> > > > +
> > >=20
> > > It seems the kernel refuses to boot after the change, but I'm not
> > > completely sure: I'm 5 km away from the board and operating it via
> > > ssh
> > > so maybe it's a reboot failure or network failure.=C2=A0 I'll report
> > > again in
> > > the evening.
> >=20
> > It was a reboot failure.
> >=20
> > Now it has booted successfully, but the stack trace still shows
> > (during
> > the 25th run of the make test t=3D... command).
>=20
> Ouch, I know what's happening...
>=20
> In the architecture-independent code we have something like
>=20
> extern struct exception_table_entry a[], b[];
> bsearch(a, b - a);
>=20
> According to the C standard, when you write "b - a" where a and b are
> pointers to type T, "b" and "a" must be pointers to elements in the
> same
> array of T.=C2=A0 So the compiler can assume ((uintptr_t)b - (uintptr_t)a=
)
> %
> 12 =3D=3D 0 and optimize "b - a" to something like
>=20
> (((uintptr_t)b - (uintptr_t)a) >> 2) * inv3
>=20
> Here inv3 is the inversion of 3 in the modulo-2**64 integer ring, so
> the
> compiler can avoid an expensive divide instruction.=C2=A0 But in my vmlin=
ux
> ((uintptr_t)b - (uintptr_t)a) is somehow not a multiple of 12:
>=20
> (gdb) p ((uintptr_t)__stop___ex_table - (uintptr_t)__start___ex_table)
> % sizeof(struct exception_table_entry)
> $9 =3D 8
>=20
> So I guess
>=20
> #define RO_EXCEPTION_TABLE_ALIGN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12
>=20
> will work.=C2=A0 I'll take a try...

No, it's not related...

The reason is the "LoongArch: Add vector extensions support" in my local
repo is not same as the version in loongarch-next!  My local version
contains some ".section __ex_table", and the content seems predates the
relative exception table change.

Sorry for wasted you guys an afternoon :(.

--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University