Yes, my earlier-posted algorithm was just plain wrong. So that's one
item out of the way.
> > > You can't disable preemption before calling in, because there is no
> > > way to sleep with preemption disabled. 8(
> >
> > Why is that harder than bumping a counter that makes preempt_schedule
> > return without doing anything?
>
> 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.
> 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.
> 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;
> })
>
> This also allows the whole thing to vanish if
> CONFIG_SECURITY_CAPABILITIES=n, and allows more flexibility for
> schemes like "always run with preemption disabled around security ops"
> or whatever, rather than having to search for all the references to
> security_ops.
Then everybody would complain about the extra overhead, no matter how
small it is. 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.
[1] Or a related way, to be determined via the tag-team mud-wrestling
method.
-- Daniel - 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/