[lkml]   [2002]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] In-kernel module loader 1/7
    (Warning, this is one of those reply-to-every-point posts, read on if you
    have masochistic tendencies.)

    On Wednesday 16 October 2002 08:11, Rusty Russell wrote:
    > > > 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.

    What are you thinking about here? (Oh, I see it's elaborated below.)

    As far as I can see, preemption only has to be disabled during the
    synchronize_kernel phase of unloading that one module, and this requirement
    is inherited neither by dependant or depending modules.

    > > 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.

    The current proposal touches the scheduler only in the slow path of
    preempt_schedule, does it not? It's hard to see what the objection to that
    would be. By the way, do you when I say "schedule on every cpu", is that
    exactly equivalent to your synchronize_kernel?

    > 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.

    But this question goes away if we get our preempt-off switch, no?

    > 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").

    Oh, I'm well aware of that one. This is a subtle design requirement that
    just didn't get to the top of the list of things to talk about, because of
    the other, competing things to talk about. To me, it's a given that the
    interface must not introduce any dead periods as a result of, say, the user
    attempting to unload a busy module. For "hard" modules there is no choice:
    the first step must necessarily be to remove the function hooks and thus deny
    the service the module was providing. For this kind of module, the unload
    should either wait until it succeeds or generate a user-visible error if it
    cannot. If the "hard" module also exports counting-style interfaces, then
    these should all be determined to be in a quiescent state before proceding
    with the unhooking.

    For pure counting-style modules, it's easy to avoid this problem: the module
    is placed in the can't-increment state if and only if the current count is
    zero, and from that point on we know the unload will either succeed or fail
    with an error.

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

    Since it's easy to avoid, why leave the fuzz there?

    Things get more interesting with (the proposed) rmmod -f. In this case
    some as-yet-undefined mechanism would try to, say, unmount all the
    filesystems using a given module. It's just too hard and too much work to
    try do the shy suitor thing here, and determine beforehand if all the
    unmounts will be successful. The easy way out is just to say "yes,
    rmmod -f may be unsuccessful but still change the system state, deal with
    it". An even easier way is just to put rmmod -f on the back burner for
    the time being.

    > 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.

    Yes, well, for "easy" modules, all the interfaces that are on the table
    or in use are simple. Hard modules require some care on the part of the
    author, but we knew that. IMHO, the important thing is to be able to state
    the rules clearly.

    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:30    [W:0.025 / U:24.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site