[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201009241014.35644.rusty@rustcorp.com.au>
Date: Fri, 24 Sep 2010 10:14:34 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: Jason Baron <jbaron@...hat.com>
Cc: Mathieu Desnoyers <compudj@...stal.dyndns.org>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Andi Kleen <andi@...stfloor.org>,
David Miller <davem@...emloft.net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 03/11] jump label: Base patch for jump label
On Fri, 24 Sep 2010 04:10:06 am Jason Baron wrote:
> @@ -2749,8 +2750,10 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
> mod->symtab = mod->core_symtab;
> mod->strtab = mod->core_strtab;
> #endif
> - module_free(mod, mod->module_init);
> + init_code = mod->module_init;
> mod->module_init = NULL;
> + synchronize_rcu();
> + module_free(mod, init_code);
> mod->init_size = 0;
> mod->init_text_size = 0;
> mutex_unlock(&module_mutex);
When a patch requires more lkml mails than it has lines, it needs a comment.
But step back for a moment: what prompts the jump label update? Why isn't
that simply done under the module lock, obviating any complexity?
If you're frobbing kernel text all over the place, you probable want the
module lock. You wouldn't be the first: perhaps we should rename that to
kernel_text_lock...
Apologies if that's a dumb question,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists