lkml.org 
[lkml]   [2011]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH 12/16] [media] lmedm04: get rid of on-stack dma buffers
On Tue, 15 Mar 2011 20:54:43 +0000
Malcolm Priestley <tvboxspy@gmail.com> wrote:

> The patch failed for the following reason.
>
> On Tue, 2011-03-15 at 09:43 +0100, Florian Mickler wrote:
> > usb_control_msg initiates (and waits for completion of) a dma transfer using
> > the supplied buffer. That buffer thus has to be seperately allocated on
> > the heap.
> >
> > In lib/dma_debug.c the function check_for_stack even warns about it:
> > WARNING: at lib/dma-debug.c:866 check_for_stack
> >
> > Note: This change is tested to compile only, as I don't have the hardware.
> >
> > Signed-off-by: Florian Mickler <florian@mickler.org>
> > ---
> > drivers/media/dvb/dvb-usb/lmedm04.c | 16 +++++++++++++---
> > 1 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c b/drivers/media/dvb/dvb-usb/lmedm04.c
> > index 0a3e88f..bec5439 100644
> > --- a/drivers/media/dvb/dvb-usb/lmedm04.c
> > +++ b/drivers/media/dvb/dvb-usb/lmedm04.c
> > @@ -314,12 +314,17 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
> > static int lme2510_return_status(struct usb_device *dev)
> > {
> > int ret = 0;
> > - u8 data[10] = {0};
> > + u8 *data;
> > +
> > + data = kzalloc(10, GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> >
> > ret |= usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
> > 0x06, 0x80, 0x0302, 0x00, data, 0x0006, 200);
> > info("Firmware Status: %x (%x)", ret , data[2]);
> >
> > + kfree(data);
> > return (ret < 0) ? -ENODEV : data[2];
>
> data has been killed off when we need the buffer contents.
> changing to the following fixed.
>
> ret = (ret < 0) ? -ENODEV : data[2];
>
> kfree(data);
>
> return ret;

Yes. Thanks. I updated the patch locally.

>
> > @@ -603,7 +608,7 @@ static int lme2510_download_firmware(struct usb_device *dev,
> > const struct firmware *fw)
> > {
> > int ret = 0;
> > - u8 data[512] = {0};
> > + u8 *data;
> > u16 j, wlen, len_in, start, end;
> > u8 packet_size, dlen, i;
> > u8 *fw_data;
> > @@ -611,6 +616,11 @@ static int lme2510_download_firmware(struct usb_device *dev,
> > packet_size = 0x31;
> > len_in = 1;
> >
> > + data = kzalloc(512, GFP_KERNEL);
> > + if (!data) {
> > + info("FRM Could not start Firmware Download (Buffer allocation failed)");
>
> Longer than 80 characters,

I choose to ignore this warning to keep the string on one line (for
grep and co).

> > + return -ENOMEM;
> > + }
> >
> > info("FRM Starting Firmware Download");
> >
> > @@ -654,7 +664,7 @@ static int lme2510_download_firmware(struct usb_device *dev,
> > else
> > info("FRM Firmware Download Completed - Resetting Device");
> >
> > -
> > + kfree(data);
> > return (ret < 0) ? -ENODEV : 0;
> > }
> >
>
> Otherwise the patch as corrected has been put on test. No initial
> problems have been encountered.
>
> Regards
>
> Malcolm
>

Thanks. I added a
Tested-by: Malcolm Priestley <tvboxspy@gmail.com>,
if that is ok?

Do you know how often/when is the .identify_state callback called during
normal operation? I.e. is this memory allocation/deallocation
in lme2510_return_status happening often and should use a preallocated
buffer?

Regards,
Flo


\
 
 \ /
  Last update: 2011-03-15 22:49    [W:0.043 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site