linux-kernel - Re: [PATCH v2 04/10] mm/vmalloc: Avoid cond_resched() when blocking is not permitted

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] [day] [month] [year] [list]

Message-ID: <aMpFeIANuJGRc0vO@pc636>
Date: Wed, 17 Sep 2025 07:22:00 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Uladzislau Rezki <urezki@...il.com>, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/10] mm/vmalloc: Avoid cond_resched() when blocking
 is not permitted

On Tue, Sep 16, 2025 at 08:08:18PM +0200, Michal Hocko wrote:
> On Tue 16-09-25 17:28:36, Uladzislau Rezki wrote:
> > On Mon, Sep 15, 2025 at 07:11:27PM +0200, Michal Hocko wrote:
> > > On Mon 15-09-25 15:40:34, Uladzislau Rezki wrote:
> > > > vm_area_alloc_pages() contains the only voluntary reschedule points
> > > > along vmalloc() allocation path. They are needed to ensure forward
> > > > progress on PREEMPT_NONE kernels under contention for vmap metadata
> > > > (e.g. alloc_vmap_area()).
> > > > 
> > > > However, yielding should only be done if the given GFP flags allow
> > > > blocking. This patch avoids calling cond_resched() when allocation
> > > > context is non-blocking(GFP_ATOMIC, GFP_NOWAIT).
> > > 
> > > We do have cond_resched in the page allocator path, right?
> > > So unless I am missing something we can safely drope these. I thought we
> > > have discused this already.
> > > 
> > Yes, we discussed this. I did some test with dropped cond_resched() for
> > !PREEMPT kernel and i can trigger soft-lockups under really heavy stress
> > load.
> > 
> > I prefer to keep them so far for consistency. I need some time to
> > investigate it more. As i noted in commit message, the vmalloc()
> > path only has those two resched points. Probably i need to move
> > them into another place later.
> > 
> > As for page-allocator, it is in a slow path which i do not hit in
> > my stress-setup.
> 
> OK, so the fast path can trigger the soft lockup? If yes please mention
> that in the changelog so that we know why this is needed. With that
> included feel free to add
> Acked-by: Michal Hocko <mhocko@...e.com>
> 
We, in vmalloc(), also have a slow path. Those two points seem to help.
I will move them later to alloc_vmal_area(), after a slow path serves
a request.

Thank you!

--
Uladzislau Rezki