lkml.org 
[lkml]   [2009]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/7] Ksplice: Export symbols needed for Ksplice
On Wed, 4 Feb 2009, Rusty Russell wrote:

> On Saturday 06 December 2008 10:33:59 Jeff Arnold wrote:
> > From: Tim Abbott <tabbott@mit.edu>
> >
> > Ksplice uses several functions from module.c in order to resolve
> > symbols and implement dependency handling. Calling these functions
> > requires holding module_mutex, so it is exported.
>
> I have fought every attempt to export that. It was long a cause of misery
> and pain; people saw the lock and so started grabbing it.
>
> Any chance we can find another way?

It is definitely possible, but it wouldn't be pretty. There are a few
things that we use module_mutex for:

(1) Preventing races involving modules being unloaded during run-pre
matching. Functions such as kallsyms_on_each_symbol, find_symbol,
__module_text_address, __module_address, and find_module that are used to
obtain a module or a symbol can only be used within preempt_disable or
while holding module_mutex. Further, the values that they return can only
be used in the same such context, unless one module_gets the relevant
module in that context.

So, we'd change/add wrappers to a bunch of these functions to do their own
preempt_disable or grabbing of module_mutex, and to module_get the
relevant module before they return. We'd also need to change the Ksplice
code to module_put whenever we stop referencing a symbol. Since a lot of
the Ksplice kernel code is related to resolving symbols, I suspect this
latter part would be somewhat messy.

(2) Calling use_module. use_module needs to be called while holding
module_mutex because it changes the modules_which_use_me lists.

We could change this by creating a modified version of use_module that
grabs module_mutex itself; perhaps renaming the current use_module to
__use_module.

(3) Preventing races involving two different Ksplice updates being applied
at the same time.

This one is easy; we could just create a new ksplice_mutex.

-Tim Abbott


\
 
 \ /
  Last update: 2009-02-13 02:51    [from the cache]
©2003-2011 Jasper Spaans