| Message ID | 20250129115411.2077152-8-david@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: fixes for device-exclusive entries (hmm) | expand |
On Wed, Jan 29, 2025 at 12:54:05PM +0100, David Hildenbrand wrote: > It's unclear why they would be considered migration entries; they are > not. Yeah, I agree that doesn't seem right. I suspect I was initially modelling device exclusive entries similar to migration entries but obviously went too far. So thanks for fixing: Reviewed-by: Alistair Popple <apopple@nvidia.com> > Likely we'll never really trigger that case in practice, because > migration (including folio split) of a folio that has device-private > entries is never started, as we would detect "additional references": > device-private entries adjust the mapcount, but not the refcount. > > Fixes: b756a3b5e7ea ("mm: device exclusive memory access") > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > mm/page_vma_mapped.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c > index 81839a9e74f1..32679be22d30 100644 > --- a/mm/page_vma_mapped.c > +++ b/mm/page_vma_mapped.c > @@ -111,8 +111,7 @@ static bool check_pte(struct page_vma_mapped_walk *pvmw) > return false; > entry = pte_to_swp_entry(ptent); > > - if (!is_migration_entry(entry) && > - !is_device_exclusive_entry(entry)) > + if (!is_migration_entry(entry)) > return false; > > pfn = swp_offset_pfn(entry); > -- > 2.48.1 >
On 31.01.25 00:36, Alistair Popple wrote: > On Wed, Jan 29, 2025 at 12:54:05PM +0100, David Hildenbrand wrote: >> It's unclear why they would be considered migration entries; they are >> not. > > Yeah, I agree that doesn't seem right. I suspect I was initially modelling > device exclusive entries similar to migration entries but obviously went too > far. So thanks for fixing: > > Reviewed-by: Alistair Popple <apopple@nvidia.com> Thanks ... fixing all the wrong use of "device-private" in the subject+description ... not sure what my mind was doing there. It's all about "device-exclusive" of course.
diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c index 81839a9e74f1..32679be22d30 100644 --- a/mm/page_vma_mapped.c +++ b/mm/page_vma_mapped.c @@ -111,8 +111,7 @@ static bool check_pte(struct page_vma_mapped_walk *pvmw) return false; entry = pte_to_swp_entry(ptent); - if (!is_migration_entry(entry) && - !is_device_exclusive_entry(entry)) + if (!is_migration_entry(entry)) return false; pfn = swp_offset_pfn(entry);
It's unclear why they would be considered migration entries; they are not. Likely we'll never really trigger that case in practice, because migration (including folio split) of a folio that has device-private entries is never started, as we would detect "additional references": device-private entries adjust the mapcount, but not the refcount. Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Signed-off-by: David Hildenbrand <david@redhat.com> --- mm/page_vma_mapped.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)