[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Raceless module interface

    On Thu, 12 Sep 2002, Rusty Russell wrote:

    > Nope, that's one of the two problems. Read my previous post: the
    > other is partial initialization.
    > Your patch is two-stage delete, with the additional of a usecount
    > function. So you have to move the usecount from the module to each
    > object it registers: great for filesystems, but I don't think it buys
    > you anything (since they were easy anyway).

    I'm aware of the init problem, what I described was the core problem,
    which prevents any further cleanup.
    The usecount is optional, the only important question a module must be
    able to answer is: Are there any objects/references belonging to the
    module? It's a simple yes/no question. If a module can't answer that, it
    likely has more problem than just module unloading.
    How that interface is exactly done is open for discussion and needs to be

    > Moreover, I don't see where your patch prevented someone increasing
    > the module count during try_unregister_module(), so that check is
    > pointless (do it in userspace unless they specify rmmod -f).

    I don't see your problem, if someone looks up a module, he gets a
    reference to the module structure, if a reference count goes to zero the
    module must be completely freed. State changes are protected with a
    separate lock, if a module is loaded/unloaded an extra reference is used
    to prevent module removal.

    bye, Roman

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:4.930 / U:0.940 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site