[PATCH v2 1/5] arm64: Rename page table BSS section to .bss..pgtbl

[Frank Li]

On Tue, Jun 16, 2026 at 11:38:48AM +0200, Ard Biesheuvel wrote:
>
>
> On Mon, 15 Jun 2026, at 22:09, Frank Li wrote:
> > On Thu, Jun 04, 2026 at 05:11:53PM +0200, Ard Biesheuvel wrote:
> >> From: Ard Biesheuvel <ardb at kernel.org>
> >>
> >> Rename the .pgdir.bss section to .bss..pgtbl so that the compiler will
> >> notice the leading ".bss" and mark it as NOBITS by default (rather than
> >> PROGBITS, which would take up space in Image binary, forcing all of the
> >> preceding BSS to be emitted into the image as well). This supersedes the
> >> NOLOAD linker directive, which achieves the same thing, and can be
> >> therefore be dropped.
> >>
> >> Also, rename .pgdir to .pgtbl to be more generic, as page tables of
> >> various levels will reside here.
> >>
> >> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> >> ---
> >
> > I met boot failure for i.MX8QXP by this patch
> >
> > [    0.823515] Unable to handle kernel paging request at virtual
> > address ffff00000328f000
> > [    0.831116] Mem abort info:
> > [    0.833886]   ESR = 0x0000000096000147
> > [    0.837622]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    0.842923]   SET = 0, FnV = 0
> > [    0.845961]   EA = 0, S1PTW = 0
> > [    0.849088]   FSC = 0x07: level 3 translation fault
> > [    0.853952] Data abort info:
> > [    0.856809]   ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
> > [    0.862296]   CM = 1, WnR = 1, TnD = 0, TagAccess = 0
> > [    0.867330]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [    0.872633] swapper pgtable: 4k pages, 48-bit VAs,
> > pgdp=000000008211f000
> > [    0.879321] [ffff00000328f000] pgd=0000000000000000,
> > p4d=18000008bffff403, pud=18000008bfffe403, pmd=18000008bffea403,
> > pte=00e800008328ff06
> > [    0.891834] Internal error: Oops: 0000000096000147 [#1]  SMP
> > [    0.897469] Modules linked in:
> > [    0.900514] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> > 7.1.0-rc1-00016-g63e0b6a5b693 #834 PREEMPT
> > [    0.909978] Hardware name: Freescale i.MX8QXP MEK (DT)
> > [    0.915104] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
> > BTYPE=--)
> > [    0.922053] pc : dcache_clean_inval_poc+0x24/0x48
> > [    0.926742] lr : kvm_arm_init+0xa78/0x1638
> > [    0.930828] sp : ffff80008318bd10
> > [    0.934127] x29: ffff80008318bd50 x28: 0000000000000000 x27:
> > ffff00000328f000
> > [    0.941251] x26: 0000000000002000 x25: ffff80008219e000 x24:
> > 0000000001002222
> > [    0.948374] x23: 0000000000000030 x22: ffff800081e850c0 x21:
> > ffff800082b790d0
> > [    0.955498] x20: 0000000000000004 x19: ffff8000830a0000 x18:
> > 0000000000000000
> > [    0.962622] x17: ffff800082f938b8 x16: ffff800082b8b4e0 x15:
> > ffff800082b8b4b8
> > [    0.969746] x14: ffff80008308f0a0 x13: ffff800082b8b490 x12:
> > ffff800082b8b530
> > [    0.976869] x11: ffff800082b8b508 x10: ffff80008308f140 x9 :
> > ffff80008308f118
> > [    0.983993] x8 : ffff80008308f0f0 x7 : ffff80008308f0c8 x6 :
> > ffff80008308f078
> > [    0.991117] x5 : ffff80008308f050 x4 : ffff800082b8b468 x3 :
> > 000000000000003f
> > [    0.998240] x2 : 0000000000000040 x1 : ffff000003291000 x0 :
> > ffff00000328f000
> > [    1.005367] Call trace:
> > [    1.007800]  dcache_clean_inval_poc+0x24/0x48 (P)
> > [    1.012490]  do_one_initcall+0x80/0x1c8
> > [    1.016310]  kernel_init_freeable+0x208/0x2f0
> > [    1.020654]  kernel_init+0x24/0x1e0
> > [    1.024131]  ret_from_fork+0x10/0x20
> > [    1.027700] Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
> > [    1.033779] ---[ end trace 0000000000000000 ]---
> > [    1.038428] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b
> > [    1.046026] SMP: stopping secondary CPUs
> > [    1.049943] Kernel Offset: disabled
> > [    1.053408] CPU features: 0x00000000,00000008,00040021,0400421b
> > [    1.059316] Memory Limit: none
> > [    1.062359] ---[ end Kernel panic - not syncing: Attempted to kill
> > init! exitcode=0x0000000b ]---
> >
> >
> > Any idea?
> >
>
> Which tree is this based on?

Sorry, after rebase to 20260615 linux-next, problem disappear. Problem
appear at next-20260608. Suppose some patch fixed this problem recently.

Frank