Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1291239 > unrolled thread

[PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc

Started byNicholas Mc Guire <hofrat@osadl.org>
First post2015-12-14 16:00 +0100
Last post2015-12-14 18:40 +0100
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc Nicholas Mc Guire <hofrat@osadl.org> - 2015-12-14 16:00 +0100
    RE: [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc "Marciniszyn, Mike" <mike.marciniszyn@intel.com> - 2015-12-14 16:30 +0100
      Re: [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc Nicholas Mc Guire <der.herr@hofr.at> - 2015-12-14 18:40 +0100

#1291239 — [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc

FromNicholas Mc Guire <hofrat@osadl.org>
Date2015-12-14 16:00 +0100
Subject[PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc
Message-ID<qFCLw-7vq-7@gated-at.bofh.it>
Add a null check after the kcalloc call as proposed by
Mike Marciniszyn <mike.marciniszyn@intel.com>.

Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---

Patch was compile tested with: x86_64_defconfig
CONFIG_INFINIBAND=m, CONFIG_STAGING=y, CONFIG_STAGING_RDMA=m

Patch is against linux-next (localversion-next is -next-20151214)

 drivers/staging/rdma/hfi1/chip.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/rdma/hfi1/chip.c b/drivers/staging/rdma/hfi1/chip.c
index 31eec8a..52d2bd7 100644
--- a/drivers/staging/rdma/hfi1/chip.c
+++ b/drivers/staging/rdma/hfi1/chip.c
@@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd, u32 first_ctxt)
 	if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
 		goto bail;
 	rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL);
+	if (!rsmmap)
+		goto bail;
+
 	/* init the local copy of the table */
 	for (i = 0, ctxt = first_ctxt; i < num_vls; i++) {
 		unsigned tctxt;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1291273

From"Marciniszyn, Mike" <mike.marciniszyn@intel.com>
Date2015-12-14 16:30 +0100
Message-ID<qFDex-7Vd-1@gated-at.bofh.it>
In reply to#1291239
> @@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd,
> u32 first_ctxt)
>  	if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
>  		goto bail;
>  	rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL);
> +	if (!rsmmap)
> +		goto bail;
> +

I checked out a linux-next remote at the next-20151214 tag.

The allocation method is clearly kmalloc_array() not kcalloc().

Where are you seeing the kcalloc()?

While it is tempting to allocate and zero, there is a chip rev specific difference.

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1291367

FromNicholas Mc Guire <der.herr@hofr.at>
Date2015-12-14 18:40 +0100
Message-ID<qFFgn-Lk-23@gated-at.bofh.it>
In reply to#1291273
On Mon, Dec 14, 2015 at 03:21:24PM +0000, Marciniszyn, Mike wrote:
> > @@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd,
> > u32 first_ctxt)
> >  	if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
> >  		goto bail;
> >  	rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL);
> > +	if (!rsmmap)
> > +		goto bail;
> > +
> 
> I checked out a linux-next remote at the next-20151214 tag.
> 
> The allocation method is clearly kmalloc_array() not kcalloc().
> 
> Where are you seeing the kcalloc()?
> 
> While it is tempting to allocate and zero, there is a chip rev specific difference.
>
x = kmalloc_array(...)
if(!x)
   ...
memset(x...)

should be equivalent to

kcalloc - include/linux/slab.h

static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
{
        return kmalloc_array(n, size, flags | __GFP_ZERO);
}

if the assumption that this is equvalent is wrong I appologize
the intent was simply API consolidation as the patch description
stated.

thx!
hofrta
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web