From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 AA6FE26738D for ; Tue, 18 Nov 2025 02:14:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763432068; cv=none; b=uq8FRVvm07xYFvA3/h6HpndWT0ouANIEhfLVm78oJFYXGupNXRG4Ef7UNMkgS7CeAtnq32AqggeAjtyOyhwdu47Q7V405FlCKxEnsNzRi1pfjgvr3cT07FzxY+gw1w+KiF2hKNTJLalX+7Tmw01bJx758fj5U/BwrzS6MnodzJQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763432068; c=relaxed/simple; bh=o48LDt0TSPg569fegonQldrDqlDIsfXnN64sffEnKdE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GwXBZjHjvtztS3pZzQP75PDzyAIHFBAsV1tWOLMT9OUMC8w1Fdc+J5+9EHeNJcihj+CIH+qEiZgI3KhYPvzfNmDcBuIM8fgYUx1pPsbnMxA1siIY6Hi1/Zb6koyG28yZ+UYX7WhIZOuhjXVXOFRlSvgn0Lp1Czk3Gcgn1JTg/v4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OyC3Z1Nt; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OyC3Z1Nt" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-298145fe27eso66243615ad.1 for ; Mon, 17 Nov 2025 18:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763432066; x=1764036866; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uG2h5hFbc8f+zsWVWelwgYAnnvEshc/EkCba1TrqhH8=; b=OyC3Z1NteNTl8ckXZ9HkjGdSas2bgonYrZYIlubcsUI1/F+4lohh8Tz80CgLhB4niJ DdXhdWXyHdi1GlfoDTCgK2qX+F2DhQ4aZ0I/QSIBCmyiTFnxiIT2bKv64Zm3vkv+8qMg PwuwVQmZGZGCGdNuY56Tdqw1N4tVqTHuHnXrpmfy57Lvlp74PmZ0VjuqwHvHgbxUMFN8 y2/dEhWZ4VzxifxEBfAJ+5aLllMs+biePJos+mjruwTEI7yToUKc7YM8lfDpyAuj5VgX QLhd5NDKn0Snmc36ywbQxWttEBQyEzGQd6M6BvLJGtIK8Ox1g0eE5Aa2NSG1XPaMr0pX fPBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763432066; x=1764036866; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uG2h5hFbc8f+zsWVWelwgYAnnvEshc/EkCba1TrqhH8=; b=J6pruUCDJ8pPqfTuQ2fuvpQ8O15UMbAnoLvv3YrvDh1Gz22qJFx1sQSGUx0Tzu+ia9 i7UsRxBUGN5Q/hpAHcWsxd8moMJ51hRShG3JnDsW+nV8jSxsScCWTC/pssnNRdh8Uyzt RA1g6RhN4D6aiYC7wdKXfAb1p7PB7rsMfm+1T2yadXZ20SvsagjYqfN9bXxoNCUkxfAq 7SFDrlI8AfH2st174v7vtQo37fp9l4PO1UmSJj9bfVWEBI28jIOqXsfgzGAt0Q56QP4n aCuDYpJSo47V0VEod2/zbfuYIoYQSYVqs2psj4AaARoGq33YOKLHYQU5E/PDEtJ4fFCQ VafQ== X-Forwarded-Encrypted: i=1; AJvYcCXH/nPn6cE2EdHGKNjZb+xCFeJaVtxrEwzlUM3ZvErUHBDVgktrH+eZ9/kL3oqORUMXRhdB6S5ejsMNqrs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxj66MAHUofu3Mjq+PBMhhnAbTmRrIEETojDeiTMg1rOXqLNa+L zL/CNwqgSCsT8I5sUXSLaYBcuHeV83EUXuaxKb0Qy2av++uu1pv+XZbI X-Gm-Gg: ASbGncvkur0+9uhGQPFf4Ets2mts7W/zrJiQNHyL6KYwidGINv3VkIXMsaOh8bwwSRl 2gAMvrRqXYNdOO6f8FbU9VGvEEpxoquxfCfLH3CnYrZEB/T4KW1XNuDJ9KByAxn1wLNU9o7lrtR tLE+RryZaIMYvpm2qcQyHE6KkRqI0ta7SFrm2lne9+nNrUKn79pROdrduODdcAJFA39gPhWqCwm GSXKG7E2Cc21NtoX5FmS4e7qKiH36tQFNbftYE0CT96oYwyshw5sU5R3SF8zkr0ipcxMU9vIq7E lxic2gdu31MHo+iMo8m2mWRADIbvSwKls0o2jjyoL9qDPZh7juChEhPy6d5UlpomL+Pe7l/EU82 nk7mxyZ3v/FwKwUlLANwlbUNwx19zqCp2pEFvdNRPz+spkoD01zIcK44qVanL3gNBjLWgc+4eGN rqWNSTTF0+pbWZKUtrPFPaVIKRrODxyiNVPHJx2gRWUHo= X-Google-Smtp-Source: AGHT+IFPov549n2LzL2CKQOMPes01IHaPnK+Nr8T6G4o/JsbD9vqU64qA4wEzMsT+osaI0OWReXc8g== X-Received: by 2002:a05:7022:b902:b0:119:e56b:c74f with SMTP id a92af1059eb24-11b411eda26mr4902917c88.20.1763432065736; Mon, 17 Nov 2025 18:14:25 -0800 (PST) Received: from fedora (c-67-164-59-41.hsd1.ca.comcast.net. [67.164.59.41]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-11b0608861asm36771548c88.9.2025.11.17.18.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Nov 2025 18:14:25 -0800 (PST) Date: Mon, 17 Nov 2025 18:14:22 -0800 From: "Vishal Moola (Oracle)" To: Lu Baolu Cc: Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jason Gunthorpe , Jann Horn , Vasant Hegde , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Alistair Popple , Peter Zijlstra , Uladzislau Rezki , Jean-Philippe Brucker , Andy Lutomirski , Yi Lai , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Andrew Morton , Vlastimil Babka , Mike Rapoport , Michal Hocko , Matthew Wilcox , Vinicius Costa Gomes , iommu@lists.linux.dev, security@kernel.org, x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 6/8] x86/mm: Use pagetable_free() Message-ID: References: <20251022082635.2462433-1-baolu.lu@linux.intel.com> <20251022082635.2462433-7-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251022082635.2462433-7-baolu.lu@linux.intel.com> On Wed, Oct 22, 2025 at 04:26:32PM +0800, Lu Baolu wrote: > The kernel's memory management subsystem provides a dedicated interface, > pagetable_free(), for freeing page table pages. Updates two call sites to > use pagetable_free() instead of the lower-level __free_page() or > free_pages(). This improves code consistency and clarity, and ensures the > correct freeing mechanism is used. In doing these ptdesc calls here, we're running into issues with the concurrent work around ptdescs: Allocating frozen page tables[1] and separately allocating ptdesc[2]. What we're seeing is attempts to cast a page that has still been allocated by the regular page allocator to a ptdesc - which won't work anymore. My hunch is we want alot of the code in pat/set_memory.c to be using ptdescs aka page table descriptors. At least all the allocations/frees for now. Does that seem right? I'm not really familiar with this code though... [1] https://lore.kernel.org/linux-mm/202511172257.ffd96dab-lkp@intel.com/T/#mf68f9c13f4b188eac08ae261c0172afe81a75827 [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/T/#md72f66473e017d6f3ce277405ad115e71898f418 > Signed-off-by: Lu Baolu > Reviewed-by: Jason Gunthorpe > Acked-by: David Hildenbrand > Acked-by: Mike Rapoport (Microsoft) > --- > arch/x86/mm/init_64.c | 2 +- > arch/x86/mm/pat/set_memory.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > index 0e4270e20fad..3d9a5e4ccaa4 100644 > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -1031,7 +1031,7 @@ static void __meminit free_pagetable(struct page *page, int order) > free_reserved_pages(page, nr_pages); > #endif > } else { > - __free_pages(page, order); > + pagetable_free(page_ptdesc(page)); > } > } > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > index 970981893c9b..fffb6ef1997d 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -429,7 +429,7 @@ static void cpa_collapse_large_pages(struct cpa_data *cpa) > > list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) { > list_del(&ptdesc->pt_list); > - __free_page(ptdesc_page(ptdesc)); > + pagetable_free(ptdesc); > } > } > > -- > 2.43.0 >