From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (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 88AF72857CD for ; Wed, 28 Jan 2026 15:57:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769615832; cv=none; b=szXVw3XbOEvR87vEqDkFw8e8Dc8Gnkz22KFzDfafLLU0toNaQlAOPxaiEW086UMIPSnDXGe5Z7Gh7FKn1pAKEa+W4+d4GDDcRqqdLgaMHw/Cs6SnQAYADj8B8Y8iKfaur6QDaaAFBvbWh1STBBze5XCfd5wsY0ZM43zN6KZkOTE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769615832; c=relaxed/simple; bh=gWvnHe8S2FbD4EQdvmOYc+6ODJAJTWSh8tOXrNO6KrA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UB6xZ+MzCPAju6bmS9STB5quDIFIyLZOpdbC7ZdiiJMxBSFsTGhKxwjgHbffSq4AwLt8+EDWWuZAJRDVGvljFQFzSDnstSzzSuD5VHFsTwG+L9njloqf3L0jK+rEGIA5tfwWljyA5ucOUiwOMqS1p7SI7m4och/C2mG/5kq1+sk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=vHfeqgVW; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vHfeqgVW" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-4806cfffca6so13528285e9.2 for ; Wed, 28 Jan 2026 07:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769615828; x=1770220628; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=5benP5LzN9tas9DLVt4VuW8nT0VafAZ6ke1BLBEShTo=; b=vHfeqgVWlOE+2pvm3BC0HO0rJwwQp1UnzGmlpN1jA0G538JuFIJ8yVEGh37Y4nSW8D G5BykhbK/lE+FKxwFgMB2FqE5DqPspX1ihRKx826Rk9mB+m4JuxY+Z+n257AQltW9j3h wCXdb+xDQWAhwBa9tzfVTXJxyW/LDsdKWUAknjVVDEPCYvDFikN7+AbjfKiNvl0ozT3k xopsgIjVXnL5q0wknmkkZIN+zHyh9f9XMnW97K61iyCyajrYov4uRNB/EZ38hY39JDMI vRZzRsocCRKAy9IBDCjQ/MUFg4sD0PDu2e1baZBgMNz09b8w11z6COb4AokAiqZeuGxP j7jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769615828; x=1770220628; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=5benP5LzN9tas9DLVt4VuW8nT0VafAZ6ke1BLBEShTo=; b=BnOktyKtaps13wKkLX0NDjbRJBd+ib43kPwiv2wkRT0K4T4bAzXfl/iLx1/Efzfck9 Rj0C5EJaCZ/1HiSX6HCExbbAVsUw4jtXP5cAOk67yUuXGd3LIRjVnsbvgqQUttfNKze1 050fIXshd3O+x6098ymokTBLD4TU0BqIOSUDIDNkCPB5rjRzoqLRKEC3g3E1Dco/cXpM swk2g4qVc/EnR5xBRIFlqmTitOCllori9aVeCwnTgTKRvOB1IMDsMXKACuT/vGsobB4/ cBZC6fzwUxLRyBdknbGDRptrUt4JfE33gKIYJtYr5gg13XLCV/IHhDMaODLq5TSHfc0e Rmkw== X-Forwarded-Encrypted: i=1; AJvYcCWfPtcQKQkmKRp0CbhhPqzTfVf7ia2HfdAD8+QT29bt1ooHWv8rtp01VcsaHD+DXVmpfLY4bRw8LNsGHlo=@vger.kernel.org X-Gm-Message-State: AOJu0Yzb8ix7sTLSSrv4nIkf5TXRuJeKWCa2UlCTTc9qlDelipLwoxZN GTw/VbQH8rpP1wrPRbhmM7EMFWlGUsHwXntP6Wlis2HmBc5hroPzglABAgZTGLvxqJpwKuedQaL VyCs3vWFEysDCNA== X-Received: from wmhn12.prod.google.com ([2002:a05:600c:304c:b0:480:4a03:7b5a]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:b8a:b0:480:3b4e:41b8 with SMTP id 5b1f17b1804b1-48069c7586amr72869795e9.33.1769615828458; Wed, 28 Jan 2026 07:57:08 -0800 (PST) Date: Wed, 28 Jan 2026 15:57:07 +0000 In-Reply-To: <20260128153834.GNaXotelMi3QMuvh9-@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250924-b4-asi-page-alloc-v1-0-2d861768041f@google.com> <20250924-b4-asi-page-alloc-v1-6-2d861768041f@google.com> <20260128153834.GNaXotelMi3QMuvh9-@fat_crate.local> X-Mailer: aerc 0.21.0 Message-ID: Subject: Re: [PATCH 06/21] mm/page_alloc: add __GFP_SENSITIVE and always set it From: Brendan Jackman To: Borislav Petkov , Brendan Jackman Cc: Dave Hansen , Andy Lutomirski , Lorenzo Stoakes , "Liam R. Howlett" , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Axel Rasmussen , Yuanchu Xie , Roman Gushchin , , , , , , , , , , , , , , , , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed Jan 28, 2026 at 3:38 PM UTC, Borislav Petkov wrote: > On Thu, Oct 02, 2025 at 02:34:33PM +0000, Brendan Jackman wrote: >> On Wed Oct 1, 2025 at 9:18 PM UTC, Dave Hansen wrote: >> > On 9/24/25 07:59, Brendan Jackman wrote: >> >> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION >> >> +#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT) >> >> +#else >> >> +#define ___GFP_SENSITIVE 0 >> >> +#endif >> > >> > This is clearly one of the inflection points of the series. >> > >> > To go any farther with this approach, I think it's critical to get a f= ew >> > acks on this hunk specifically. Well, maybe not formal acked-by's, but >> > at least _clear_ agreement from at least one of: >> > >> > MEMORY MANAGEMENT - PAGE ALLOCATOR >> > M: Andrew Morton >> > M: Vlastimil Babka >> > >> > ... or this approach is dead in the water. >>=20 >> Yep, I agree. This is where the chicken-and-egg thing I mentioned in [0] >> comes into play though... >>=20 >> [0] https://lore.kernel.org/all/DD7SCRK2OJI9.1EJ9GSEH9FHW2@google.com/ > > Btw: > > ./include/linux/sockptr.h: In function =E2=80=98memdup_sockptr_noprof=E2= =80=99: > ./include/linux/gfp_types.h:306:41: error: =E2=80=98___GFP_SENSITIVE=E2= =80=99 undeclared (first use in this function); did you mean =E2=80=98___GF= P_SENSITIVE_BIT=E2=80=99? > 306 | #define __GFP_SENSITIVE ((__force gfp_t)___GFP_SENSITIVE) > | ^~~~~~~~~~~~~~~~ > ./include/linux/slab.h:1049:76: note: in definition of macro =E2=80=98kma= lloc_node_track_caller_noprof=E2=80=99 > 1049 | __kmalloc_node_track_caller_noprof(PASS_BUCKET_PARAMS(siz= e, NULL), flags, node, caller) > | = ^~~~~ > ./include/linux/sockptr.h:126:19: note: in expansion of macro =E2=80=98km= alloc_track_caller_noprof=E2=80=99 > 126 | void *p =3D kmalloc_track_caller_noprof(len, GFP_USER | _= _GFP_NOWARN); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > ./include/linux/gfp_types.h:390:43: note: in expansion of macro =E2=80=98= __GFP_SENSITIVE=E2=80=99 > 390 | __GFP_HARDWALL | __GFP_SENSITIVE) > | ^~~~~~~~~~~~~~~ > ./include/linux/sockptr.h:126:52: note: in expansion of macro =E2=80=98GF= P_USER=E2=80=99 > 126 | void *p =3D kmalloc_track_caller_noprof(len, GFP_USER | _= _GFP_NOWARN); > | ^~~~~~~~ > > Perhaps it is time for a refresh and a new submission huh? Yeah, that time has long since passed, I'm sorry about the delay! =20 I'm working on it as we speak. The submission I've been trying to post for the last few week is to add a __GFP_UNMAPPED flag. That will unblock the guest_memfd unmapped usecase. =20 I got some design elements wrong and had to reimplement some stuff during January (I had an AI review my code and it pointed out that part of my pagetable management code was garbage. Spooky). Now I'm working on integrating the new version with the guest_memfd features to make sure it's actually fast (it's quite complicated so it had better be useful). Once that's done I'll hopefully be ready to post.... _THEN_ I can update the __GFP_SENSITIVE functionality on top of the __GFP_UNMAPPED functionality. The former means "don't map into ASI" and the latter means "don't map at all" so they overlap in terms of allocator stuff.l