On 10/22/26 14:11, Lorenzo Stoakes (ARM) wrote:
> On Thu, Oct 22, 2026 at 12:44:40PM +0200, Konstantin Khorenko wrote:
>> On 10/22/26 10:07, Lorenzo Stoakes (ARM) wrote:
>>
>>> Was this a mistake in d8ef5e311d7b, or actually intentional for whatever
>>> reason?
>>> If the latter this shouldn't be a fixes.
>>
>> commit d8ef5e311d7bfde54b60ab45026f206eff31b2d2
>>
>> mm/rmap: convert page_dup_file_rmap() to
>> folio_dup_file_rmap_[pte|ptes|pmd]()
>>
>> ...
>> +static inline void folio_dup_file_rmap_ptes(struct folio *folio,
>> + struct page *page, int nr_pages)
>> +{
>> + __folio_dup_file_rmap(folio, page, nr_pages, RMAP_LEVEL_PTE);
>> +}
>>
>> ...
>> +static inline void folio_dup_file_rmap_pmd(struct folio *folio,
>> + struct page *page)
>> +{
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> + __folio_dup_file_rmap(folio, page, HPAGE_PMD_NR, RMAP_LEVEL_PTE);
>> +#else
>> + WARN_ON_ONCE(true);
>> +#endif
>> +}
>
> OK so it was just wrong at the time :)
>
>>
>> Both functions were introduced in a single commit, i think it's a simple
>> copy-paste issue.
>>
>> The helper never had a caller, so nobody could hit it. If you prefer, I
>> can drop the Fixes tag and only mention d8ef5e311d7b in the changelog, as
>> there is nothing to backport.
>
> I mean, it seems like a bug to me? If there's no harm in backporting it I
> think you
> should add Cc: [email protected] in that case actually.
It was never used, so it's by definition not even a bug. :)
Cc: stable makes sense if we want to backport it along the other things.
--
Cheers,
David
