lkml.org 
[lkml]   [2002]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] In-kernel module loader 1/7
    Date
    In message <E181eOt-00044e-00@starship> you write:
    > > Definitely. We could simply allow schedule() to be called when
    > > preempt is disabled, but it's a useful debugging tool to not do that.
    >
    > It doesn't strike me as difficult or costly to accomodate this.

    It's possible, of course.

    > > And, of course, disabling preemption widely kind of defeats the point
    > > of having a preemptive kernel 8(
    >
    > It only needs to be turned off when unloading one of the "hard" modules.
    > This would be an incrementing disable to accodate simultaneous unloads.
    > During the unload your desktop might get a little bit less interactive,
    > but that's better than not being able to unload at all.

    It needs to be turned off when dealing with any interface which might
    be used by one of the hard modules. Which is pretty bad.

    > > I really wish the security guys had gone down the macro path, with
    > > something like
    > >
    > > #define security_check(func, default_val, ...)
    > > ({ if (try_inc_mod_count(security_ops->owner))
    > > security_ops->func(__VA_ARGS__);
    > > else
    > > default_val;
    > > })
    > Then everybody would complain about the extra overhead, no matter how
    > small it is.

    These people didn't even whimper when an extra (useless) indirect
    function call got added at all these points. It's easy to make this
    overhead only exist when a modular security module is in use (the
    try_inc_mod_count wedge solution), and the overhead for non-modules is
    one branch.

    > Conceptually, are there any outstanding issues with "hard"
    > way of unloading modules, assuming we can use the TRY_INC way[1] for
    > "easy" modules? One I don't recall being discussed, is the inherent
    > difficulty of unhooking an interface like LSM, one function at a time.

    Without preempt, it was relatively easy (my initial code preceeded
    preempt). With preempt, unless you touch the scheduler (I have code
    for that too, Ingo doesn't like it anyway), a module can't control its
    own reference counts.

    Either way, how do you return "Pretend I wasn't here" in general, if
    the module is being unloaded? Only the infrastructure knows what to
    do.

    If a module cannot control its own reference counts, every exported
    interface which can sleep needs to do the try_inc_modcount thing, or a
    module which uses it cannot be unloaded.

    Now, there remains a subtle problem with the try_inc_mod_count
    approach in general. It is the "spurious failure" problem, where
    eg. a notifier cannot inc the module count, and so does not call the
    registered notifier, but the module is still being initialized *OR* is
    in the middle of an attempt to remove the module (which fails, and the
    module is restored to "life").

    Will this be a problem in general? I don't think so, since I couldn't
    find an example, but it's possible.

    The major advantage of this scheme is the simplicity for module
    authors (for the vast majority, no change). Given the complete dogs
    breakfast most module authors made of the current module count scheme,
    that's a HUGE bonus.

    Rusty.
    --
    Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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