public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Om Narasimhan <om.turyx@gmail.com>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@lists.osdl.org
Subject: Re: [KJ] kmalloc to kzalloc patches for drivers/block [sane version]
Date: Thu, 21 Sep 2006 00:20:17 -0700	[thread overview]
Message-ID: <20060921072017.GA27798@us.ibm.com> (raw)
In-Reply-To: <6b4e42d10609202311t47038692x5627f51d69f28209@mail.gmail.com>

On 20.09.2006 [23:11:25 -0700], Om Narasimhan wrote:
> This patch changes the kmalloc() calls followed by memset(,0,) to kzalloc.
> 
>     cciss.c : Changed the kmalloc/memset pair to kzalloc
>     cpqarray.c : km2zalloc conversion and code size reduction by
> changing multiple cleanup calls and returns of the function
> getgeometry() by adding a label.
>     loop.c : km2zalloc converion
> 
> 
> 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>

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

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

> diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
> index 78082ed..8a697c7 100644
> --- a/drivers/block/cpqarray.c
> +++ b/drivers/block/cpqarray.c
> @@ -1642,58 +1639,46 @@ static void start_fwbk(int ctlr)
>      It is used only at init time.
>  *****************************************************************/
>  static void getgeometry(int ctlr)
> -{				
> -	id_log_drv_t *id_ldrive;
> -	id_ctlr_t *id_ctlr_buf;
> -	sense_log_drv_stat_t *id_lstatus_buf;
> -	config_t *sense_config_buf;
> +{

Unrelated whitespace change.

> +	id_log_drv_t *id_ldrive = NULL;
> +	id_ctlr_t *id_ctlr_buf = NULL;
> +	sense_log_drv_stat_t *id_lstatus_buf = NULL;
> +	config_t *sense_config_buf = NULL;

Why initialize if you're going to immediately assign the return of
kzalloc()?

>  	unsigned int log_unit, log_index;
>  	int ret_code, size;
> -	drv_info_t *drv;
> +	drv_info_t *drv = NULL;

What does this do? Seems unnecessary and unrelated.

<snip>

> -		kfree(id_ctlr_buf);
> -		kfree(id_ldrive);
>  		printk( KERN_ERR "cpqarray:  out of memory.\n");
> -		return;
> +		goto end;

All of this rearrangement needs to be a separate patch.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

  reply	other threads:[~2006-09-21  7:19 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 ` Nishanth Aravamudan [this message]
2006-09-22  5:40   ` [KJ] " 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
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=20060921072017.GA27798@us.ibm.com \
    --to=nacc@us.ibm.com \
    --cc=kernel-janitors@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --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