In that case they are filesystems or some other thing that fits the
model closely enough for try_ind_mod_count to be efficient. This
case is easy and solved as far as I'm concerned, do correct me if
I'm wrong. Assuming I'm not wrong, on to a hard and interesting
case.
> Or those entry points
> are not protected by try_inc_mod_count, so it must bump the refcnt, so
> you need to sleep in load until the module becomes unused again.
Let's consider LSM as a really hard case, and let's suppose that the
register_*'s just plug new functions into function tables. These functions
are just called indirectly, there is no module entry/exit accounting
whatsoever, except that the inc/dec rule must be followed where module code
itself might sleep.
Anyway, at the -EBARF point, all the function pointers have been restored to
their original state, but we may have some tasks executing in the module
already, which got in while _xxx was there. The solution is to do the
magic_wait_for_quiescence (yes I know it has a real name, I forgot it) before
returning -EBARF. Refcounts never come into it.
What did I miss? It was too easy.
Ah, I'm glossing over how the "I need to sleep" intramodule refcounts
interact with the magic quiescence test. Let's see if some sleep fixes that.
I doubt this is any central issue though. We could, for instance, pass the
address of the count variable to the quiescence tester, and it will be
examined at schedule time, however that works (I promise to find out soon).
> You have the same issue in the "wait for schedule" case on unload,
> where someone jumps in while you are unregistering.
We don't. Our LSM module will first restore all the function pointers to
their original state, then wait for everyone to schedule.
> My implementation
> decided to ignore this problem (ie. potentially wait forever with the
> module half-loaded) but it is an issue.
I don't see the endless wait. It looks to me like it's just the time
required for everyone to schedule, which is unbounded all right, but not in
any interesting sense.
-- 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/