[akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[kernel test robot]

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-new
head:   dc4fe40a11269aead253fa0beb098b00417b8694
commit: 57a654376d4bb67119d436edc8c3c4c0ecb3c369 [420/429] mm: update all remaining mmap_prepare users to use vma_flags_t
config: sh-randconfig-r122-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 13.4.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-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/202601221505.RxftadLx-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression
>> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression
   fs/romfs/mmap-nommu.c: note: in included file:
   include/linux/mm.h:1954:16: sparse: sparse: dereference of noderef expression
   include/linux/mm.h:1954:16: sparse: sparse: dereference of noderef expression
   include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression
   include/linux/mm.h:1954:16: sparse: sparse: dereference of noderef expression
   include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression

vim +66 fs/romfs/mmap-nommu.c

    59	
    60	/*
    61	 * permit a R/O mapping to be made directly through onto an MTD device if
    62	 * possible
    63	 */
    64	static int romfs_mmap_prepare(struct vm_area_desc *desc)
    65	{
  > 66		return is_nommu_shared_vma_flags(desc->vma_flags) ? 0 : -ENOSYS;
    67	}
    68	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[Andrew Morton]

On Thu, 22 Jan 2026 16:04:37 +0800 kernel test robot <lkp@intel.com> 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-new
> head:   dc4fe40a11269aead253fa0beb098b00417b8694
> commit: 57a654376d4bb67119d436edc8c3c4c0ecb3c369 [420/429] mm: update all remaining mmap_prepare users to use vma_flags_t
> config: sh-randconfig-r122-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-lkp@intel.com/config)

Has CONFIG_NOMMU=y

> compiler: sh4-linux-gcc (GCC) 13.4.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-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/202601221505.RxftadLx-lkp@intel.com/
> 
> sparse warnings: (new ones prefixed by >>)
> >> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

fs/romfs/Makefile has

ifneq ($(CONFIG_MMU),y)
romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o
endif

so why is mmap-nommu.o being compiled in this testing??

Re: [akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[Philip Li]

On Thu, Jan 22, 2026 at 01:23:35PM -0800, Andrew Morton wrote:
> On Thu, 22 Jan 2026 16:04:37 +0800 kernel test robot <lkp@intel.com> 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-new
> > head:   dc4fe40a11269aead253fa0beb098b00417b8694
> > commit: 57a654376d4bb67119d436edc8c3c4c0ecb3c369 [420/429] mm: update all remaining mmap_prepare users to use vma_flags_t
> > config: sh-randconfig-r122-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-lkp@intel.com/config)
> 
> Has CONFIG_NOMMU=y
> 
> > compiler: sh4-linux-gcc (GCC) 13.4.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-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/202601221505.RxftadLx-lkp@intel.com/
> > 
> > sparse warnings: (new ones prefixed by >>)
> > >> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression
> 
> fs/romfs/Makefile has
> 
> ifneq ($(CONFIG_MMU),y)
> romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o
> endif
> 
> so why is mmap-nommu.o being compiled in this testing??

Hi Andrew, the related configs are set as below, and this is guarded
with CONFIG_MMU, thus the build is triggered for mmap-nommu.o.

# CONFIG_MMU is not set
CONFIG_NOMMU=y

> 

Re: [akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[Andrew Morton]

On Fri, 23 Jan 2026 12:19:59 +0800 Philip Li <philip.li@intel.com> wrote:

> On Thu, Jan 22, 2026 at 01:23:35PM -0800, Andrew Morton wrote:
> > On Thu, 22 Jan 2026 16:04:37 +0800 kernel test robot <lkp@intel.com> 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-new
> > > head:   dc4fe40a11269aead253fa0beb098b00417b8694
> > > commit: 57a654376d4bb67119d436edc8c3c4c0ecb3c369 [420/429] mm: update all remaining mmap_prepare users to use vma_flags_t
> > > config: sh-randconfig-r122-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-lkp@intel.com/config)
> > 
> > Has CONFIG_NOMMU=y
> > 
> > > compiler: sh4-linux-gcc (GCC) 13.4.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-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/202601221505.RxftadLx-lkp@intel.com/
> > > 
> > > sparse warnings: (new ones prefixed by >>)
> > > >> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression
> > 
> > fs/romfs/Makefile has
> > 
> > ifneq ($(CONFIG_MMU),y)
> > romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o
> > endif
> > 
> > so why is mmap-nommu.o being compiled in this testing??
> 
> Hi Andrew, the related configs are set as below, and this is guarded
> with CONFIG_MMU, thus the build is triggered for mmap-nommu.o.
> 
> # CONFIG_MMU is not set
> CONFIG_NOMMU=y

Oh, OK, thanks, sorry, my brain ran out of multiple negation capacity.

The code which this report quoted had

 > 66		return is_nommu_shared_vma_flags(desc->vma_flags) ? 0 : -ENOSYS;

whereas Lorenzo's v2 patchset has

        return is_nommu_shared_vma_flags(&desc->vma_flags) ? 0 : -ENOSYS;

so I expect that the new `&' fixed this issue.

Re: [akpm-mm:mm-new 420/429] fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression

[Lorenzo Stoakes]

On Thu, Jan 22, 2026 at 09:48:30PM -0800, Andrew Morton wrote:
> On Fri, 23 Jan 2026 12:19:59 +0800 Philip Li <philip.li@intel.com> wrote:
>
> > On Thu, Jan 22, 2026 at 01:23:35PM -0800, Andrew Morton wrote:
> > > On Thu, 22 Jan 2026 16:04:37 +0800 kernel test robot <lkp@intel.com> 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-new
> > > > head:   dc4fe40a11269aead253fa0beb098b00417b8694
> > > > commit: 57a654376d4bb67119d436edc8c3c4c0ecb3c369 [420/429] mm: update all remaining mmap_prepare users to use vma_flags_t
> > > > config: sh-randconfig-r122-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-lkp@intel.com/config)
> > >
> > > Has CONFIG_NOMMU=y
> > >
> > > > compiler: sh4-linux-gcc (GCC) 13.4.0
> > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221505.RxftadLx-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/202601221505.RxftadLx-lkp@intel.com/
> > > >
> > > > sparse warnings: (new ones prefixed by >>)
> > > > >> fs/romfs/mmap-nommu.c:66:42: sparse: sparse: dereference of noderef expression
> > >
> > > fs/romfs/Makefile has
> > >
> > > ifneq ($(CONFIG_MMU),y)
> > > romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o
> > > endif
> > >
> > > so why is mmap-nommu.o being compiled in this testing??
> >
> > Hi Andrew, the related configs are set as below, and this is guarded
> > with CONFIG_MMU, thus the build is triggered for mmap-nommu.o.
> >
> > # CONFIG_MMU is not set
> > CONFIG_NOMMU=y
>
> Oh, OK, thanks, sorry, my brain ran out of multiple negation capacity.
>
> The code which this report quoted had
>
>  > 66		return is_nommu_shared_vma_flags(desc->vma_flags) ? 0 : -ENOSYS;
>
> whereas Lorenzo's v2 patchset has
>
>         return is_nommu_shared_vma_flags(&desc->vma_flags) ? 0 : -ENOSYS;
>
> so I expect that the new `&' fixed this issue.

Well more so with the sparse stuff my removing the __private sparse decoration :)

It actually ended up being counterproductive in practice, and the obvious
'wrong' thing of vma->flags.__vma_flags |= ... or whatever already signals to
any reviewers that the kernel developer doing something like that is being
'naughty' so no need to enforce ACCESS_PRIVATE() etc., which in any case cannot
work with the semantics we need for vma_flags_t.

Cheers, Lorenzo