Re: [RFC PATCH v3] RDMA/siw: use kzalloc_flex

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, May 13, 2026 at 04:17:03PM +0200, Bernard Metzler wrote:
> > @@ -338,25 +336,20 @@ struct siw_umem *siw_umem_get(struct ib_device *base_dev, u64 start,
> >   	struct sg_page_iter sg_iter;
> >   	struct sg_table *sgt;
> >   	u64 first_page_va;
> > -	int num_pages, num_chunks, i, rv = 0;
> > +	unsigned int num_pages, num_chunks, i;
> > +	int rv = 0;
> >   	if (!len)
> >   		return ERR_PTR(-EINVAL);
> >   	first_page_va = start & PAGE_MASK;
> >   	num_pages = PAGE_ALIGN(start + len - first_page_va) >> PAGE_SHIFT;
> > -	num_chunks = (num_pages >> CHUNK_SHIFT) + 1;
> > +	num_chunks = ((num_pages - 1) >> CHUNK_SHIFT) + 1;
> > -	umem = kzalloc_obj(*umem);
> > +	umem = kzalloc_flex(*umem, page_chunk, num_chunks);
> >   	if (!umem)
> >   		return ERR_PTR(-ENOMEM);
> I got the following comment from sashiko:
> 
> "Does umem->num_chunks need to be explicitly initialized here?"
> 
> sashiko correctly points out that only newer compilers do that
> initialization (I checked: only supported since gcc >= 15,
> clang >= 19).

Ignore this, kxalloc_flex should not be assumed to initialize anything
but 0. IDK why they put in the auto-initialize when it cannot be
relied on, security in depth I guess.

> > --- a/drivers/infiniband/sw/siw/siw_mem.h
> > +++ b/drivers/infiniband/sw/siw/siw_mem.h
> > @@ -17,7 +17,7 @@ int siw_check_mem(struct ib_pd *pd, struct siw_mem *mem, u64 addr,
> >   		  enum ib_access_flags perms, int len);
> >   int siw_check_sge(struct ib_pd *pd, struct siw_sge *sge,
> >   		  struct siw_mem *mem[], enum ib_access_flags perms,
> > -		  u32 off, int len);
> > +		  u32 off, u32 len);
> 
> Sashiko says:
> 
> "The parameter len in siw_check_sge() is changed to u32, but it looks like
> siw_check_mem() still takes an int for its len parameter."
> 
> 
> This is correct, but shall I correct code not related to that
> kzalloc_flex patch? I propose sending an extra patch fixing that
> broken signed buffer access len/offset treatment all over driver code
> in an extra patch. It is indeed broken and a great finding, but I'd
> like to keep things separately.

Seperate patch is fine

Jason