Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Christoph Biedl]

[-- Attachment #1: Type: text/plain, Size: 6723 bytes --]

, nodemask=(null)"
Reply-To: 
Message-ID: <1690917866@msgid.manchmal.in-ulm.de>

Greetings,

it took a while to find some time for bisecting, but finally:

after upgrading from 6.3 to 6.4, my old HPPA/PA-RISC box started
throwing traces and became unusable, details below. I'm a little
surprised apparently nobody else got bitten by this.

This still happens with 6.5-rc4, bisecting led to:

    700d2e9a36b93601270c1e15550acde2521386c5 is the first bad commit
    commit 700d2e9a36b93601270c1e15550acde2521386c5
    Author: Vlastimil Babka <vbabka@suse.cz>
    Date:   Thu Feb 16 10:51:31 2023 +0100

        mm, page_alloc: reduce page alloc/free sanity checks

Does this make sense? Anything I could try out?

    Christoph


    Linux version 6.3.0-rc4+ (linux@localhost) (hppa-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #16 Tue Aug  1 21:11:13 CEST 2023
    FP[0] enabled: Rev 1 Model 16
    The 32-bit Kernel has started...
    Kernel default page size is 4 KB. Huge pages enabled with 4 MB physical and 4 MB virtual size.
    Determining PDC firmware type: System Map.
    model 00005cf0 00000481 00000000 00000002 776d19ff 100000f0 00000008 000000b2 000000b2
    vers  00000300
    CPUID vers 17 rev 10 (0x0000022a)
    capabilities 0x3
    HP-UX model name: 9000/785/C3600
    Memory Ranges:
     0) Start 0x0000000000000000 End 0x000000003fffffff Size   1024 MB
    Total Memory: 1024 MB
    initrd: 4f4a1000-4ffedd01
    initrd: reserving 3f4a1000-3ffedd01 (mem_max 40000000)
    PDT: type PDT_PDC, size 50, entries 0, status 2, dbe_loc 0xffffffff, good_mem 8 MB
    PDT: Firmware reports all memory OK.
    Zone ranges:
      Normal   [mem 0x0000000000000000-0x000003ffffffffff]
    Movable zone start for each node
    Early memory node ranges
      node   0: [mem 0x0000000000000000-0x000000003fffffff]
    Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
    LCD display at f05d0008,f05d0000 registered
    Built 1 zonelists, mobility grouping on.  Total pages: 259840
    Kernel command line:  (...)
    earlycon: pdc0 at MMIO32be 0x00000000 (options '')
    printk: bootconsole [pdc0] enabled
    Unknown kernel command line parameters "palo_kernel=2/vmlinuz.bisect", will be passed to user space.
    Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
    Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
    swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO), nodemask=(null)
    CPU: 0 PID: 0 Comm: swapper Not tainted 6.3.0-rc4+ #16
    Hardware name: 9000/785/C3600
    Backtrace:
     [<10408594>] show_stack+0x48/0x5c
     [<10e152d8>] dump_stack_lvl+0x48/0x64
     [<10e15318>] dump_stack+0x24/0x34
     [<105cf7f8>] warn_alloc+0x10c/0x1c8
     [<105d068c>] __alloc_pages+0xbbc/0xcf8
     [<105d0e4c>] __get_free_pages+0x28/0x78
     [<105ad10c>] __pte_alloc_kernel+0x30/0x98
     [<10406934>] set_fixmap+0xec/0xf4
     [<10411ad4>] patch_map.constprop.0+0xa8/0xdc
     [<10411bb0>] __patch_text_multiple+0xa8/0x208
     [<10411d78>] patch_text+0x30/0x48
     [<1041246c>] arch_jump_label_transform+0x90/0xcc
     [<1056f734>] jump_label_update+0xd4/0x184
     [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
     [<1056fd08>] static_key_enable+0x1c/0x2c
     [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
     [<1010141c>] start_kernel+0x5f0/0xa98
     [<10105da8>] start_parisc+0xb8/0xe4

    Mem-Info:
    active_anon:0 inactive_anon:0 isolated_anon:0
     active_file:0 inactive_file:0 isolated_file:0
     unevictable:0 dirty:0 writeback:0
     slab_reclaimable:0 slab_unreclaimable:0
     mapped:0 shmem:0 pagetables:0
     sec_pagetables:0 bounce:0
     kernel_misc_reclaimable:0
     free:0 free_pcp:0 free_cma:0
    Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:0kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no
    Normal free:0kB boost:0kB min:0kB low:0kB high:0kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:1048576kB managed:1039360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
    lowmem_reserve[]: 0 0
    Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
    0 total pagecache pages
    0 pages in swap cache
    Free swap  = 0kB
    Total swap = 0kB
    262144 pages RAM
    0 pages HighMem/MovableOnly
    2304 pages reserved
    Backtrace:
     [<10411d78>] patch_text+0x30/0x48
     [<1041246c>] arch_jump_label_transform+0x90/0xcc
     [<1056f734>] jump_label_update+0xd4/0x184
     [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
     [<1056fd08>] static_key_enable+0x1c/0x2c
     [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
     [<1010141c>] start_kernel+0x5f0/0xa98
     [<10105da8>] start_parisc+0xb8/0xe4

    Kernel Fault: Code=15 (Data TLB miss fault) at addr 0f7fe3c0
    CPU: 0 PID: 0 Comm: swapper Not tainted 6.3.0-rc4+ #16
    Hardware name: 9000/785/C3600
    
         YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
    PSW: 00000000000001000000000000001110 Not tainted
    r00-03  0004000e 10ff31b0 10411bb0 11400300
    r04-07  00000004 0f7fe3c0 105cb3c0 10ff6794
    r08-11  1140029c 0f7fe3c0 10f43000 10f43000
    r12-15  1160e9b0 00000000 10f3f000 10f3f000
    r16-19  f00008c4 f000017c f0000174 00001000
    r20-23  00000045 3fffbfff 10407794 fffffffe
    r24-27  0f7ff000 0f7ff000 00000000 10ff31b0
    r28-31  e80002a2 11583c78 11400380 00013ffb
    sr00-03  00000000 00000000 00000000 00000000
    sr04-07  00000000 00000000 00000000 00000000
    
    IASQ: 00000000 00000000 IAOQ: 10411bcc 10411bd0
     IIR: 0cbc1280    ISR: 00000000  IOR: 0f7fe3c0
     CPU:        0   CR30: 1140d510 CR31: 11111111
     ORIG_R28: 00000000
     IAOQ[0]: __patch_text_multiple+0xc4/0x208
     IAOQ[1]: __patch_text_multiple+0xc8/0x208
     RP(r2): __patch_text_multiple+0xa8/0x208
    Backtrace:
     [<10411d78>] patch_text+0x30/0x48
     [<1041246c>] arch_jump_label_transform+0x90/0xcc
     [<1056f734>] jump_label_update+0xd4/0x184
     [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
     [<1056fd08>] static_key_enable+0x1c/0x2c
     [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
     [<1010141c>] start_kernel+0x5f0/0xa98
     [<10105da8>] start_parisc+0xb8/0xe4
    
    Kernel panic - not syncing: Kernel Fault
    Rebooting in 60 seconds..


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[John David Anglin]

On 2023-08-01 3:37 p.m., Christoph Biedl wrote:
> Greetings,
>
> it took a while to find some time for bisecting, but finally:
>
> after upgrading from 6.3 to 6.4, my old HPPA/PA-RISC box started
> throwing traces and became unusable, details below. I'm a little
> surprised apparently nobody else got bitten by this.
Helge and I have both encountered this issue.  Thanks for bisecting!

-- 
John David Anglin  dave.anglin@bell.net

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Mike Rapoport]

Hi Christoph,

On Tue, Aug 01, 2023 at 09:37:11PM +0200, Christoph Biedl wrote:
> 
> Greetings,
> 
> it took a while to find some time for bisecting, but finally:
> 
> after upgrading from 6.3 to 6.4, my old HPPA/PA-RISC box started
> throwing traces and became unusable, details below. I'm a little
> surprised apparently nobody else got bitten by this.
> 
> This still happens with 6.5-rc4, bisecting led to:
> 
>     700d2e9a36b93601270c1e15550acde2521386c5 is the first bad commit
>     commit 700d2e9a36b93601270c1e15550acde2521386c5
>     Author: Vlastimil Babka <vbabka@suse.cz>
>     Date:   Thu Feb 16 10:51:31 2023 +0100
> 
>         mm, page_alloc: reduce page alloc/free sanity checks
> 
> Does this make sense? Anything I could try out?

Looks like this commit somehow exposed that if static keys are
enabled/disabled before page allocator is initialized, the set_fixmap()
fails to allocate a page for pte. I'm still not sure why bisect pointed to
this commit because it does not really change the order in which static
keys are set up.

Can you check if the patch helps:

diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
index cc15d737fda6..ae3493dae9dc 100644
--- a/arch/parisc/mm/fixmap.c
+++ b/arch/parisc/mm/fixmap.c
@@ -19,9 +19,6 @@ void notrace set_fixmap(enum fixed_addresses idx, phys_addr_t phys)
 	pmd_t *pmd = pmd_offset(pud, vaddr);
 	pte_t *pte;
 
-	if (pmd_none(*pmd))
-		pte = pte_alloc_kernel(pmd, vaddr);
-
 	pte = pte_offset_kernel(pmd, vaddr);
 	set_pte_at(&init_mm, vaddr, pte, __mk_pte(phys, PAGE_KERNEL_RWX));
 	flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index b0c43f3b0a5f..2d5916018c71 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -610,6 +610,26 @@ void __init mem_init(void)
 unsigned long *empty_zero_page __ro_after_init;
 EXPORT_SYMBOL(empty_zero_page);
 
+static void __init early_fixmap_init(void)
+{
+	unsigned long addr = FIXMAP_START;
+	unsigned long end = FIXMAP_START + FIXMAP_SIZE;
+	pgd_t *pgd = pgd_offset_k(addr);
+	p4d_t *p4d = p4d_offset(pgd, addr);
+	pud_t *pud = pud_offset(p4d, addr);
+	pmd_t *pmd = pmd_offset(pud, addr);
+
+	do {
+		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+		if (!pte)
+			panic("fixmap: failed to allocate pte\n");
+
+		pmd_populate_kernel(&init_mm, pmd, pte);
+
+		addr += PAGE_SIZE;
+	} while (addr < end);
+}
+
 /*
  * pagetable_init() sets up the page tables
  *
@@ -649,6 +669,7 @@ static void __init pagetable_init(void)
 	if (!empty_zero_page)
 		panic("zero page allocation failed.\n");
 
+	early_fixmap_init();
 }
 
 static void __init gateway_init(void)
 
>     Christoph
> 
> 
>     Linux version 6.3.0-rc4+ (linux@localhost) (hppa-linux-gnu-gcc (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #16 Tue Aug  1 21:11:13 CEST 2023
>     FP[0] enabled: Rev 1 Model 16
>     The 32-bit Kernel has started...
>     Kernel default page size is 4 KB. Huge pages enabled with 4 MB physical and 4 MB virtual size.
>     Determining PDC firmware type: System Map.
>     model 00005cf0 00000481 00000000 00000002 776d19ff 100000f0 00000008 000000b2 000000b2
>     vers  00000300
>     CPUID vers 17 rev 10 (0x0000022a)
>     capabilities 0x3
>     HP-UX model name: 9000/785/C3600
>     Memory Ranges:
>      0) Start 0x0000000000000000 End 0x000000003fffffff Size   1024 MB
>     Total Memory: 1024 MB
>     initrd: 4f4a1000-4ffedd01
>     initrd: reserving 3f4a1000-3ffedd01 (mem_max 40000000)
>     PDT: type PDT_PDC, size 50, entries 0, status 2, dbe_loc 0xffffffff, good_mem 8 MB
>     PDT: Firmware reports all memory OK.
>     Zone ranges:
>       Normal   [mem 0x0000000000000000-0x000003ffffffffff]
>     Movable zone start for each node
>     Early memory node ranges
>       node   0: [mem 0x0000000000000000-0x000000003fffffff]
>     Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
>     LCD display at f05d0008,f05d0000 registered
>     Built 1 zonelists, mobility grouping on.  Total pages: 259840
>     Kernel command line:  (...)
>     earlycon: pdc0 at MMIO32be 0x00000000 (options '')
>     printk: bootconsole [pdc0] enabled
>     Unknown kernel command line parameters "palo_kernel=2/vmlinuz.bisect", will be passed to user space.
>     Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
>     Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>     swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO), nodemask=(null)
>     CPU: 0 PID: 0 Comm: swapper Not tainted 6.3.0-rc4+ #16
>     Hardware name: 9000/785/C3600
>     Backtrace:
>      [<10408594>] show_stack+0x48/0x5c
>      [<10e152d8>] dump_stack_lvl+0x48/0x64
>      [<10e15318>] dump_stack+0x24/0x34
>      [<105cf7f8>] warn_alloc+0x10c/0x1c8
>      [<105d068c>] __alloc_pages+0xbbc/0xcf8
>      [<105d0e4c>] __get_free_pages+0x28/0x78
>      [<105ad10c>] __pte_alloc_kernel+0x30/0x98
>      [<10406934>] set_fixmap+0xec/0xf4
>      [<10411ad4>] patch_map.constprop.0+0xa8/0xdc
>      [<10411bb0>] __patch_text_multiple+0xa8/0x208
>      [<10411d78>] patch_text+0x30/0x48
>      [<1041246c>] arch_jump_label_transform+0x90/0xcc
>      [<1056f734>] jump_label_update+0xd4/0x184
>      [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
>      [<1056fd08>] static_key_enable+0x1c/0x2c
>      [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
>      [<1010141c>] start_kernel+0x5f0/0xa98
>      [<10105da8>] start_parisc+0xb8/0xe4
> 
>     Mem-Info:
>     active_anon:0 inactive_anon:0 isolated_anon:0
>      active_file:0 inactive_file:0 isolated_file:0
>      unevictable:0 dirty:0 writeback:0
>      slab_reclaimable:0 slab_unreclaimable:0
>      mapped:0 shmem:0 pagetables:0
>      sec_pagetables:0 bounce:0
>      kernel_misc_reclaimable:0
>      free:0 free_pcp:0 free_cma:0
>     Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:0kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no
>     Normal free:0kB boost:0kB min:0kB low:0kB high:0kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:1048576kB managed:1039360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>     lowmem_reserve[]: 0 0
>     Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>     0 total pagecache pages
>     0 pages in swap cache
>     Free swap  = 0kB
>     Total swap = 0kB
>     262144 pages RAM
>     0 pages HighMem/MovableOnly
>     2304 pages reserved
>     Backtrace:
>      [<10411d78>] patch_text+0x30/0x48
>      [<1041246c>] arch_jump_label_transform+0x90/0xcc
>      [<1056f734>] jump_label_update+0xd4/0x184
>      [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
>      [<1056fd08>] static_key_enable+0x1c/0x2c
>      [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
>      [<1010141c>] start_kernel+0x5f0/0xa98
>      [<10105da8>] start_parisc+0xb8/0xe4
> 
>     Kernel Fault: Code=15 (Data TLB miss fault) at addr 0f7fe3c0
>     CPU: 0 PID: 0 Comm: swapper Not tainted 6.3.0-rc4+ #16
>     Hardware name: 9000/785/C3600
>     
>          YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>     PSW: 00000000000001000000000000001110 Not tainted
>     r00-03  0004000e 10ff31b0 10411bb0 11400300
>     r04-07  00000004 0f7fe3c0 105cb3c0 10ff6794
>     r08-11  1140029c 0f7fe3c0 10f43000 10f43000
>     r12-15  1160e9b0 00000000 10f3f000 10f3f000
>     r16-19  f00008c4 f000017c f0000174 00001000
>     r20-23  00000045 3fffbfff 10407794 fffffffe
>     r24-27  0f7ff000 0f7ff000 00000000 10ff31b0
>     r28-31  e80002a2 11583c78 11400380 00013ffb
>     sr00-03  00000000 00000000 00000000 00000000
>     sr04-07  00000000 00000000 00000000 00000000
>     
>     IASQ: 00000000 00000000 IAOQ: 10411bcc 10411bd0
>      IIR: 0cbc1280    ISR: 00000000  IOR: 0f7fe3c0
>      CPU:        0   CR30: 1140d510 CR31: 11111111
>      ORIG_R28: 00000000
>      IAOQ[0]: __patch_text_multiple+0xc4/0x208
>      IAOQ[1]: __patch_text_multiple+0xc8/0x208
>      RP(r2): __patch_text_multiple+0xa8/0x208
>     Backtrace:
>      [<10411d78>] patch_text+0x30/0x48
>      [<1041246c>] arch_jump_label_transform+0x90/0xcc
>      [<1056f734>] jump_label_update+0xd4/0x184
>      [<1056fc9c>] static_key_enable_cpuslocked+0xc0/0x110
>      [<1056fd08>] static_key_enable+0x1c/0x2c
>      [<1011362c>] init_mem_debugging_and_hardening+0xdc/0xf8
>      [<1010141c>] start_kernel+0x5f0/0xa98
>      [<10105da8>] start_parisc+0xb8/0xe4
>     
>     Kernel panic - not syncing: Kernel Fault
>     Rebooting in 60 seconds..
> 



-- 
Sincerely yours,
Mike.

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Christoph Biedl]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

Mike Rapoport wrote...

> Can you check if the patch helps:
> 
> diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
> index cc15d737fda6..ae3493dae9dc 100644
(...)

Yes, everything's fine now. Applied on top of v6.5-rc4, there
were some offsets.

    Christoph

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[John David Anglin]

On 2023-08-02 3:20 p.m., Christoph Biedl wrote:
> Mike Rapoport wrote...
>
>> Can you check if the patch helps:
>>
>> diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
>> index cc15d737fda6..ae3493dae9dc 100644
> (...)
>
> Yes, everything's fine now. Applied on top of v6.5-rc4, there
> were some offsets.
Same here.  Applied on v6.4.7 stable.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Christoph Biedl]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Christoph Biedl wrote...

> Mike Rapoport wrote...
> 
> > Can you check if the patch helps:
> > 
> > diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
> > index cc15d737fda6..ae3493dae9dc 100644
> (...)
> 
> Yes, everything's fine now. Applied on top of v6.5-rc4, there
> were some offsets.

Now confirmed on top of 6.4.8 as well.

However, there's now an issue when reconfiguring the locales package in
Debian:

    Setting up locales (2.37-7) ...
    Generating locales (this might take a while)...
      C.UTF-8...cannot map archive header: Invalid argument
     done

Using 6.3.13, everything is fine.

There a Debian bug report #552233 from very old ages about this, the
solution suggests this is related to memory management so it might apply
here, too.

Unfortunately, I'll very *very* limited time to test things in the next
weeks.

    Christoph

¹ https://bugs.debian.org/552233

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Helge Deller]

On 8/6/23 21:21, Christoph Biedl wrote:
> Christoph Biedl wrote...
>
>> Mike Rapoport wrote...
>>
>>> Can you check if the patch helps:
>>>
>>> diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
>>> index cc15d737fda6..ae3493dae9dc 100644
>> (...)
>>
>> Yes, everything's fine now. Applied on top of v6.5-rc4, there
>> were some offsets.
>
> Now confirmed on top of 6.4.8 as well.
>
> However, there's now an issue when reconfiguring the locales package in
> Debian:
>
>      Setting up locales (2.37-7) ...
>      Generating locales (this might take a while)...
>        C.UTF-8...cannot map archive header: Invalid argument
>       done
>
> Using 6.3.13, everything is fine.
>
> There a Debian bug report #552233 from very old ages about this, the
> solution suggests this is related to memory management so it might apply
> here, too.

I'm afraid that my patch:
commit 32832a407a7178eec3215fad9b1a3298c14b0d69
Author: Helge Deller <deller@gmx.de>
Date:   Fri Jul 21 17:24:31 2023 +0200

     io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()

might be the culprit...

Helge

Re: Regression with kernel 6.4 "swapper: page allocation failure: order:0, mode:0x100(__GFP_ZERO)

[Helge Deller]

On 8/6/23 21:54, Helge Deller wrote:
> On 8/6/23 21:21, Christoph Biedl wrote:
>> Christoph Biedl wrote...
>>
>>> Mike Rapoport wrote...
>>>
>>>> Can you check if the patch helps:
>>>>
>>>> diff --git a/arch/parisc/mm/fixmap.c b/arch/parisc/mm/fixmap.c
>>>> index cc15d737fda6..ae3493dae9dc 100644
>>> (...)
>>>
>>> Yes, everything's fine now. Applied on top of v6.5-rc4, there
>>> were some offsets.
>>
>> Now confirmed on top of 6.4.8 as well.
>>
>> However, there's now an issue when reconfiguring the locales package in
>> Debian:
>>
>>      Setting up locales (2.37-7) ...
>>      Generating locales (this might take a while)...
>>        C.UTF-8...cannot map archive header: Invalid argument
>>       done
>>
>> Using 6.3.13, everything is fine.
>>
>> There a Debian bug report #552233 from very old ages about this, the
>> solution suggests this is related to memory management so it might apply
>> here, too.
>
> I'm afraid that my patch:
> commit 32832a407a7178eec3215fad9b1a3298c14b0d69
> Author: Helge Deller <deller@gmx.de>
> Date:   Fri Jul 21 17:24:31 2023 +0200
>
>      io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()
>
> might be the culprit...

could you test this (copy&pasted) patch?
(it will break io_uring, but this is just a test)

diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index ca2d537e25b1..6c94e8da19b7 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -117,7 +117,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp,
         do_color_align = 0;
         if (filp || (flags & MAP_SHARED))
                 do_color_align = 1;
-       filp_pgoff = GET_FILP_PGOFF(filp, addr);
+       filp_pgoff = GET_FILP_PGOFF(filp, 0);

         if (flags & MAP_FIXED) {
                 /* Even MAP_FIXED mappings must reside within TASK_SIZE */

[PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Helge Deller]

The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
using architecture-provided get_unmapped_area()") to the parisc
implementation of get_unmapped_area() broke glibc's locale-gen
executable when running on parisc.

This patch reverts those architecture-specific changes, and instead
adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
then given to parisc's get_unmapped_area() function.  This is much
cleaner than the previous approach, and we still will get a coherent
addresss.

This patch has no effect on other architectures (SHM_COLOUR is only
defined on parisc), and the liburing testcase stil passes on parisc.

Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Fixes: 32832a407a71 ("io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()")
Fixes: d808459b2e31 ("io_uring: Adjust mapping wrt architecture aliasing requirements")

diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index ca2d537e25b1..9915062d5243 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -27,17 +27,12 @@
 #include <linux/elf-randomize.h>

 /*
- * Construct an artificial page offset for the mapping based on the virtual
+ * Construct an artificial page offset for the mapping based on the physical
  * address of the kernel file mapping variable.
- * If filp is zero the calculated pgoff value aliases the memory of the given
- * address. This is useful for io_uring where the mapping shall alias a kernel
- * address and a userspace adress where both the kernel and the userspace
- * access the same memory region.
  */
-#define GET_FILP_PGOFF(filp, addr)		\
-	((filp ? (((unsigned long) filp->f_mapping) >> 8)	\
-		 & ((SHM_COLOUR-1) >> PAGE_SHIFT) : 0UL)	\
-	  + (addr >> PAGE_SHIFT))
+#define GET_FILP_PGOFF(filp)		\
+	(filp ? (((unsigned long) filp->f_mapping) >> 8)	\
+		 & ((SHM_COLOUR-1) >> PAGE_SHIFT) : 0UL)

 static unsigned long shared_align_offset(unsigned long filp_pgoff,
 					 unsigned long pgoff)
@@ -117,7 +112,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp,
 	do_color_align = 0;
 	if (filp || (flags & MAP_SHARED))
 		do_color_align = 1;
-	filp_pgoff = GET_FILP_PGOFF(filp, addr);
+	filp_pgoff = GET_FILP_PGOFF(filp);

 	if (flags & MAP_FIXED) {
 		/* Even MAP_FIXED mappings must reside within TASK_SIZE */
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index f4591b912ea8..93db3e4e7b68 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -3470,6 +3470,8 @@ static unsigned long io_uring_mmu_get_unmapped_area(struct file *filp,
 	 * - use the kernel virtual address of the shared io_uring context
 	 *   (instead of the userspace-provided address, which has to be 0UL
 	 *   anyway).
+	 * - use the same pgoff which the get_unmapped_area() uses to
+	 *   calculate the page colouring.
 	 * For architectures without such aliasing requirements, the
 	 * architecture will return any suitable mapping because addr is 0.
 	 */
@@ -3478,6 +3480,7 @@ static unsigned long io_uring_mmu_get_unmapped_area(struct file *filp,
 	pgoff = 0;	/* has been translated to ptr above */
 #ifdef SHM_COLOUR
 	addr = (uintptr_t) ptr;
+	pgoff = addr >> PAGE_SHIFT;
 #else
 	addr = 0UL;
 #endif

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Jens Axboe]

On 8/7/23 12:04?PM, Helge Deller wrote:
> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
> using architecture-provided get_unmapped_area()") to the parisc
> implementation of get_unmapped_area() broke glibc's locale-gen
> executable when running on parisc.
> 
> This patch reverts those architecture-specific changes, and instead
> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
> then given to parisc's get_unmapped_area() function.  This is much
> cleaner than the previous approach, and we still will get a coherent
> addresss.
> 
> This patch has no effect on other architectures (SHM_COLOUR is only
> defined on parisc), and the liburing testcase stil passes on parisc.

What branch is this against? It doesn't apply to my 6.5 io_uring branch,
which is odd as that's where the previous commits went through.

-- 
Jens Axboe

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Helge Deller]

On 8/7/23 20:24, Jens Axboe wrote:
> On 8/7/23 12:04?PM, Helge Deller wrote:
>> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
>> using architecture-provided get_unmapped_area()") to the parisc
>> implementation of get_unmapped_area() broke glibc's locale-gen
>> executable when running on parisc.
>>
>> This patch reverts those architecture-specific changes, and instead
>> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
>> then given to parisc's get_unmapped_area() function.  This is much
>> cleaner than the previous approach, and we still will get a coherent
>> addresss.
>>
>> This patch has no effect on other architectures (SHM_COLOUR is only
>> defined on parisc), and the liburing testcase stil passes on parisc.
>
> What branch is this against? It doesn't apply to my 6.5 io_uring branch,
> which is odd as that's where the previous commits went through.

applies for me on git head / Linux 6.5-rc5

Helge

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Jens Axboe]

On 8/7/23 12:27?PM, Helge Deller wrote:
> On 8/7/23 20:24, Jens Axboe wrote:
>> On 8/7/23 12:04?PM, Helge Deller wrote:
>>> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
>>> using architecture-provided get_unmapped_area()") to the parisc
>>> implementation of get_unmapped_area() broke glibc's locale-gen
>>> executable when running on parisc.
>>>
>>> This patch reverts those architecture-specific changes, and instead
>>> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
>>> then given to parisc's get_unmapped_area() function.  This is much
>>> cleaner than the previous approach, and we still will get a coherent
>>> addresss.
>>>
>>> This patch has no effect on other architectures (SHM_COLOUR is only
>>> defined on parisc), and the liburing testcase stil passes on parisc.
>>
>> What branch is this against? It doesn't apply to my 6.5 io_uring branch,
>> which is odd as that's where the previous commits went through.
> 
> applies for me on git head / Linux 6.5-rc5

Hmm, maybe something unrelated then. I'll take a look. The patch is
garbled fwiw, but that's nothing new. If you download the raw one from
lore you can see how.

-- 
Jens Axboe

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Jens Axboe]

On Mon, 07 Aug 2023 20:04:09 +0200, Helge Deller wrote:
> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
> using architecture-provided get_unmapped_area()") to the parisc
> implementation of get_unmapped_area() broke glibc's locale-gen
> executable when running on parisc.
> 
> This patch reverts those architecture-specific changes, and instead
> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
> then given to parisc's get_unmapped_area() function.  This is much
> cleaner than the previous approach, and we still will get a coherent
> addresss.
> 
> [...]

Applied, thanks!

[1/1] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc
      commit: ce11a0688e67aae1e9ba6c8843d7e8b7dd791ead

Best regards,
-- 
Jens Axboe

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Helge Deller]

On 8/7/23 20:33, Jens Axboe wrote:
> On 8/7/23 12:27?PM, Helge Deller wrote:
>> On 8/7/23 20:24, Jens Axboe wrote:
>>> On 8/7/23 12:04?PM, Helge Deller wrote:
>>>> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
>>>> using architecture-provided get_unmapped_area()") to the parisc
>>>> implementation of get_unmapped_area() broke glibc's locale-gen
>>>> executable when running on parisc.
>>>>
>>>> This patch reverts those architecture-specific changes, and instead
>>>> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
>>>> then given to parisc's get_unmapped_area() function.  This is much
>>>> cleaner than the previous approach, and we still will get a coherent
>>>> addresss.
>>>>
>>>> This patch has no effect on other architectures (SHM_COLOUR is only
>>>> defined on parisc), and the liburing testcase stil passes on parisc.
>>>
>>> What branch is this against? It doesn't apply to my 6.5 io_uring branch,
>>> which is odd as that's where the previous commits went through.
>>
>> applies for me on git head / Linux 6.5-rc5
>
> Hmm, maybe something unrelated then. I'll take a look. The patch is
> garbled fwiw, but that's nothing new. If you download the raw one from
> lore you can see how.

That's strange. I usually send to the mailing list, and then apply
from patchwork, in this case from here:
https://patchwork.kernel.org/project/linux-parisc/patch/ZNEyGV0jyI8kOOfz@p100/
That worked for me.

Helge

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Helge Deller]

On 8/7/23 20:34, Jens Axboe wrote:
>
> On Mon, 07 Aug 2023 20:04:09 +0200, Helge Deller wrote:
>> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
>> using architecture-provided get_unmapped_area()") to the parisc
>> implementation of get_unmapped_area() broke glibc's locale-gen
>> executable when running on parisc.
>>
>> This patch reverts those architecture-specific changes, and instead
>> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
>> then given to parisc's get_unmapped_area() function.  This is much
>> cleaner than the previous approach, and we still will get a coherent
>> addresss.
>>
>> [...]
>
> Applied, thanks!

That was fast :-)
Actually I had hoped for some more testing from Christoph and other
parisc guys first.
Anyway, since you have a parisc machine in your test ring, you will
notice if something breaks,

What's important:
Please add to the patch:
Cc: stable@vger.kernel.org # 6.4

Thank you!
Helge

> [1/1] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc
>        commit: ce11a0688e67aae1e9ba6c8843d7e8b7dd791ead

Re: [PATCH] io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc

[Jens Axboe]

On Aug 7, 2023, at 12:33 PM, Helge Deller <deller@gmx.de> wrote:
> 
> On 8/7/23 20:34, Jens Axboe wrote:
>> 
>>> On Mon, 07 Aug 2023 20:04:09 +0200, Helge Deller wrote:
>>> The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by
>>> using architecture-provided get_unmapped_area()") to the parisc
>>> implementation of get_unmapped_area() broke glibc's locale-gen
>>> executable when running on parisc.
>>> 
>>> This patch reverts those architecture-specific changes, and instead
>>> adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is
>>> then given to parisc's get_unmapped_area() function.  This is much
>>> cleaner than the previous approach, and we still will get a coherent
>>> addresss.
>>> 
>>> [...]
>> 
>> Applied, thanks!
> 
> That was fast :-)
> Actually I had hoped for some more testing from Christoph and other
> parisc guys first.
> Anyway, since you have a parisc machine in your test ring, you will
> notice if something breaks,
> 
> What's important:
> Please add to the patch:
> Cc: stable@vger.kernel.org # 6.4

It’s not going upstream just yet, just easiser to apply for testing on my end. I will test it locally too.

— 
Jens Axboe