On Thu, Oct 17, 2024 at 11:48 AM Ian Abbott <abbotti@xxxxxxxxx> wrote: > On 17/10/2024 10:29, Ian Abbott wrote: > > On 16/10/2024 23:05, Jann Horn wrote: > >> On Wed, Oct 16, 2024 at 8:05 PM kernel test robot <lkp@xxxxxxxxx> wrote: > >>> [auto build test ERROR on 6485cf5ea253d40d507cd71253c9568c5470cd27] > >>> > >>> url: https://github.com/intel-lab-lkp/linux/commits/Jann-Horn/ > >>> comedi-Flush-partial-mappings-in-error-case/20241016-022809 > >>> base: 6485cf5ea253d40d507cd71253c9568c5470cd27 > >>> patch link: https://lore.kernel.org/r/20241015-comedi-tlb-v2-1- > >>> cafb0e27dd9a%40google.com > >>> patch subject: [PATCH v2] comedi: Flush partial mappings in error case > >>> config: arm-randconfig-004-20241016 (https://download.01.org/0day-ci/ > >>> archive/20241017/202410170111.K30oyTWa-lkp@xxxxxxxxx/config) > >>> compiler: arm-linux-gnueabi-gcc (GCC) 14.1.0 > >>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/ > >>> archive/20241017/202410170111.K30oyTWa-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/202410170111.K30oyTWa-lkp@xxxxxxxxx/ > >>> > >>> All errors (new ones prefixed by >>): > >>> > >>> arm-linux-gnueabi-ld: drivers/comedi/comedi_fops.o: in function > >>> `comedi_mmap': > >>>>> comedi_fops.c:(.text+0x4be): undefined reference to `zap_vma_ptes' > >> > >> Ugh, this one is from a nommu build ("# CONFIG_MMU is not set"), it > >> makes sense that you can't zap PTEs when you don't have any PTEs at > >> all... what really impresses me about this is that the rest of the > >> code compiles on nommu. I'm pretty sure this codepath wouldn't > >> actually _work_ on nommu, but apparently compiling it works? > >> > >> I don't know what the right fix is here - should the entire comedi > >> driver be gated on CONFIG_MMU, or only a subset of the mmap handler, > >> or something else? > > > > Given that it would also affect a lot of fbdev drivers that would also > > benefit from zapping partial mappings, I suggest that gating on > > CONFIG_MMU would not be the correct fix. > > Perhaps just add an #ifdef CONFIG_MMU around the affected call for now? Sure, I guess that works, though it's not particularly pretty. (And this codepath looks like it won't really work on nommu either way...) I'll change it that way for now.
