All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akira Hayakawa <ruby.wktk@gmail.com>
To: Kumar Amit Mehta <gmate.amit@gmail.com>,
	device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] dm-lc.c: fix for a potential NULL pointer dereference
Date: Wed, 31 Jul 2013 22:04:09 +0900	[thread overview]
Message-ID: <51F90B49.60708@gmail.com> (raw)
In-Reply-To: <1375272568-2730-1-git-send-email-gmate.amit@gmail.com>

Thanks, Kumar.
Your patch is applied.

resume_cache,
a routine to build in-memory data structures
by reading metadata on cache device,
is so complicated in the code and the logic
to thoroughly implement the error checks.

I am wondering how I should face this problem.
Only caring about lines
that allocates large-sized memories
and forget about anything else
is what I am thinking now.
But it is clear that
it is not a way kernel module should be.

Do you guys have some thoughts on this problem?

On 7/31/13 9:09 PM, Kumar Amit Mehta wrote:
> Memory allocation may fail, hence add a check before dereferencing
> the pointer.
> 
> Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com>
> ---
>  Driver/dm-lc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Driver/dm-lc.c b/Driver/dm-lc.c
> index 4a65042..e00fb27 100644
> --- a/Driver/dm-lc.c
> +++ b/Driver/dm-lc.c
> @@ -2671,6 +2671,8 @@ static int lc_mgr_message(struct dm_target *ti, unsigned int argc, char **argv)
>  	 */
>  	if (!strcasecmp(cmd, "resume_cache")) {
>  		struct lc_cache *cache = kzalloc(sizeof(*cache), GFP_KERNEL);
> +		if (!cache)
> +			return -ENOMEM;
>  
>  		struct dm_dev *dev;
>  		if (dm_get_device(ti, argv[1], dm_table_get_mode(ti->table),
> 

  reply	other threads:[~2013-07-31 13:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31 12:09 [PATCH] dm-lc.c: fix for a potential NULL pointer dereference Kumar Amit Mehta
2013-07-31 13:04 ` Akira Hayakawa [this message]
2013-07-31 15:57   ` dm-lc code/design [was: Re: dm-lc.c: fix for a potential NULL pointer dereference] Mike Snitzer
2013-08-01 12:45     ` Akira Hayakawa

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=51F90B49.60708@gmail.com \
    --to=ruby.wktk@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=gmate.amit@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.