pincount vs refcount: [PATCH] mm/hmm: Fix a hmm_range_fault() livelock / starvation problem

[John Hubbard <jhubbard@nvidia.com>]

On 2/3/26 1:31 AM, Thomas Hellström wrote:
...
> So this is what I had in mind:
> 
> I think certainly this would work regardless of whether pincount is
> implemented by means of refcount with a bias or not, and AFAICT it's
> also consistent with 
> 
> https://docs.kernel.org/core-api/pin_user_pages.html
> 
> But it would not work if some part of core mm grabs a page refcount and
> *expects* that to pin a page in the sense that it should not be
> migrated. But you're suggesting that's actually the case?

Yes. The migration code itself, in fact, uses folio_get() with the
expectation that this blocks migration:

migrate_vma_collect_pmd():

	/*
	 * By getting a reference on the folio we pin it and that blocks
	 * any kind of migration. Side effect is that it "freezes" the
	 * pte.
	 *
	 * We drop this reference after isolating the folio from the lru
	 * for non device folio (device folio are not on the lru and thus
	 * can't be dropped from it).
	 */
	folio = page_folio(page);
	folio_get(folio);


I'm experiencing a bit of local-mind-boggle at decoupling refcount
from pincount, but part of that is probably just bias towards "but
it's always been that way!". haha :)


thanks,
-- 
John Hubbard