linux-kernel - Re: [PATCH RESEND v1 0/2] mm: don't use __GFP

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: <Z1FvfEwhvaZGJm7-@localhost.localdomain>
Date: Thu, 5 Dec 2024 10:16:44 +0100
From: Oscar Salvador <osalvador@...e.de>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>, Zi Yan <ziy@...dia.com>
Subject: Re: [PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when
 migrating remote pages

On Thu, Dec 05, 2024 at 10:05:06AM +0100, David Hildenbrand wrote:
> Resending via a known-working SMTP setup.
> 
> ---
> 
> __GFP_HARDWALL means that we will be respecting the cpuset of the caller
> when allocating a page. However, when we are migrating remote allocations
> (pages allocated from other context), the cpuset of the current context
> is irrelevant.
> 
> For memory offlining + alloc_contig_*(), this is rather obvious. There
> might be other such page migration users, let's start with the obvious
> ones.

After the insight we gained from yesterday's discussion, this makes a
lot of sense, and I suspect this was one of those "that code makes it
that way, let's copy it just in case".
I will go through the patches later today and give me ack.

As you mentioned, migration code could potentially derive the policy
of the old pages and try to respect that when __HARDWALL.

It might not be possible though, but I guess it is a worth a shot.
I will try to investigate and see whether that is feasible.

-- 
Oscar Salvador
SUSE Labs