All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jesper Juhl <juhl-lkml@dif.dk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Katrina Tsipenyuk <ytsipenyuk@fortifysoftware.com>,
	katrina@fortifysoftware.com,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH][1/2] fix unchecked returns from kmalloc() (in kernel/module.c)
Date: Tue, 7 Dec 2004 22:29:58 +0100	[thread overview]
Message-ID: <20041207212958.GD10083@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0412072203070.3320@dragon.hygekrogen.localhost>

On Tue, Dec 07 2004, Jesper Juhl wrote:
> 
> Problem reported by Katrina Tsipenyuk and the Fortify Software engineering 
> team in thread with subject "PROBLEM: unchecked returns from kmalloc() in 
> linux-2.6.10-rc2".
> 
> The patch attempts to handle a failed kmalloc() a bit better than it 
> currently is. As I see it (and I'm not familliar with this code) there's 
> no really good way to cope with kmalloc failing on us here, so the best we 
> can do is print an error message and return a meaningful error value. As 
> the function is used with __initcall() I don't think much will actually 
> come of the negatve return, but returning -ENOMEM seems to me to be the 
> proper thing to do. Comments from someone who's actually familliar with 
> the code is very welcome.
> 
> Patch has been compile tested, boot tested, and didn't immediately blow 
> up my kernel, but that's all. Please review before applying.
> 
> Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
> 
> diff -up linux-2.6.10-rc3-bk2-orig/kernel/module.c linux-2.6.10-rc3-bk2/kernel/module.c
> --- linux-2.6.10-rc3-bk2-orig/kernel/module.c	2004-12-06 22:24:56.000000000 +0100
> +++ linux-2.6.10-rc3-bk2/kernel/module.c	2004-12-07 21:17:00.000000000 +0100
> @@ -334,6 +334,10 @@ static int percpu_modinit(void)
>  	pcpu_num_allocated = 2;
>  	pcpu_size = kmalloc(sizeof(pcpu_size[0]) * pcpu_num_allocated,
>  			    GFP_KERNEL);
> +	if (!pcpu_size) {
> +		printk(KERN_ERR "Unable to allocate per-cpu memory for modules.");
> +		return -ENOMEM;
> +	}

I'd say these cases are similar to SLAB_PANIC. Since it runs at boot, if
it fails it's likely an indication of some other problem, so dealing
with it here is silly. Perhaps just panic() on a NULL return.

Both of these fortify cases aren't real problems, imho. They trip a
stupid (no offense to the analyzer, but it's not human :) static
analyzer, that's all.

-- 
Jens Axboe


  reply	other threads:[~2004-12-07 21:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-07 21:23 [PATCH][1/2] fix unchecked returns from kmalloc() (in kernel/module.c) Jesper Juhl
2004-12-07 21:29 ` Jens Axboe [this message]
2004-12-07 22:56   ` Jesper Juhl
2004-12-07 22:57   ` Andries Brouwer
2004-12-08  7:01     ` Jens Axboe
2004-12-08  1:57 ` Rusty Russell

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=20041207212958.GD10083@suse.de \
    --to=axboe@suse.de \
    --cc=juhl-lkml@dif.dk \
    --cc=katrina@fortifysoftware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=ytsipenyuk@fortifysoftware.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.