From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-240.mta1.migadu.com [95.215.58.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2BCB4519AC for ; Tue, 18 Aug 2026 10:58:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.240 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787050690; cv=none; b=UBBXsrpsiXdQKGl8FPmxWb2nr8GlVvp4pI7NnIDDSTcwk4pzGpG8IHY62AJBSI3zq12p6qcqcAykTXzvj/V1oizR6GgnDGgrLXLPhgaydOfBk1nhgMwRp8OiUFTAGJNL9jyLEMsa8NgmGNjIiHVT+JGlhc1XDbg93WGsfB4/EyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787050690; c=relaxed/simple; bh=olJ6zlGKO4Jvnbtl+1LnszRH44Q4D0La/kTP3ky6LNk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=aupzBmw8Y32OYy0+XX18UHwXIq+pgNyMRE67eSMXlgcaeOCT8dJc8C4ykkI41YQSQv/VzqLn6b7QhEpLTWJa8ExbW08+5fOJ4xy8kv/f1czOsXHgs6Dc+shdktLIRbkDldupwkRIJfeRI9OMtiOdhZ/RrHuaKiSYwp7IjkfNxao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=W3gWg80l; arc=none smtp.client-ip=95.215.58.240 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="W3gWg80l" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=olJ6zlGKO4Jvnbtl+1LnszRH44Q4D0La/kTP3ky6LNk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787050685; v=1; x=1787655485; b=W3gWg80lZaGrkbqiNtMNLqd9YkEkAHo7K4H9VsO9mNjuxVpIyD4CqpAC0mr9N9XwuEIkVkT8 RK5KI5Ym6M4ADmCCGpkdspGbpg00mbdwE91VAbR1DHeU/hxmV5pa8Oy8aMRoeYxhxShFRbkiZDW AOSgHP1Auhvmwbhl6iI+QFX8= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2a02:168:f6cc:0:a69a:f3a4:8fdd:3332) by smtp.migadu.com with ESMTPS id d4297f5cac7e4cb7; Tue, 18 Aug 2026 10:58:04 +0000 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 18 Aug 2026 12:58:03 +0200 Message-Id: Cc: "Vlastimil Babka (SUSE)" , "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Mike Rapoport" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" Subject: Re: [PATCH v3 19/26] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER From: "Brendan Jackman" To: "Yosry Ahmed" , "Brendan Jackman" X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-19-6f5729aa9832@google.com> In-Reply-To: On Tue Aug 18, 2026 at 2:45 AM CEST, Yosry Ahmed wrote: > On Fri, Aug 14, 2026 at 01:09:32PM +0100, Brendan Jackman wrote: >> On Tue Aug 4, 2026 at 10:50 PM BST, Yosry Ahmed wrote: >> > On Fri, Jul 31, 2026 at 04:52:59PM +0200, Vlastimil Babka (SUSE) wrote= : >> >> On 7/27/26 00:22, Brendan Jackman wrote: >> >> > Commit 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HI= GH >> >> > non-blocking allocations accesses reserves") renamed ALLOC_HARDER t= o >> >> > ALLOC_NON_BLOCK because the former is "a vague description". >> >> >=20 >> >> > However, vagueness is accurate here, this is a vague flag. It is no= t set >> >> > for __GFP_NOMEMALLOC. It doesn't really mean "allocate without bloc= king" >> >> > but rather "allow dipping into atomic reserves, _because_ of the ne= ed >> >> > not to block". >> >> >=20 >> >> > A later commit will need an alloc flag that really means "don't blo= ck >> >> > here", so go back to the flag's old name and update the commentary >> >> > to try and give it a slightly clearer meaning. >> >> >=20 >> >> > Signed-off-by: Brendan Jackman >>=20 >> Writing this to get it clear in my head, so I'll also dump it in the >> mail in case it helps get us on the same page...=20 >>=20 >> What we actually want here is a flag that tells us when we can do a TLB >> shootdown. That means (on x86) that IRQs must be on and we mustn't be >> holding some random spinlock (most spinlocks would actually be fine but >> I think it's simpler to assume we can't hold any).=20 >>=20 >> It must never be over-permissive i.e. tell us we can do a TLB flush >> when we can't. It's fine to _sometimes_ be over-restrictive i.e. tell us >> we can't do a TLB flush when we can, but if it always forbids flushing >> while GFP_BOOT_MASK is in effect then we'll fail critical allocations >> and crash. > > Why is it a problem if it forbids flushing while GFP_BOOT_MASK is in > effect? We should change gfp_allowed_mask before any unmapped > allocations are possible, right? Hm, good point... I don't remember why this was a problem. It certainly seems like it shoudl be OK for secretmem and guest_memfd.