Re: [RESEND v7 08/29] mm: recognize PMD swap entries in the softleaf layer

[Usama Arif]

On 18/09/2026 22:56, David Hildenbrand (Arm) wrote:
> On 9/14/26 14:27, Usama Arif wrote:
>> Reclaim splits a PMD-mapped anonymous THP into PTE-level swap entries
>> before unmapping it, so an ordinary swap entry has never had to appear in a
>> PMD. Later patches install one there instead, and the softleaf layer is
> 
> "Prepare for ..."
> 
>> where every consumer decodes non-present PMDs.
>>
>> Accept swap entries as valid PMD softleaves and add pmd_is_swap_entry().
>> A swap entry carries no PFN, so make pmd_softleaf_to_folio() warn and
>> return NULL rather than interpret a swap offset as a page frame number.
>>
>> Unlike migration and device-private entries, a PMD swap entry can also
>> carry the swap-exclusive marker, which softleaf_from_pmd() has to strip
>> before decoding. Strip all three overlays unconditionally while we are
>> here: each clear is a plain bit clear, so testing first only buys a branch.
>>
>> Signed-off-by: Usama Arif <usama.arif@xxxxxxxxx>
>> ---
> 
> 
> [...]
> 
>> +/**
>> + * pmd_is_swap_entry() - Does this PMD entry encode an actual swap entry?
>> + * @pmd: PMD entry.
>> + *
>> + * Returns: true if the PMD encodes a swap entry, otherwise false.
>> + */
>> +static inline bool pmd_is_swap_entry(pmd_t pmd)
>> +{
>> +	return softleaf_is_swap(softleaf_from_pmd(pmd));
>>  }
> 
> We don't have a pte_is_swap_entry(), I guess because we always want to handle
> different softleaf types through softleaf_from_pte() first.
> 
>>  
>>  /**
>>   * pmd_is_valid_softleaf() - Is this PMD entry a valid softleaf entry?
>>   * @pmd: PMD entry.
>>   *
>> - * PMD leaf entries are valid only if they are device private or migration
>> - * entries. This function asserts that a PMD leaf entry is valid in this
>> - * respect.
>> + * PMD leaf entries are valid only if they are device private, migration,
>> + * or swap entries. This function asserts that a PMD leaf entry is valid
>> + * in this respect.
>>   *
>>   * Returns: true if the PMD entry is a valid leaf entry, otherwise false.
>>   */
>> @@ -660,10 +670,12 @@ static inline bool pmd_is_valid_softleaf(pmd_t pmd)
>>   * pmd_softleaf_to_folio() - Convert the PMD softleaf entry to a folio.
>>   * @pmd: PMD entry.
>>   *
>> - * The PMD entry is expected to be a valid PMD softleaf entry.
>> + * The PMD entry is expected to be a valid PMD softleaf entry that references a
>> + * PFN, that is a migration or device private entry. A PMD swap entry is a valid
>> + * softleaf entry but encodes swap slots rather than a PFN, so it has no folio.
>>   *
>> - * Returns: the folio the softleaf entry references if this is a valid softleaf
>> - * entry, otherwise NULL.
>> + * Returns: the folio the softleaf entry references, or NULL if the entry is not
>> + * a valid PMD softleaf entry or does not reference a PFN.
>>   */
>>  static inline struct folio *pmd_softleaf_to_folio(pmd_t pmd)
>>  {
>> @@ -673,6 +685,10 @@ static inline struct folio *pmd_softleaf_to_folio(pmd_t pmd)
>>  		VM_WARN_ON_ONCE(true);
>>  		return NULL;
>>  	}
>> +	if (!softleaf_has_pfn(entry)) {
>> +		VM_WARN_ON_ONCE(true);
>> +		return NULL;
> softleaf_to_folio() does a
> 
> 	VM_WARN_ON_ONCE(!softleaf_has_pfn(entry));
> 
> Just curious: why is that not sufficient? Which could would we expect to call
> into this fuction with nonesense? (same applies to the existing runtime check)
> 

Because softleaf_to_folio() warns after the damage:

  static inline struct folio *softleaf_to_folio(softleaf_t entry)
  {
          struct folio *folio = pfn_folio(softleaf_to_pfn(entry));

          VM_WARN_ON_ONCE(!softleaf_has_pfn(entry));

pfn_folio() is page_folio(pfn_to_page(pfn)), and page_folio() is
_compound_head(), i.e. READ_ONCE(page->compound_info).  So a swap
offset interpreted as a PFN is already dereferenced by the time the
warning runs.

As for who would call it with nonsense: nobody today. zap_huge_pmd()
is the only path that reaches it with a non-present PMD and it takes
the pmd_is_swap_entry() branch first.


> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>