[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100923190854.GA32400@Krystal>
Date: Thu, 23 Sep 2010 15:08:54 -0400
From: Mathieu Desnoyers <compudj@...stal.dyndns.org>
To: Jason Baron <jbaron@...hat.com>
Cc: 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>,
Rusty Russell <rusty@...tcorp.com.au>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [PATCH 03/11] jump label: Base patch for jump label
* Mathieu Desnoyers (compudj@...stal.dyndns.org) wrote:
> * Jason Baron (jbaron@...hat.com) wrote:
[...]
> > jump label: fix __init module section race
> >
> > Jump label uses is_module_text_address() to ensure that the module
> > __init sections are valid before updating them. However, between the
> > check for a valid module __init section and the subsequent jump
> > label update, the module's __init section could be free out from under
> > us.
> >
> > We fix this potential race putting the address check *and* the jump
> > label update under a rcu_read_lock(), and making sure a grace period
> > has completed before we free the __init section.
> >
> > Thanks to Mathieu Desnoyers for pointing out this race condition.
Actually, there might be another way to deal with this that would not
require holding rcu read lock at all in this path, nor adding
synchronize_rcu in the module code.
This involves adding a notifier right before the init code is freed, so
the static jump code can disable all static jumps pointing to init code
area for the given module.
On the plus side, this means text_poke would be free to still use
synchronize_rcu() if it ever needs to. Also, calling a notifier chain
before freeing the module init region will hurt module load time much
less than waiting for a grace period.
Thoughts ?
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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