From: Jiri Slaby <jirislaby@gmail.com>
To: Om Narasimhan <om.turyx@gmail.com>
Cc: Nishanth Aravamudan <nacc@us.ibm.com>,
linux-kernel@vger.kernel.org, kernel-janitors@lists.osdl.org
Subject: Re: [KJ] kmalloc to kzalloc patches for drivers/block [sane version]
Date: Fri, 22 Sep 2006 10:36:40 +0200 [thread overview]
Message-ID: <4513A098.4060505@gmail.com> (raw)
In-Reply-To: <6b4e42d10609212240i3d02241djbdaa0176ab9bfb2b@mail.gmail.com>
Om Narasimhan wrote:
> Thanks for the comments.
>> >
>> > Signed off by Om Narasimhan <om.turyx@gmail.com>
>>
>> This is not the canonical format, per SubmittingPatches. It should be:
>>
>> Signed-off-by: Random J Developer <random@developer.example.org>
> OK. I would take care of it.
>>
>> > drivers/block/cciss.c | 4 +--
>> > drivers/block/cpqarray.c | 72
>> +++++++++++++++-------------------------------
>> > drivers/block/loop.c | 4 +--
>> > 3 files changed, 25 insertions(+), 55 deletions(-)
>>
>> Your diffstat should have indicated to you that this should be split up
>> better. Please (re-)read SubmittingPatches. *One* logical change per
>> patch, most importantly.
> OK. I would resubmit.
>> >
>> > diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
>> > index 2cd3391..a800a69 100644
>> > --- a/drivers/block/cciss.c
>> > +++ b/drivers/block/cciss.c
>> > @@ -900,7 +900,7 @@ #if 0 /* 'buf_size'
>> member is 16-bits
>> > return -EINVAL;
>> > #endif
>> > if (iocommand.buf_size > 0) {
>> > - buff = kmalloc(iocommand.buf_size,
>> GFP_KERNEL);
>> > + buff = kzalloc(iocommand.buf_size,
>> GFP_KERNEL);
>> > if (buff == NULL)
>> > return -EFAULT;
>> > }
>> > @@ -911,8 +911,6 @@ #endif
>> > kfree(buff);
>> > return -EFAULT;
>> > }
>> > - } else {
>> > - memset(buff, 0, iocommand.buf_size);
>> > }
>> > if ((c = cmd_alloc(host, 0)) == NULL) {
>> > kfree(buff);
>>
>> This changes performance potentially, no? The memset before was
>> conditional upon (iocommand.Request.Type.Direction == XFER_WRITE) and
>> now the memory will always be zero'd.
> Yes, but not the functionality.
> if (iocommand.buf_size > 0), code allocates using kmalloc. if
> direction is XFER_WRITE, it does a copy_from_user(), and free()s the
> allocated buffer, not really caring what data came in from userspace.
> Else, it does memset(). So I could safely replace the kmalloc() with
> kzalloc() without compromising functionality.
Ok, this is something like I need 10 bytes of memory, so I request two memory
pages for reserved use. It works, but it kills performance.
Why you zero memory that is not needed to be zeroed?
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
next prev parent reply other threads:[~2006-09-22 8:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 6:11 kmalloc to kzalloc patches for drivers/block [sane version] Om Narasimhan
2006-09-21 7:20 ` [KJ] " Nishanth Aravamudan
2006-09-22 5:40 ` Om Narasimhan
2006-09-22 6:04 ` Om Narasimhan
2006-09-22 8:43 ` Jiri Slaby
2006-09-22 11:32 ` Paulo Marques
2006-09-22 12:03 ` Pekka Enberg
2006-09-22 13:03 ` Paulo Marques
2006-09-22 13:45 ` Dmitry Torokhov
2006-09-22 22:55 ` Om Narasimhan
2006-09-22 8:36 ` Jiri Slaby [this message]
2006-09-22 11:28 ` Paulo Marques
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=4513A098.4060505@gmail.com \
--to=jirislaby@gmail.com \
--cc=kernel-janitors@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nacc@us.ibm.com \
--cc=om.turyx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox