Re: [akpm-mm:mm-new 418/422] fs/orangefs/file.c:414:9: sparse: sparse: dereference of noderef expression

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

On Tue, Jan 20, 2026 at 10:56:04AM +0000, Lorenzo Stoakes wrote:
> On Tue, Jan 20, 2026 at 05:10:47PM +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-new
> > head:   e4348a62bb1acacafcdeb149c9363291fae08c0c
> > commit: ccbdd8044f13617fe9f2bce61aed556314544664 [418/422] mm: update all remaining mmap_prepare users to use vma_flags_t
> > config: arm-randconfig-r131-20260120 (https://download.01.org/0day-ci/archive/20260120/202601201701.IhxeGffs-lkp@intel.com/config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 11.5.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260120/202601201701.IhxeGffs-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/202601201701.IhxeGffs-lkp@intel.com/
> >
> > sparse warnings: (new ones prefixed by >>)
> > >> fs/orangefs/file.c:414:9: sparse: sparse: dereference of noderef expression
> >    fs/orangefs/file.c: note: in included file (through arch/arm/include/asm/cacheflush.h, include/linux/cacheflush.h, include/linux/highmem.h, ...):
> >    include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1199:46: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1199:46: sparse: sparse: dereference of noderef expression
> >    fs/orangefs/file.c:415:9: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1048:16: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1216:48: sparse: sparse: dereference of noderef expression
> >    include/linux/mm.h:1216:48: sparse: sparse: dereference of noderef expression
> > --
> > >> fs/ramfs/file-nommu.c:267:40: sparse: sparse: dereference of noderef expression
> > >> fs/ramfs/file-nommu.c:267:40: sparse: sparse: dereference of noderef expression
> >    fs/ramfs/file-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 +414 fs/orangefs/file.c
> >
> >    397
> >    398	/*
> >    399	 * Memory map a region of a file.
> >    400	 */
> >    401	static int orangefs_file_mmap_prepare(struct vm_area_desc *desc)
> >    402	{
> >    403		struct file *file = desc->file;
> >    404		int ret;
> >    405
> >    406		ret = orangefs_revalidate_mapping(file_inode(file));
> >    407		if (ret)
> >    408			return ret;
> >    409
> >    410		gossip_debug(GOSSIP_FILE_DEBUG,
> >    411			     "orangefs_file_mmap: called on %pD\n", file);
> >    412
> >    413		/* set the sequential readahead hint */
> >  > 414		vma_desc_set_flags(desc, VMA_SEQ_READ_BIT);
>
> This is totally valid? vma_flags_set_mask() (which is ultimately invoked) uses
> ACCESS_PRIVATE() consistently.
>
> I wonder if mk_vma_flags() is an issue as it ultimately does (const vma_flag_t
> []){ VMA_SEQ_READ_BIT } here that then gets 'dereferenced' by array access in
> __mk_vma_flags().
>
> Nothing is accessing __vma_flags in vma_flags_t directly however, it's all via
> ACCESS_PRIVATE() as far as I can tell?

I mean this makes sparse so damn cumbersome to use.

I do NOT want people doing flags->__vma_flags blah, and force ACCESS_PRIVATE()
for this field.

But I _do_ want to be able to pass around pointers to it, but sparse
unconditionally makes the type no de-ref and these warnings trigger if you ever
take a pointer, and there's no helper to help in that case AFAICT.

If I mark __vma_flags __private this does nothing, I can even do:

unsigned long *foo = flags.__vma_flags;

without any new sparse warnings

Which seems bizarre to me.

Touching headers generates endless (currently ignored) sparse warnings in
general so it's very hard to figure out if things break.

OK I think the best approach here is to drop __private, the __vma_flags
value should make it clear that access directly is a no-no, and we can
avoid all this :)

>
> >    415		vma_desc_clear_flags(desc, VMA_RAND_READ_BIT);
> >    416
> >    417		file_accessed(file);
> >    418		desc->vm_ops = &orangefs_file_vm_ops;
> >    419		return 0;
> >    420	}
> >    421
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
>
> Thanks, Lorenzo
>

Cheers, Lorenzo