On Wed, Jan 08, 2025 at 11:02:57PM +0100, David Hildenbrand wrote: > 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 :) ) Matthew pinged me on irc with mapping_wrprotect_page() :>) Am happy to do that, will respin in a bit anyway... > > -- > Cheers, > > David / dhildenb >
