Right, so there's two problems there:
- the exposed function pointer
- unload serialization
The problem with the exposed function pointer is that two competing
modules can set the function pointer:
extern void (*ptr)(void);
static void (*old_ptr)(void);
void func(void)
{
/* do something */
}
module_init()
{
old_ptr = ptr;
ptr = func;
}
module_exit()
{
ptr = old_ptr;
synchronize_stuff();
}
Now suppose two modules A and B both have that template, then load
module A, at that time ptr == A::func, A::old_ptr = NULL, right?
Then load B, then ptr == B:func, B::old_ptr = A::func.
then unload A, then ptr == NULL; /* hey where's B gone? */
Suppose module_exit() had read:
module_exit()
{
if (ptr == func)
ptr = old_ptr;
}
Then after A got unloaded, you'd have: ptr = B::func, B::old_ptr ==
A:func, and the world goes *bang* when you unload B.
If you'd have exposed the thing like:
static void (*callback)(void);
int set_foo_callback(void (*func)(void))
{
if (callback && func)
return -EBUSY;
callback = func;
synchronize_world();
return 0;
}
EXPORT_SYMBOL_GPL(set_foo_callback);
Then there'd be no confusion, as loading B while A was already loaded
would fail since set_foo_callback() would fail with -EBUSY.
Now the synchronization issue, above represented by synchronize_world();
that will have to do something that ensures all current users of the ptr
have gone, taking a reference on the module will likely result in an
pinned module, since what will drop the ref again?
Module unload does a fairly heavy stop-machine thing, which might be
sufficient for some, but a sensible solution really depends on the
problem domain, RCU could be used in various ways.
--
