public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Amey Narkhede <ameynarkhede03@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: gdm724x: Fix DMA from stack
Date: Wed, 10 Feb 2021 12:04:42 +0300	[thread overview]
Message-ID: <20210210090442.GV2696@kadam> (raw)
In-Reply-To: <20210210085811.7dunnfly6cqw67m3@archlinux>

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@gmail.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


  reply	other threads:[~2021-02-10  9:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  8:01 [PATCH v2] staging: gdm724x: Fix DMA from stack Amey Narkhede
2021-02-10  8:06 ` Greg KH
2021-02-10  8:58   ` Amey Narkhede
2021-02-10  9:04     ` Dan Carpenter [this message]
2021-02-10 10:48       ` Amey Narkhede
2021-02-10  9:09     ` Greg KH
2021-02-10 10:54       ` Amey Narkhede
  -- strict thread matches above, loose matches on Subject: below --
2021-02-09 19:31 ameynarkhede03
2021-02-09 19:52 ` Greg KH

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=20210210090442.GV2696@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=ameynarkhede03@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox