Re: [PATCH 5/9] jump label: Addregister_jump_label_key/unregister_jump_label_key

[Jason Baron]

On Mon, Oct 18, 2010 at 02:05:21PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-10-15 at 23:13 +0200, Peter Zijlstra wrote:
> > On Fri, 2010-10-15 at 17:09 -0400, Steven Rostedt wrote:
> > > On Fri, 2010-10-15 at 23:03 +0200, Peter Zijlstra wrote:
> > > 
> > > > Urgh, this sucks.. :-(
> > > > 
> > > > So now we have to actually track all JUMP_LABEL() sites and call
> > > > register muck on them.. even though we already track them through the
> > > > special data section.
> > > > 
> > > > Is there really no way around this?
> > > 
> > > I'll take a look to see if we can monkey with magic and automate it.
> > 
> > So the problem is something like:
> > 
> > core kernel:
> > 
> >  jump_label_enable()
> > 
> > module:
> > 
> >  JUMP_LABEL()
> > 
> > And then because we don't have a proper __jump_table section, the
> > jump_label_enable() won't properly work?
> > 
> > Why not let jump_label_enable() add a dummy entry with the enabled bit
> > and once you load the module merge the real entry into it.
> 
> Or actually use the value of the key pointer.. it would mean either
> standardizing the size (int/atomic_t would work), or using a version of
> the fallback JUMP_LABEL implementation to sort out the type issues.


So I initially implmented this as 'jump_label_enable()' would add a new
entry for the key, if it didn't already exist. However, I was concerned
about the case where module 'a' defined the key variable, and then
module 'b' did the enable/disable, and then module 'a' was removed and
thus the key value could be re-used, and module's 'b' key would mean
something different.

However, I'm not sure that is possible - since module 'b' would have
symbol dependency on module 'a', and thus module 'a' could not be
unloaded before module 'b'.

Thus, when a module is freed, I think we can scan all the keys and check
if any key is contained within the text section of the module that is
about to be freed. If so, we simply remove that key entry. does this
make sense?

thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/