[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57edd968-91d7-41f9-8a29-e86d8f583efa@gmail.com>
Date: Thu, 19 Oct 2023 11:22:00 -0500
From: Bob Pearson <rpearsonhpe@...il.com>
To: kernel test robot <lkp@...el.com>
Cc: oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: drivers/infiniband/sw/rxe/rxe_mr.c:106:9: warning: array
subscript 0 is outside array bounds of 'struct sg_table[0]'
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@...el.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.
Bob
Powered by blists - more mailing lists