From: Ji-Hun Kim <ji_hun.kim@samsung.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org, y.k.oh@samsung.com,
gregkh@linuxfoundation.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org, julia.lawall@lip6.fr,
baijiaju1990@gmail.com, forest@alittletooquiet.net,
santhameena13@gmail.com
Subject: Re: [PATCH v3] staging: vt6655: check for memory allocation failures
Date: Wed, 04 Apr 2018 07:24:10 +0000 [thread overview]
Message-ID: <20180404072410.GA31134@ubuntu> (raw)
In-Reply-To: <20180403104052.6wbomdguifrmlmpz@mwanda>
On Tue, Apr 03, 2018 at 01:40:52PM +0300, Dan Carpenter wrote:
> > desc->rd_info = kzalloc(sizeof(*desc->rd_info), GFP_KERNEL);
> > -
> > + if (!desc->rd_info) {
> > + ret = -ENOMEM;
> > + goto error;
> > + }
> > if (!device_alloc_rx_buf(priv, desc))
> > dev_err(&priv->pcid->dev, "can not alloc rx bufs\n");
> >
>
> We need to handle the case where device_alloc_rx_buf() fails as well...
Hi Dan, thanks for your comments! I will write a patch v5 including this fix.
> Some years back, I wrote a post about error handling that might be
> helpful:
> https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
This post is very helpful to me, Thank you.
> You are using "one err" and "do nothing" style error handling which are
> described in the post.
Sorry, I didn't fully understand "one err" and "do nothing" style error
handling of this code. The reason using goto instead of returns directly
was that for freeing previously allocated "rd_info"s in the for loop.
Please see below comment.
> > @@ -550,20 +554,29 @@ static void device_init_rd0_ring(struct vnt_private *priv)
> > if (i > 0)
> > priv->aRD0Ring[i-1].next_desc = cpu_to_le32(priv->rd0_pool_dma);
> > priv->pCurrRD[0] = &priv->aRD0Ring[0];
> > +
> > + return 0;
> > +error:
> > + device_free_rd0_ring(priv);
> > + return ret;
> > }
>
> Of course, Jia-Ju Bai is correct to say that this is a layering
> violation. Each function should only clean up after its self.
>
> Also, this is a very typical "one err" style bug which I explain about
> in my g+ post. The rule that applies here is that you should only free
> things which have been allocated. Since we only partially allocated the
> rd0 ring, device_free_rd0_ring() will crash when we do:
>
> dma_unmap_single(&priv->pcid->dev, rd_info->skb_dma,
> priv->rx_buf_sz, DMA_FROM_DEVICE);
>
> "rd_info" is NULL so rd_info->skb_dma is a NULL dereference.
For dealing with this problem, I added below code on patch v3. I think it
would not make Null dereferencing issues, because it will not enter
dma_unmap_single(), if "rd_info" is Null.
+ if (rd_info) {
+ dma_unmap_single(&priv->pcid->dev, rd_info->skb_dma,
+ priv->rx_buf_sz, DMA_FROM_DEVICE);
+ dev_kfree_skb(rd_info->skb);
+ kfree(desc->rd_info);
+ }
I would appreciate for your opinions what would be better way for freeing
allocated "rd_info"s in the loop previously.
Best regards,
Ji-Hun
WARNING: multiple messages have this Message-ID (diff)
From: Ji-Hun Kim <ji_hun.kim@samsung.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org, y.k.oh@samsung.com,
gregkh@linuxfoundation.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org, julia.lawall@lip6.fr,
baijiaju1990@gmail.com, forest@alittletooquiet.net,
santhameena13@gmail.com
Subject: Re: [PATCH v3] staging: vt6655: check for memory allocation failures
Date: Wed, 04 Apr 2018 16:24:10 +0900 [thread overview]
Message-ID: <20180404072410.GA31134@ubuntu> (raw)
In-Reply-To: <20180403104052.6wbomdguifrmlmpz@mwanda>
On Tue, Apr 03, 2018 at 01:40:52PM +0300, Dan Carpenter wrote:
> > desc->rd_info = kzalloc(sizeof(*desc->rd_info), GFP_KERNEL);
> > -
> > + if (!desc->rd_info) {
> > + ret = -ENOMEM;
> > + goto error;
> > + }
> > if (!device_alloc_rx_buf(priv, desc))
> > dev_err(&priv->pcid->dev, "can not alloc rx bufs\n");
> >
>
> We need to handle the case where device_alloc_rx_buf() fails as well...
Hi Dan, thanks for your comments! I will write a patch v5 including this fix.
> Some years back, I wrote a post about error handling that might be
> helpful:
> https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
This post is very helpful to me, Thank you.
> You are using "one err" and "do nothing" style error handling which are
> described in the post.
Sorry, I didn't fully understand "one err" and "do nothing" style error
handling of this code. The reason using goto instead of returns directly
was that for freeing previously allocated "rd_info"s in the for loop.
Please see below comment.
> > @@ -550,20 +554,29 @@ static void device_init_rd0_ring(struct vnt_private *priv)
> > if (i > 0)
> > priv->aRD0Ring[i-1].next_desc = cpu_to_le32(priv->rd0_pool_dma);
> > priv->pCurrRD[0] = &priv->aRD0Ring[0];
> > +
> > + return 0;
> > +error:
> > + device_free_rd0_ring(priv);
> > + return ret;
> > }
>
> Of course, Jia-Ju Bai is correct to say that this is a layering
> violation. Each function should only clean up after its self.
>
> Also, this is a very typical "one err" style bug which I explain about
> in my g+ post. The rule that applies here is that you should only free
> things which have been allocated. Since we only partially allocated the
> rd0 ring, device_free_rd0_ring() will crash when we do:
>
> dma_unmap_single(&priv->pcid->dev, rd_info->skb_dma,
> priv->rx_buf_sz, DMA_FROM_DEVICE);
>
> "rd_info" is NULL so rd_info->skb_dma is a NULL dereference.
For dealing with this problem, I added below code on patch v3. I think it
would not make Null dereferencing issues, because it will not enter
dma_unmap_single(), if "rd_info" is Null.
+ if (rd_info) {
+ dma_unmap_single(&priv->pcid->dev, rd_info->skb_dma,
+ priv->rx_buf_sz, DMA_FROM_DEVICE);
+ dev_kfree_skb(rd_info->skb);
+ kfree(desc->rd_info);
+ }
I would appreciate for your opinions what would be better way for freeing
allocated "rd_info"s in the loop previously.
Best regards,
Ji-Hun
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2018-04-04 7:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180330024416epcas2p2f566f43a8f5af8b4ebc17659e3cf0ecf@epcas2p2.samsung.com>
2018-03-30 2:44 ` [PATCH v3] staging: vt6655: check for memory allocation failures Ji-Hun Kim
2018-03-30 2:44 ` Ji-Hun Kim
2018-03-30 3:15 ` Jia-Ju Bai
2018-03-30 3:15 ` Jia-Ju Bai
2018-03-30 3:39 ` Ji-Hun Kim
2018-03-30 3:39 ` Ji-Hun Kim
2018-03-30 3:50 ` Jia-Ju Bai
2018-03-30 3:50 ` Jia-Ju Bai
2018-03-30 3:50 ` Ji-Hun Kim
2018-03-30 3:50 ` Ji-Hun Kim
2018-04-03 10:40 ` Dan Carpenter
2018-04-03 10:40 ` Dan Carpenter
2018-04-04 7:24 ` Ji-Hun Kim [this message]
2018-04-04 7:24 ` Ji-Hun Kim
2018-04-04 9:53 ` Dan Carpenter
2018-04-04 9:53 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180404072410.GA31134@ubuntu \
--to=ji_hun.kim@samsung.com \
--cc=baijiaju1990@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=forest@alittletooquiet.net \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=santhameena13@gmail.com \
--cc=y.k.oh@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.