[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210210090442.GV2696@kadam>
Date: Wed, 10 Feb 2021 12:04:42 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Amey Narkhede <ameynarkhede03@...il.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] staging: gdm724x: Fix DMA from stack
On Wed, Feb 10, 2021 at 02:28:11PM +0530, Amey Narkhede wrote:
> On 21/02/10 09:06AM, Greg KH wrote:
> > On Wed, Feb 10, 2021 at 01:31:34PM +0530, Amey Narkhede wrote:
> > > Stack allocated buffers cannot be used for DMA
> > > on all architectures so allocate hci_packet buffer
> > > using kzalloc().
> > >
> > > Signed-off-by: Amey Narkhede <ameynarkhede03@...il.com>
> > > ---
> > > Changes in v2:
> > > - Fixed build warning
> > > - Fixed memory leak using kfree
> > >
> > > drivers/staging/gdm724x/gdm_usb.c | 9 +++++++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/gdm724x/gdm_usb.c b/drivers/staging/gdm724x/gdm_usb.c
> > > index dc4da66c3..c4a9b90c5 100644
> > > --- a/drivers/staging/gdm724x/gdm_usb.c
> > > +++ b/drivers/staging/gdm724x/gdm_usb.c
> > > @@ -56,11 +56,15 @@ static int gdm_usb_recv(void *priv_dev,
> > >
> > > static int request_mac_address(struct lte_udev *udev)
> > > {
> > > - u8 buf[16] = {0,};
> > > - struct hci_packet *hci = (struct hci_packet *)buf;
> > > + u8 *buf;
> > > + struct hci_packet *hci;
> > > struct usb_device *usbdev = udev->usbdev;
> > > int actual;
> > > int ret = -1;
> > > + buf = kzalloc(16, GFP_KERNEL);
> >
> > checkpatch did not complain about this?
> No. checkpatch shows no errors and warnings.
> >
> > And why do you need 'buf' anymore now? Why not just allocate hci and
> > pass that to the request instead? Saves you an extra cast and an extra
> > pointer.
> >
> > thanks,
> >
> > greg k-h
> Thanks. I'll send v3. I assume now we don't need kzalloc anymore as we initialize
> the hci_packet so kmalloc(sizeof(struct hci_packet),..) will do.
We only initialize the first five bytes, but it also seems as if we only
use the first five bytes which raises the question of why we are
allocating 16 bytes.
regards,
dan carpenter
Powered by blists - more mailing lists