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
2023-10-20T00:04:39Z

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