(This time sent in reply to the correct series...) On Fri, Jan 31, 2025 at 06:28:58PM +0000, Lorenzo Stoakes wrote: > With the introduction of mapping_wrprotect_page() there is no need to use > folio_mkclean() in order to write-protect mappings of frame buffer pages, > and therefore no need to inappropriately set kernel-allocated page->index, > mapping fields to permit this operation. > > Instead, store the pointer to the page cache object for the mapped driver > in the fb_deferred_io object, and use the already stored page offset from > the pageref object to look up mappings in order to write-protect them. > > This is justified, as for the page objects to store a mapping pointer at > the point of assignment of pages, they must all reference the same > underlying address_space object. Since the life time of the pagerefs is > also the lifetime of the fb_deferred_io object, storing the pointer here > makes snese. > > This eliminates the need for all of the logic around setting and > maintaining page->index,mapping which we remove. > > This eliminates the use of folio_mkclean() entirely but otherwise should > have no functional change. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > Tested-by: Kajtar Zsolt <soci@xxxxxxxxxxxxx> Andrew - Sorry to be a pain but could you please apply the attached fix-patch to avoid build bot failures when randconfig generates invalid configurations. The defio mechanism entirely relies upon the page faulting mechanism, and thus an MMU to function. This was previously masked, because folio_mkclean() happens to have a !CONFIG_MMU stub. It really doesn't make sense to apply such a stub for mapping_wrprotect_page() for architectures without an MMU. Instead, correctly express the actual dependency in Kconfig, which should prevent randconfig from doing the wrong thing and also helps document this fact about defio. Thanks! ----8<----
