On Sun, Feb 02, 2025 at 12:16:55AM +0800, kernel test robot wrote: > Hi Lorenzo, > > FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable > head: 7de6fd8ab65003f050aa58e705592745717ed318 > commit: 6a9318f28d7e371692838677c364145fe04b1093 [75/80] fb_defio: do not use deprecated page->mapping, index fields > config: sh-randconfig-002-20250201 (https://download.01.org/0day-ci/archive/20250202/202502020030.MnEJ847Z-lkp@xxxxxxxxx/config) > compiler: sh4-linux-gcc (GCC) 14.2.0 > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250202/202502020030.MnEJ847Z-lkp@xxxxxxxxx/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > | Closes: https://lore.kernel.org/oe-kbuild-all/202502020030.MnEJ847Z-lkp@xxxxxxxxx/ > > All errors (new ones prefixed by >>): > > drivers/video/fbdev/core/fb_defio.c: In function 'fb_deferred_io_work': > >> drivers/video/fbdev/core/fb_defio.c:272:17: error: implicit declaration of function 'mapping_wrprotect_page' [-Wimplicit-function-declaration] > 272 | mapping_wrprotect_page(fbdefio->mapping, pgoff, 1, page); > | ^~~~~~~~~~~~~~~~~~~~~~ This seems entirely bogus to me, you're building defio on a non-MMU arch, whereas defio literally relies on an MMU to function at all. I mean what does it actually mean to wrprotect otherwise? :) I think this is because CONFIG_FB_DEFERRED_IO should be made to depend on CONFIG_MMU but isn't. > > > vim +/mapping_wrprotect_page +272 drivers/video/fbdev/core/fb_defio.c > > 258 > 259 /* workqueue callback */ > 260 static void fb_deferred_io_work(struct work_struct *work) > 261 { > 262 struct fb_info *info = container_of(work, struct fb_info, deferred_work.work); > 263 struct fb_deferred_io_pageref *pageref, *next; > 264 struct fb_deferred_io *fbdefio = info->fbdefio; > 265 > 266 /* here we wrprotect the page's mappings, then do all deferred IO. */ > 267 mutex_lock(&fbdefio->lock); > 268 list_for_each_entry(pageref, &fbdefio->pagereflist, list) { > 269 struct page *page = pageref->page; > 270 pgoff_t pgoff = pageref->offset >> PAGE_SHIFT; > 271 > > 272 mapping_wrprotect_page(fbdefio->mapping, pgoff, 1, page); > 273 } > 274 > 275 /* driver's callback with pagereflist */ > 276 fbdefio->deferred_io(info, &fbdefio->pagereflist); > 277 > 278 /* clear the list */ > 279 list_for_each_entry_safe(pageref, next, &fbdefio->pagereflist, list) > 280 fb_deferred_io_pageref_put(pageref, info); > 281 > 282 mutex_unlock(&fbdefio->lock); > 283 } > 284 > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki I mean I'm not sure it's worth doing anything about this since this is just an invalid config combo, which was masked before because for instance folio_mkclean() has a !CONFIG_MMU stub, however it really does not make sense for there to be such a stub for a function which explicitly refers to wrprotect afaic. But if we want to stop randconfig build bots tripping this, probably best to solve by making CONFIG_FB_DEFERRED_IO depend on CONFIG_MMU, so I will send a fix-patch to that effect I guess. I mean quite literally deferred I/O _relies_ on an MMU doing page faulting to function at all. So this dependency was always an oversight (I guess they assumed nobody would be crazy enough to figure out a config that allows the combination of the two things as clearly no real hardware would :)
