From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (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 264283115A1 for ; Mon, 27 Oct 2025 16:09:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761581367; cv=none; b=KdW4krnZVdK5iqrcjEZr1xmmszRB4sj6qvURIsF8xCyQoJC+GM1JJanuR4bTcAZpMkAOGi29onXpv5Y2kwBJ28Phu48z7Y5hFosbrB8Beu37JRSW5dD0kqw0KASHlgC44As8cLoMkf0BpQaE7aIzUiuDr/UsE9ExLq4Bs6HVCj0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761581367; c=relaxed/simple; bh=Ip6risDW9tTbsO2jqPpdXFWuol17OZMU9AeN0DDZC0s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=laLS/4oOFJXc3KcHdAVlPLZpY8QHMiQvrKbE4RCCAcavSh5RANF0TzKSM555+2cPgpaJ3QX68E8BHjcZnm/qR09jTPJI10RUqlJWjyQgy+/MWIMFH/yKczWPKDGbrn+AfkGJmIvXyBe81HE4gxzq2pYioLfjiMLhI/Kc1ZDyNns= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=kC9k2C1i; arc=none smtp.client-ip=209.85.222.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="kC9k2C1i" Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-893c373500cso493734385a.0 for ; Mon, 27 Oct 2025 09:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1761581365; x=1762186165; 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=anSGbOUh9PRDsyCb0fgwZTMvbpzdcHnK6psdZLJfHyQ=; b=kC9k2C1ipB0+8n0nDWV75bFcRvL16rGr//zO4g2ezNYzc8ibboc9Zs5rmRW7okfp9v KopeJr+kws+jhfq0fZmMCiBiRti6OMf9RdiPLOcmUZAqpS63TxOtRtGWXWE8Q5lqfpE0 NrM673GKnBk5KHQAuN4kS1BmUvuiUs47eQ2Zvtzi1vK3bAzGm8xeKcwwhe0L/5uQmQER QA/S9+XxULInuMBS0xIGXOZDPwhZDsE59jnGgg7KSs5iete7eY5t0xIHXWJWXUi9kWg0 aJyKPS7GRYfHJS9hlMnkVvENbtR/hTzMszY4O/KuBknMNAg0XqetkaokiwRVA98WqbgI dK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761581365; x=1762186165; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=anSGbOUh9PRDsyCb0fgwZTMvbpzdcHnK6psdZLJfHyQ=; b=nYMdo6VN6q9xneGMvslxsWhY0ajMSpDSFwmv3CHaRHlNeFWbCvE3sSQqV6Txf4SCz2 YNPG9L845rJXCjSpISli5ANO24npJnqjHK4FMnhaNwNW/jME2Zuhz5QgZm7xN6o8Pj0E snO5d7pwf5MrCL9a2+NutDush33QPr65Gz/3g1vV0RaXWtwI2WZT/3y+jaxMyZSEnVD4 K/p18/5C+X6Zgnan33Ppgr32a/LVpzjOhSZpQHKl66F2JW3xZLYBMg39rkrLQAAWIeSh fZV+p5JlU9ThroSqmbH+R0H6s0gD5jirl5d7Ngu675PldV2FaaVs4GsBuJmeim5RDnj8 LOiQ== X-Forwarded-Encrypted: i=1; AJvYcCUwfb68kBAl2gW6JvVEBWrwt6pRbNQBQNvJZwXIYQ4DvnAfAhETg9I3FVzbkIr6bAaEddo=@vger.kernel.org X-Gm-Message-State: AOJu0YwRFyxZtxEdYCsd7yQ1Vx+T+/2+1UW/pWOdzSChYYD/YuVow1Fa nfkpu+JdF4/bYLZjBxf6PugdQY1u4s8jJYSjjj96hMRY7z5BK1JEktcftEI7iJcmyY4= X-Gm-Gg: ASbGncvcMdh51hdacqV8gV/qfJB2+vlV2LI4B7fq7CMBsYi98JWptp7jfJHtGsU5vN9 8hyjm/Io7e2xYk/lHII2lqokPPx+aJEngsLn+sRsfu4gfafQTp12CDCKS0ErcZVg5oJcO4jlc38 0pUbagUOTT7TAypTRIfPefWEqdhdRd3VUB+BnwhVinSUsjZdf4nfuTjs1TfBUso+EcKdFp+VhrD x74Ir83XqFzNBKHhWLsHvX+qAoPF84gux7o8BzYqJbtC1KK5WioygSqph7MSlyzIx5TsR2OwXHS vkEMX9CaeeZqSULurvOrNJcFdWQrvL0NQFlGsHPKLKYdXWqyGltz83P7vtYcOfTAOKI16TNaQPl TWW1JZyN0yxakCG5cjRGtYefxajLr+X0661WtJ8mWqR+BXubzLytYDvHzgsDgzhomwXp6iKDDFi zXQc4PqlkGee1SjAaDlObMw+1P97RtWkLU3a3oOg8fKYrx8MluW+uszozq X-Google-Smtp-Source: AGHT+IHlNcX7M4ho1Hgm07pKSXRDLSWwAqfcPM4p2At44BY4PwXR6XnbKFaciXa2MkD0JUoTO3ORTg== X-Received: by 2002:a05:620a:1aa1:b0:8a3:9a05:ec15 with SMTP id af79cd13be357-8a6d072570emr95429085a.19.1761581364508; Mon, 27 Oct 2025 09:09:24 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-47-55-120-4.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.120.4]) by smtp.gmail.com with ESMTPSA id af79cd13be357-89f25c8a34dsm624408985a.48.2025.10.27.09.09.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Oct 2025 09:09:23 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vDPmd-00000004HT9-1p2Z; Mon, 27 Oct 2025 13:09:23 -0300 Date: Mon, 27 Oct 2025 13:09:23 -0300 From: Jason Gunthorpe To: Lorenzo Stoakes Cc: Andrew Morton , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , David Hildenbrand , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Sven Schnelle , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Kemeng Shi , Kairui Song , Nhat Pham , Baoquan He , Chris Li , Peter Xu , Matthew Wilcox , Leon Romanovsky , Muchun Song , Oscar Salvador , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Pedro Falcato , Pasha Tatashin , Rik van Riel , Harry Yoo , kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 00/12] remove is_swap_[pte, pmd]() + non-swap confusion Message-ID: <20251027160923.GF760669@ziepe.ca> References: Precedence: bulk X-Mailing-List: kvm@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: On Fri, Oct 24, 2025 at 08:41:16AM +0100, Lorenzo Stoakes wrote: > There's an established convention in the kernel that we treat leaf page > tables (so far at the PTE, PMD level) as containing 'swap entries' should > they be neither empty (i.e. p**_none() evaluating true) nor present > (i.e. p**_present() evaluating true). I have to say I've never liked the none-vs-present naming either. > This is deeply confusing, so this series goes further and eliminates the > non_swap_entry() predicate, replacing it with is_non_present_entry() - with > an eye to a new convention of referring to these non-swap 'swap entries' as > non-present. I'm not keen on is_non_present_entry(), it seems confusing again. It looks like we are stuck with swp_entry_t as the being the handle for a non-present pte. Oh well, not a great name, but fine.. So we think of that swp_entry_t having multiple types: swap, migration, device private, etc, etc Then I'd think the general pattern should be to get a swp_entry_t: if (pte_present(pte)) return; swpent = pte_to_swp_entry(pte); And then evaluate the type: if (swpent_is_swap()) { } If you keep the naming as "swp_entry" indicates the multi-type value, then "swap" can mean a swp_entry which is used by the swap subsystem. That suggests functions like this: swpent_is_swap() swpent_is_migration() .. and your higher level helpers like: /* True if the pte is a swpent_is_swap() */ static inline bool swpent_get_swap_pte(pte_t pte, swp_entry_t *entryp) { if (pte_present(pte)) return false; *swpent = pte_to_swp_entry(pte); return swpent_is_swap(*swpent); } I also think it will be more readable to keep all these things under a swpent namespace instead of using unstructured english names. > * pte_to_swp_entry_or_zero() - allows for convenient conversion from a PTE > to a swap entry if present, or an empty swap entry if none. This is > useful as many swap entry conversions are simply checking for flags for > which this suffices. I'd expect a safe function should be more like *swpent = pte_to_swp_entry_safe(pte); return swpent_is_swap(*swpent); Where "safe" means that if the PTE is None or Present then swpent_is_XX() == false. Ie it returns a 0 swpent and 0 swpent is always nothing. > * get_pte_swap_entry() - Retrieves a PTE swap entry if it truly is a swap > entry (i.e. not a non-present entry), returning true if so, otherwise > returns false. This simplifies a lot of logic that previously open-coded > this. Like this is still a tortured function: +static inline bool get_pte_swap_entry(pte_t pte, swp_entry_t *entryp) +{ + if (pte_present(pte)) + return false; + if (pte_none(pte)) + return false; + + *entryp = pte_to_swp_entry(pte); + if (non_swap_entry(*entryp)) + return false; + + return true; +} + static inline bool get_pte_swap_entry(pte_t pte, swp_entry_t *entryp) { return swpent_is_swap(*swpent = pte_to_swp_entry_safe(pte)); } Maybe it doesn't even need an inline at that point? > * is_huge_pmd() - Determines if a PMD contains either a present transparent > huge page entry or a huge non-present entry. This again simplifies a lot > of logic that simply open-coded this. is_huge_or_swpent_pmd() would be nicer, IMHO. I think it is surprising when any of these APIs accept swap entries without being explicit Jason