linux-kernel - Re: [PATCH] mm, percpu: do not consider sleepable allocations atomic

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: <Z60KQCuPCueqRwzc@tiehlicka>
Date: Wed, 12 Feb 2025 21:53:20 +0100
From: Michal Hocko <mhocko@...e.com>
To: Tejun Heo <tj@...nel.org>
Cc: Dennis Zhou <dennis@...nel.org>, Filipe Manana <fdmanana@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm, percpu: do not consider sleepable allocations atomic

On Wed 12-02-25 08:14:35, Tejun Heo wrote:
> Hello,
> 
> On Wed, Feb 12, 2025 at 05:57:04PM +0100, Michal Hocko wrote:
> ...
> > I have gone with masking because that seemed easier to review and more
> > robust solution. vmalloc does support NOFS/NOIO contexts these days (it
> > will just uses scoped masking in those cases). Propagating the gfp
> 
> I see. Nice.
> 
> > throughout the worker code path is likely possible, but I haven't really
> > explored that in detail to be sure. Would that be preferable even if the
> > fix would be more involved?
> 
> Longer term, yeah, I think so.

I can invest more time into that direction if this is really preferred
way. Not my call but I would argue that the scope interface is actually a
good fit in the current implementation because it clearly defines the
scope of all allocation context at a single place. Ideally with a good
explanation on why is that (I guess I owe in that regards).

> > > Also, doesn't the above always prevent percpu allocations from doing fs/io
> > > reclaims? 
> > 
> > Yes it does. Probably worth mentioning in the changelog. These
> > allocations should be rare so having a constrained reclaim didn't really
> > seem problematic to me. There should be kswapd running in the background
> > with the full reclaim power.
> 
> Hmm... you'd a better judge on whether that'd be okay or not but it does
> bother me that we might be increasing the chance of allocation failures for
> GFP_KERNEL users at least under memory pressure.

Nope, this will not change the allocation failure mode. Reclaim
constrains do not change the failure mode they just change how much the
allocation might struggle to reclaim to succeed. 

My undocumented assumption (another dept on my end) is that pcp
allocations are no hot paths. So the worst case is that GFP_KERNEL
pcp_allocation could have been satisfied _easier_ (i.e. faster) because
it could have reclaimed fs/io caches and now it needs to rely on kswapd
to do that on memory tight situations. On the other hand we have a
situation when NOIO/FS allocations fail prematurely so there is
certainly some pros and cons.

As I've said I am no pcp allocator expert so I cannot really make proper
judgment calls. I can improve the changelog or move from scope to
specific gfp flags but I do not feel like I am positioned to make deeper
changes to the subsystem.

-- 
Michal Hocko
SUSE Labs