On 08.01.25 22:55, Matthew Wilcox wrote:
On Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote:
On 08.01.25 21:54, Matthew Wilcox wrote:
Not necessarily! We already do that (since 2022) for DAX (see
6a8e0596f004). rmap lets you find every place that a given range
of a file is mapped into user address spaces; but that file might be a
device file, and so it's not just pagecache but also (in this case)
fb memory, and whatever else device drivers decide to mmap.
Yes, that part I remember.
I thought we would be passing in a page into rmap_wrprotect_file_page(), and
was wondering what we would do to "struct page" that won't be a folio in
there.
Probably, because the "_page" in rmap_wrprotect_file_page() is misleading :)
... should it be "file_range" ? (but we also pass the pfn ... )
I don't think it's unprecedented for us to identify a page by its pfn.
After all, the acronym stands for "page frame number". That said, for
the one caller of this, it has the struct page and passes in the result
from page_to_pfn(). So no harm in passing in the struct page directly.
I would not like to see this function called "rmap_wrprotect_file_pfn".
Files don't have pfns, so that's a bad name.
Agreed.
(it's too late in the evening for me to give any good suggestions :) )
--
Cheers,
David / dhildenb
