All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tejun Heo <tj@kernel.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Kamalesh Babulal" <kamalesh@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	"Eric Dumazet" <dada1@cosmosbay.com>,
	"Américo Wang" <xiyou.wangcong@gmail.com>
Subject: Re: [PATCH] fix error handling in load_module()
Date: Tue, 22 Sep 2009 14:35:21 +0930	[thread overview]
Message-ID: <200909221435.22512.rusty@rustcorp.com.au> (raw)
In-Reply-To: <4AB79091.1050004@kernel.org>

On Tue, 22 Sep 2009 12:11:21 am Tejun Heo wrote:
> Hello, Andrew.
> 
> Andrew Morton wrote:
> > My reverse engineering of the secret, undocumented percpu_modfree()
> > indicates that its mad inventor intended that percpu_modfree(NULL) be a
> > valid thing to do.
> > 
> > It calls free_percpu(), all implementations of which appear to secretly
> > support free_percpu(NULL).
> 
> Eh... unfortunately, the original percpu_modfree() implementation
> didn't seem to support it.

OK, I'll Andrew's fix for Tejun, and after his (spot-on!) comment about
percpu_modfree never taking NULL, I've fixed the one caller to match
the other two:

Subject: module: don't call percpu_modfree on NULL pointer.

The general one handles NULL, the static obsolescent
(CONFIG_HAVE_LEGACY_PER_CPU_AREA) one in module.c doesn't; Eric's
commit 720eba31 assumed it did, and various frobbings since then kept
that assumption.

All other callers in module.c all protect it with an if; this effectively
does the same as free_init is only goto if we fail percpu_modalloc().

Reported-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Américo Wang <xiyou.wangcong@gmail.com>

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2522,8 +2522,8 @@ static noinline struct module *load_modu
  free_unload:
 	module_unload_free(mod);
 #if defined(CONFIG_MODULE_UNLOAD) && defined(CONFIG_SMP)
+	percpu_modfree(mod->refptr);
  free_init:
-	percpu_modfree(mod->refptr);
 #endif
 	module_free(mod, mod->module_init);
  free_core:

  reply	other threads:[~2009-09-22  5:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07 14:15 [PATCH] fix error handling in load_module() Kamalesh Babulal
2009-09-10 21:14 ` Andrew Morton
2009-09-14  9:42   ` Kamalesh Babulal
2009-09-21 11:00   ` Rusty Russell
2009-09-21 14:23     ` Tejun Heo
2009-09-21 14:41   ` Tejun Heo
2009-09-22  5:05     ` Rusty Russell [this message]
2009-09-22 10:10       ` Kamalesh Babulal

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=200909221435.22512.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=xiyou.wangcong@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.