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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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