lkml.org 
[lkml]   [2023]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: drivers/infiniband/sw/rxe/rxe_mr.c:106:9: warning: array subscript 0 is outside array bounds of 'struct sg_table[0]'
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

\
 
 \ /
  Last update: 2023-10-20 02:05    [W:0.052 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site