[Lse-tech] Re: Module Unloading using Read-Copy Update (Resending)

[Andrew M. <an...@uo...>]

Maneesh Soni wrote:
> 
> ...
> This is the analysis for module unloading problem and possible solution
> using read-copy update.

Like Andi says, I think the requirement to identify every
place where every module can block isn't going to be
popular.

We can probably have "wrapper" functions, so if a piece
of code calls

	kmalloc(something, somehow);

then that code gets expanded to

	mod_kmalloc(something, somehow);

which is contained in the kernel core, and which does
the kmod_blocked()/kmod_unblocked() stuff.

So it would be a matter of identifying all inlines
and exported functions which can sleep and then
make module code use these.  This is feasible.

It could be done with #defines, or perhaps with
relocation tricks in insmod.  Preferably the
latter - functions which can sleep would be exported
with a new macro:

	EXPORT_SYMBOL_SLEEP(foo, nargs)

which expands to

long mod_foo(args...)
{
	void *args = __builtin_apply_args();
	long result;

	kmod_blocked();
	result = __builtin_apply((void(*)())foo, args, (nargs + 4) * sizeof(long));
	kmod_unblocked();
	return __builtin_return(result);
}
EXPORT_SYMBOL(foo);
// Something here which tells insmod to use `mod_foo' for references
// to 'foo'

Or something like that....

 

Bear in mind, however, that there are moves afoot
to make the kernel internally preemptive.  I haven't
seen a decent discussion of the desirability of that,
but if it were to come about I think your requirement
to wrap blockable calls in this manner would rather
blow preemptability out of the water.  Something to think
about.


Rusty and Keith have another scheme for module unload which
also uses quiescent states.  Reading that email trail is on my
"things to do when I've had enough sleep" list.  I'll
try to get onto that in the next few days, see if I can
summarise it for you.