All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Grabner <grabner@icg.tugraz.at>
To: line6linux-devel@lists.sourceforge.net
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Laurent Navet <laurent.navet@gmail.com>,
	devel@driverdev.osuosl.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernel-janitors@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation
Date: Tue, 04 Dec 2012 21:22:12 +0000	[thread overview]
Message-ID: <4461097.8nbt8bgEO9@medialab> (raw)
In-Reply-To: <CAJSP0QXcv3CYE=4Ci=vRZQgHU=nDjAYx3kbbCnVgGfcn0seTDg@mail.gmail.com>

Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <laurent.navet@gmail.com> 
wrote:
> > staging: line6: driver.c
> > 
> >  The semantic patch that makes this output is available
> >  in scripts/coccinelle/api/memdup.cocci.
> > 
> > Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
> > ---
> > 
> >  drivers/staging/line6/driver.c |    5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/line6/driver.c
> > b/drivers/staging/line6/driver.c index f5c19b2..e1d6241 100644
> > --- a/drivers/staging/line6/driver.c
> > +++ b/drivers/staging/line6/driver.c
> > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6
> > *line6)> 
> >         char *buffer;
> >         int retval;
> > 
> > -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > +       buffer = kmemdup(line6_request_version,
> > +                       sizeof(line6_request_version), GFP_ATOMIC);
> > 
> >         if (buffer = NULL) {
> >         
> >                 dev_err(line6->ifcdev, "Out of memory");
> >                 return -ENOMEM;
> >         
> >         }
> > 
> > -       memcpy(buffer, line6_request_version,
> > sizeof(line6_request_version)); -
> > 
> >         retval = line6_send_raw_message_async(line6, buffer,
> >         
> >                                               sizeof(line6_request_version
> >                                               ));
> >         
> >         kfree(buffer);
> > 
> > --
> > 1.7.10.4
> 
> Your change is fine but I'm not sure whether we should allocate memory
> in the first place:
I can't remember the precise reason for this copy operation, it was related to 
which type of memory is allowed for a URB data block, and memory declared with 
"static const char[]" at global scope in the driver is not allowed. I just 
verified on my system (kernel 3.4.11) that requesting the device's firmware 
version doesn't work when passing the line6_request_version pointer directly 
(instead of its kmemdup copy), so I think the kmemdup is necessary here. It's 
a bit unsatisfactory to make a copy just because the original data is not 
accessible for whatever reason, but I don't know of a better solution. Maybe 
somebody else can clarify this or propose an alternative method?

	Kind regards,
		Markus


WARNING: multiple messages have this Message-ID (diff)
From: Markus Grabner <grabner@icg.tugraz.at>
To: line6linux-devel@lists.sourceforge.net
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Laurent Navet <laurent.navet@gmail.com>,
	devel@driverdev.osuosl.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernel-janitors@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation
Date: Tue, 04 Dec 2012 22:22:12 +0100	[thread overview]
Message-ID: <4461097.8nbt8bgEO9@medialab> (raw)
In-Reply-To: <CAJSP0QXcv3CYE=4Ci=vRZQgHU=nDjAYx3kbbCnVgGfcn0seTDg@mail.gmail.com>

Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <laurent.navet@gmail.com> 
wrote:
> > staging: line6: driver.c
> > 
> >  The semantic patch that makes this output is available
> >  in scripts/coccinelle/api/memdup.cocci.
> > 
> > Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
> > ---
> > 
> >  drivers/staging/line6/driver.c |    5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/line6/driver.c
> > b/drivers/staging/line6/driver.c index f5c19b2..e1d6241 100644
> > --- a/drivers/staging/line6/driver.c
> > +++ b/drivers/staging/line6/driver.c
> > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6
> > *line6)> 
> >         char *buffer;
> >         int retval;
> > 
> > -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > +       buffer = kmemdup(line6_request_version,
> > +                       sizeof(line6_request_version), GFP_ATOMIC);
> > 
> >         if (buffer == NULL) {
> >         
> >                 dev_err(line6->ifcdev, "Out of memory");
> >                 return -ENOMEM;
> >         
> >         }
> > 
> > -       memcpy(buffer, line6_request_version,
> > sizeof(line6_request_version)); -
> > 
> >         retval = line6_send_raw_message_async(line6, buffer,
> >         
> >                                               sizeof(line6_request_version
> >                                               ));
> >         
> >         kfree(buffer);
> > 
> > --
> > 1.7.10.4
> 
> Your change is fine but I'm not sure whether we should allocate memory
> in the first place:
I can't remember the precise reason for this copy operation, it was related to 
which type of memory is allowed for a URB data block, and memory declared with 
"static const char[]" at global scope in the driver is not allowed. I just 
verified on my system (kernel 3.4.11) that requesting the device's firmware 
version doesn't work when passing the line6_request_version pointer directly 
(instead of its kmemdup copy), so I think the kmemdup is necessary here. It's 
a bit unsatisfactory to make a copy just because the original data is not 
accessible for whatever reason, but I don't know of a better solution. Maybe 
somebody else can clarify this or propose an alternative method?

	Kind regards,
		Markus


  reply	other threads:[~2012-12-04 21:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-03 13:20 [PATCH] line6: Use kmemdup rather than duplicating its implementation Laurent Navet
2012-12-03 13:20 ` Laurent Navet
2012-12-03 16:34 ` [Line6linux-devel] " Stefan Hajnoczi
2012-12-03 16:34   ` Stefan Hajnoczi
2012-12-04 21:22   ` Markus Grabner [this message]
2012-12-04 21:22     ` Markus Grabner
2012-12-04 21:29     ` Greg Kroah-Hartman
2012-12-04 21:29       ` Greg Kroah-Hartman
2012-12-04 22:25   ` Dan Carpenter
2012-12-04 22:25     ` 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=4461097.8nbt8bgEO9@medialab \
    --to=grabner@icg.tugraz.at \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=laurent.navet@gmail.com \
    --cc=line6linux-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefanha@gmail.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.