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: <aG03zMoVJSVJz5KK@tiehlicka>
Date: Tue, 8 Jul 2025 17:22:52 +0200
From: Michal Hocko <mhocko@...e.com>
To: Uladzislau Rezki <urezki@...il.com>
Cc: 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 Tue 08-07-25 14:27:57, Uladzislau Rezki wrote:
> 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.

You are right, I have misread the patch. I thought this includes
vm_area_alloc_pages as well but you are right this is only for page
tables and that seems much more reasonable. Having that outlined in the
changelog would have helped ;)
-- 
Michal Hocko
SUSE Labs