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

Message-ID: <20241205090508.2095225-1-david@redhat.com>
Date: Thu,  5 Dec 2024 10:05:06 +0100
From: David Hildenbrand <david@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org,
	David Hildenbrand <david@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Oscar Salvador <osalvador@...e.de>,
	Zi Yan <ziy@...dia.com>
Subject: [PATCH RESEND v1 0/2] mm: don't use __GFP_HARDWALL when migrating remote pages

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.

Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Vlastimil Babka <vbabka@...e.cz>
Cc: Oscar Salvador <osalvador@...e.de>
Cc: Zi Yan <ziy@...dia.com>

David Hildenbrand (2):
  mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via
    alloc_contig*()
  mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via
    memory offlining

 mm/memory_hotplug.c | 2 +-
 mm/page_alloc.c     | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.47.1