Re: drivers/infiniband/sw/rxe/rxe_mr.c:106:9: warning: array subscript 0 is outside array bounds of 'struct sg_table[0]'

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Oct 19, 2023 at 11:22:00AM -0500, Bob Pearson wrote:
> On 10/19/23 10:33, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head:   dd72f9c7e512da377074d47d990564959b772643
> > commit: 592627ccbdff0ec6fff00fc761142a76db750dd4 RDMA/rxe: Replace rxe_map and rxe_phys_buf by xarray
> > date:   9 months ago
> > config: sparc-randconfig-c023-20211015 (https://download.01.org/0day-ci/archive/20231019/202310192300.lurP44yG-lkp@intel.com/config)
> > compiler: sparc64-linux-gcc (GCC) 13.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231019/202310192300.lurP44yG-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/202310192300.lurP44yG-lkp@intel.com/
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >    drivers/infiniband/sw/rxe/rxe_mr.c: In function 'rxe_mr_fill_pages_from_sgt.constprop':
> >>> drivers/infiniband/sw/rxe/rxe_mr.c:106:9: warning: array subscript 0 is outside array bounds of 'struct sg_table[0]' [-Warray-bounds=]
> >      106 |         __sg_page_iter_start(&sg_iter, sgt->sgl, sgt->orig_nents, 0);
> >          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >    cc1: note: source object is likely at address zero
> >>> drivers/infiniband/sw/rxe/rxe_mr.c:106:9: warning: array subscript 0 is outside array bounds of 'struct sg_table[0]' [-Warray-bounds=]
> >    cc1: note: source object is likely at address zero
> > 
> > 
> > vim +106 drivers/infiniband/sw/rxe/rxe_mr.c
> > 
> >     98	
> >     99	static int rxe_mr_fill_pages_from_sgt(struct rxe_mr *mr, struct sg_table *sgt)
> >    100	{
> >    101		XA_STATE(xas, &mr->page_list, 0);
> >    102		struct sg_page_iter sg_iter;
> >    103		struct page *page;
> >    104		bool persistent = !!(mr->access & IB_ACCESS_FLUSH_PERSISTENT);
> >    105	
> >  > 106		__sg_page_iter_start(&sg_iter, sgt->sgl, sgt->orig_nents, 0);
> >    107		if (!__sg_page_iter_next(&sg_iter))
> >    108			return 0;
> >    109	
> >    110		do {
> >    111			xas_lock(&xas);
> >    112			while (true) {
> >    113				page = sg_page_iter_page(&sg_iter);
> >    114	
> >    115				if (persistent && !is_pmem_page(page)) {
> >    116					rxe_dbg_mr(mr, "Page can't be persistent\n");
> >    117					xas_set_err(&xas, -EINVAL);
> >    118					break;
> >    119				}
> >    120	
> >    121				xas_store(&xas, page);
> >    122				if (xas_error(&xas))
> >    123					break;
> >    124				xas_next(&xas);
> >    125				if (!__sg_page_iter_next(&sg_iter))
> >    126					break;
> >    127			}
> >    128			xas_unlock(&xas);
> >    129		} while (xas_nomem(&xas, GFP_KERNEL));
> >    130	
> >    131		return xas_error(&xas);
> >    132	}
> >    133	
> > 
> 
> Jason,
> 
> Can you make sense out of this? The marked line (was 106, now 101)
> seems completely innocuous.

I think this is the key:

> >    cc1: note: source object is likely at address zero

So something is wrong with the call chain passing sgt into this
function, at least the compiler thinks it is an empty allocation.

Jason