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
next prev parent 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.