[lkml]   [2010]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fwd: help needed with EXPORT_SYMBOL
    On Wed, 2010-08-25 at 14:57 +0530, Aijaz Baig wrote:

    > I am trying to understand if its possible to add functions dynamically
    > to the kernel source based on the presence of certain modules in the
    > running kernel image.
    > I did try what brian suggested with the function pointer and yeah it
    > does work. But I could not understand what peter was trying to say about
    > modular users since I suppose he mentioned one module (B in this case)
    > using a function pointer defined in (or by) module A. In my case, since
    > it is the kernel that is gonna use the function, I need to make sure
    > that the module doesn't get unloaded while we are using the function.

    Right, so there's two problems there:

    - the exposed function pointer
    - unload serialization

    The problem with the exposed function pointer is that two competing
    modules can set the function pointer:

    extern void (*ptr)(void);

    static void (*old_ptr)(void);

    void func(void)
    /* do something */

    old_ptr = ptr;
    ptr = func;

    ptr = old_ptr;

    Now suppose two modules A and B both have that template, then load
    module A, at that time ptr == A::func, A::old_ptr = NULL, right?

    Then load B, then ptr == B:func, B::old_ptr = A::func.

    then unload A, then ptr == NULL; /* hey where's B gone? */

    Suppose module_exit() had read:

    if (ptr == func)
    ptr = old_ptr;

    Then after A got unloaded, you'd have: ptr = B::func, B::old_ptr ==
    A:func, and the world goes *bang* when you unload B.

    If you'd have exposed the thing like:

    static void (*callback)(void);

    int set_foo_callback(void (*func)(void))
    if (callback && func)
    return -EBUSY;

    callback = func;
    return 0;

    Then there'd be no confusion, as loading B while A was already loaded
    would fail since set_foo_callback() would fail with -EBUSY.

    Now the synchronization issue, above represented by synchronize_world();
    that will have to do something that ensures all current users of the ptr
    have gone, taking a reference on the module will likely result in an
    pinned module, since what will drop the ref again?

    Module unload does a fairly heavy stop-machine thing, which might be
    sufficient for some, but a sensible solution really depends on the
    problem domain, RCU could be used in various ways.

     \ /
      Last update: 2010-08-25 12:27    [W:0.037 / U:2.324 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site