linux-kernel - Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area

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: <aG0Ozc3Mro95djxn@pc636>
Date: Tue, 8 Jul 2025 14:27:57 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: "Uladzislau Rezki (Sony)" <urezki@...il.com>, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>
Subject: Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in
 __vmalloc_area_node()

On Mon, Jul 07, 2025 at 09:13:04AM +0200, Michal Hocko wrote:
> On Fri 04-07-25 17:25:36, Uladzislau Rezki wrote:
> > This patch makes __vmalloc_area_node() to correctly handle non-blocking
> > allocation requests, such as GFP_ATOMIC and GFP_NOWAIT. Main changes:
> > 
> > - nested_gfp flag follows the same non-blocking constraints
> >   as the primary gfp_mask, ensuring consistency and avoiding
> >   sleeping allocations in atomic contexts.
> > 
> > - if blocking is not allowed, __GFP_NOFAIL is forcibly cleared
> >   and warning is issued if it was set, since __GFP_NOFAIL is
> >   incompatible with non-blocking contexts;
> > 
> > - Add a __GFP_HIGHMEM to gfp_mask only for blocking requests
> >   if there are no DMA constraints.
> > 
> > - in non-blocking mode we use memalloc_noreclaim_save/restore()
> >   to prevent reclaim related operations that may sleep while
> >   setting up page tables or mapping pages.
> > 
> > This is particularly important for page table allocations that
> > internally use GFP_PGTABLE_KERNEL, which may sleep unless such
> > scope restrictions are applied. For example:
> > 
> > <snip>
> >     #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO)
> > 
> >     __pte_alloc_kernel()
> >         pte_alloc_one_kernel(&init_mm);
> >             pagetable_alloc_noprof(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM, 0);
> > <snip>
> 
> The changelog doesn't explain the actual implementation and that is
> really crucial here. You rely on memalloc_noreclaim_save (i.e.
> PF_MEMALLOC) to never trigger memory reclaim but you are not explaining
> how do you prevent from the biggest caveat of this interface. Let me
> quote the documentation
>  * Users of this scope have to be extremely careful to not deplete the reserves
>  * completely and implement a throttling mechanism which controls the
>  * consumption of the reserve based on the amount of freed memory. Usage of a
>  * pre-allocated pool (e.g. mempool) should be always considered before using
>  * this scope.
> 
I am aware about that comment. I had same concern about this, but it
looks like i/you may overshot here. Yes, we have access to memory
resrves but this only for page-table manipulations, i.e. to allocate
a page for 5-level page table structure. We have PGD, P4D, PUD, PMD
and PTE which is the lowest level and which needs pages the most.

As i see we do not free pages at least on PTE level, it means that
an address space is populated forward only and never shrink back.
Most of the time you do not need to allocate, this mostly occurs
initially after the boot.

>
> Unless I am missing something _any_ vmalloc(GFP_NOWAIT|GFP_ATOMIC) user
> would get practically unbound access to the whole available memory. This
> is not really acceptable.
> 
See above comment. If there is a big concern about this, i can add
memalloc_noblock_save() memalloc_noblock_restore() pair to eliminate
that concern. The context will be converted in a way that it drops
__GFP_DIRECT_RECLAIM flag.

Thank you for your comments and input i appreciate it.

--
Uladzislau Rezki