On Thu, Oct 17, 2024 at 11:48 AM Ian Abbott abbotti@mev.co.uk 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@intel.com 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@intel.com/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@intel.com/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@intel.com | Closes: https://lore.kernel.org/oe-kbuild- all/202410170111.K30oyTWa-lkp@intel.com/
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.