linux-kernel - Re: [QUESTION] Order-4 allocation failures on reads with 256bit csums

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQvz42UTgwx7zFrO@mozart.vkv.me>
Date: Wed, 5 Nov 2025 17:03:31 -0800
From: Calvin Owens <calvin@...nvd.org>
To: Qu Wenruo <wqu@...e.com>
Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>
Subject: Re: [QUESTION] Order-4 allocation failures on reads with 256bit csums

On Thursday 11/06 at 07:31 +1030, Qu Wenruo wrote:
> 在 2025/11/6 07:24, Qu Wenruo 写道:
> > 在 2025/11/6 04:30, Calvin Owens 写道:
> > > Hello all,
> > > 
> > > I'm seeing order-4 allocation failures reading from btrfs filesystems
> > > with blake2b/sha256 checksums, on a couple different machines.
> > > 
> > > I don't think I'm doing anything interesting: in both cases they were
> > > idle except for a single-threaded file reader doing buffered I/O. The
> > > first one was an x86 QEMU VM, the second was a raspberry pi 4b (below):
> 
> Another thing is, although the order 4 allocation is indeed large, it's not
> that unreasonable large.
> 
> The problem is still that we're requiring physically contiguous range which
> greatly reduce the chance to get one.
> 
> Another point contributing to this is the order 4, which is beyond the
> PAGE_ALLOC_COSTLY_ORDER (3), thus no more retry is done thus can fail here.
> 
> In fact for your aarch64 case, you can configure the kernel to use 64K page
> size and in that case such allocation will only be one page thus will almost
> never fail.
>
> This leads to my final question, what's the memory size of the RPI4 and your
> qemu VM?
> My guess is there is a very limited amount of memory (1GiB?), but still a
> lot of large buffered IOs.
> I guess enlarging the VM RAM size will hugely reduce the chance of memory
> allocation failure.

Thanks for looking Qu.

Both have 8GB of RAM, here's the rest of the allocfail trace from the pi
in case it's interesting:

    Mem-Info:
    active_anon:56 inactive_anon:3262 isolated_anon:0
     active_file:421253 inactive_file:1487506 isolated_file:0
     unevictable:0 dirty:51 writeback:0
     slab_reclaimable:28851 slab_unreclaimable:13163
     mapped:6531 shmem:13 pagetables:493
     sec_pagetables:0 bounce:0
     kernel_misc_reclaimable:0
     free:39062 free_pcp:34 free_cma:15
    Node 0 active_anon:224kB inactive_anon:13048kB active_file:1685012kB inactive_file:5950024kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:26124kB dirty:204kB writeback:0kB shmem:52kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB kernel_stack:3472kB pagetables:1972kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB
    DMA free:48336kB boost:12288kB min:19692kB low:21540kB high:23388kB reserved_highatomic:2048KB free_highatomic:2032KB active_anon:0kB inactive_anon:80kB active_file:274560kB inactive_file:545700kB unevictable:0kB writepending:0kB present:970752kB managed:880012kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:60kB
    lowmem_reserve[]: 0 3008 6962 6962
    DMA32 free:53372kB boost:10240kB min:36236kB low:42732kB high:49228kB reserved_highatomic:2048KB free_highatomic:2016KB active_anon:32kB inactive_anon:124kB active_file:971292kB inactive_file:1993632kB unevictable:0kB writepending:24kB present:3080192kB managed:3080192kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
    lowmem_reserve[]: 0 0 3954 3954
    Normal free:54540kB boost:16384kB min:50560kB low:59104kB high:67648kB reserved_highatomic:2048KB free_highatomic:2032KB active_anon:192kB inactive_anon:12844kB active_file:439160kB inactive_file:3410608kB unevictable:0kB writepending:180kB present:4194304kB managed:4049512kB mlocked:0kB bounce:0kB free_pcp:136kB local_pcp:0kB free_cma:0kB
    lowmem_reserve[]: 0 0 0 0
    DMA: 12*4kB (UM) 11*8kB (UM) 53*16kB (UMEH) 40*32kB (UMH) 18*64kB (UMH) 47*128kB (UMH) 34*256kB (UMH) 39*512kB (UMH) 10*1024kB (UMH) 0*2048kB 0*4096kB = 48344kB
    DMA32: 14*4kB (UME) 16*8kB (UME) 806*16kB (UMEH) 194*32kB (UMEH) 29*64kB (UEH) 50*128kB (UM) 34*256kB (UMEH) 22*512kB (UMH) 4*1024kB (UMH) 1*2048kB (M) 0*4096kB = 53656kB
    Normal: 3*4kB (U) 6*8kB (U) 10*16kB (UEH) 31*32kB (UMEH) 35*64kB (UMEH) 45*128kB (UMH) 13*256kB (MH) 74*512kB (MH) 4*1024kB (UH) 0*2048kB 0*4096kB = 54524kB
    Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
    Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB
    Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
    Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB
    1909321 total pagecache pages
    532 pages in swap cache
    Free swap  = 16764072kB
    Total swap = 16777212kB
    2061312 pages RAM
    0 pages HighMem/MovableOnly
    58883 pages reserved
    16384 pages cma reserved