From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: netdev@vger.kernel.org, linux-can@vger.kernel.org
Subject: Re: [PATCH 3/3] net: can: peak_usb: Do not do dma on the stack
Date: Sat, 14 Dec 2013 14:37:19 +0100 [thread overview]
Message-ID: <52AC5F0F.20105@pengutronix.de> (raw)
In-Reply-To: <52A9CBC1.4080809@peak-system.com>
[-- Attachment #1: Type: text/plain, Size: 4596 bytes --]
On 12/12/2013 03:44 PM, Stephane Grosjean wrote:
> Going back into linux-can peak_usb, and I'm currently having a quick
> look to what has changed during these several past months.
> I agree with the below patch that fixes the "DMAusage with USB core"
> issue, but - maybe I'm wrong - isn't there now amemory leak issue in
> "pcan_usb_pro_init()" function below?
>
> I mean, you now allocate "fi" and "bi" memory objects but, AFAIK, they
> aren't freed anywhere in the function, don't they?
Thanks for pointing out.
[...]
>> b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
>> index 30d79bf..8ee9d15 100644
>> --- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
>> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
[...]
>> @@ -851,21 +860,24 @@ static int pcan_usb_pro_stop(struct
>> peak_usb_device *dev)
>> */
>> static int pcan_usb_pro_init(struct peak_usb_device *dev)
>> {
>> - struct pcan_usb_pro_interface *usb_if;
>> struct pcan_usb_pro_device *pdev =
>> container_of(dev, struct pcan_usb_pro_device, dev);
>> + struct pcan_usb_pro_interface *usb_if = NULL;
>> + struct pcan_usb_pro_fwinfo *fi = NULL;
>> + struct pcan_usb_pro_blinfo *bi = NULL;
>> + int err;
>> /* do this for 1st channel only */
>> if (!dev->prev_siblings) {
>> - struct pcan_usb_pro_fwinfo fi;
>> - struct pcan_usb_pro_blinfo bi;
>> - int err;
>> -
>> /* allocate netdevices common structure attached to first
>> one */
>> usb_if = kzalloc(sizeof(struct pcan_usb_pro_interface),
>> GFP_KERNEL);
>> - if (!usb_if)
>> - return -ENOMEM;
>> + fi = kmalloc(sizeof(struct pcan_usb_pro_fwinfo), GFP_KERNEL);
>> + bi = kmalloc(sizeof(struct pcan_usb_pro_blinfo), GFP_KERNEL);
>> + if (!usb_if || !fi || !bi) {
>> + err = -ENOMEM;
>> + goto err_out;
>> + }
>> /* number of ts msgs to ignore before taking one into
>> account */
>> usb_if->cm_ignore_count = 5;
>> @@ -877,34 +889,34 @@ static int pcan_usb_pro_init(struct
>> peak_usb_device *dev)
>> */
>> err = pcan_usb_pro_send_req(dev, PCAN_USBPRO_REQ_INFO,
>> PCAN_USBPRO_INFO_FW,
>> - &fi, sizeof(fi));
>> + fi, sizeof(*fi));
>> if (err) {
>> - kfree(usb_if);
>> dev_err(dev->netdev->dev.parent,
>> "unable to read %s firmware info (err %d)\n",
>> pcan_usb_pro.name, err);
>> - return err;
>> + goto err_out;
>> }
>> err = pcan_usb_pro_send_req(dev, PCAN_USBPRO_REQ_INFO,
>> PCAN_USBPRO_INFO_BL,
>> - &bi, sizeof(bi));
>> + bi, sizeof(*bi));
>> if (err) {
>> - kfree(usb_if);
>> dev_err(dev->netdev->dev.parent,
>> "unable to read %s bootloader info (err %d)\n",
>> pcan_usb_pro.name, err);
>> - return err;
>> + goto err_out;
>> }
>> + /* tell the device the can driver is running */
>> + err = pcan_usb_pro_drv_loaded(dev, 1);
>> + if (err)
>> + goto err_out;
>> +
>> dev_info(dev->netdev->dev.parent,
>> "PEAK-System %s hwrev %u serial %08X.%08X (%u
>> channels)\n",
>> pcan_usb_pro.name,
>> - bi.hw_rev, bi.serial_num_hi, bi.serial_num_lo,
>> + bi->hw_rev, bi->serial_num_hi, bi->serial_num_lo,
>> pcan_usb_pro.ctrl_count);
>> -
>> - /* tell the device the can driver is running */
>> - pcan_usb_pro_drv_loaded(dev, 1);
>> } else {
>> usb_if = pcan_usb_pro_dev_if(dev->prev_siblings);
>> }
>> @@ -916,6 +928,13 @@ static int pcan_usb_pro_init(struct
>> peak_usb_device *dev)
>> pcan_usb_pro_set_led(dev, 0, 1);
>> return 0;
>> +
>> + err_out:
>> + kfree(bi);
>> + kfree(fi);
>> + kfree(usb_if);
>> +
>> + return err;
>> }
>> static void pcan_usb_pro_exit(struct peak_usb_device *dev)
I'll send a fix.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2013-12-14 13:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 12:15 pull-request: can 2013-06-03 Marc Kleine-Budde
2013-06-03 12:15 ` [PATCH 1/3] net: can: kvaser_usb: fix reception on "USBcan Pro" and "USBcan R" type hardware Marc Kleine-Budde
2013-06-03 12:15 ` [PATCH 2/3] net: can: esd_usb2: Do not do dma on the stack Marc Kleine-Budde
2013-06-03 12:15 ` [PATCH 3/3] net: can: peak_usb: " Marc Kleine-Budde
2013-12-12 14:44 ` Stephane Grosjean
2013-12-14 13:37 ` Marc Kleine-Budde [this message]
2013-06-04 21:31 ` pull-request: can 2013-06-03 David Miller
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=52AC5F0F.20105@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=s.grosjean@peak-system.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.