Andrew - Ugh sorry - please disregard the below, I sent it to the wrong thread. It's Saturday and I'm tired and brain not working :>) Let me resend this against the correct non-RFC thread! On Sat, Feb 01, 2025 at 05:01:15PM +0000, Lorenzo Stoakes wrote: > On Mon, Jan 13, 2025 at 11:15:48PM +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> > > 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<---- > From 32abcfbb8dea92d9a8a99e6a86f45a1823a75c59 Mon Sep 17 00:00:00 2001 > From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > Date: Sat, 1 Feb 2025 16:56:02 +0000 > Subject: [PATCH] fbdev: have CONFIG_FB_DEFERRED_IO depend on CONFIG_MMU > > Frame buffer deferred I/O is entirely reliant on the page faulting > mechanism (and thus, an MMU) to function. > > Express this dependency in the Kconfig, as otherwise randconfig could > generate invalid configurations resulting in build errors. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > Reported-by: kernel test robot <lkp@xxxxxxxxx> > Closes: https://lore.kernel.org/oe-kbuild-all/202502020030.MnEJ847Z-lkp@xxxxxxxxx/ > --- > drivers/video/fbdev/core/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig > index d554d8c543d4..154804914680 100644 > --- a/drivers/video/fbdev/core/Kconfig > +++ b/drivers/video/fbdev/core/Kconfig > @@ -135,6 +135,7 @@ config FB_SYSMEM_FOPS > config FB_DEFERRED_IO > bool > depends on FB_CORE > + depends on MMU > > config FB_DMAMEM_HELPERS > bool > -- > 2.48.1
