kaos@ocs.com.au said:
> get_module_symbol is only called from 8390.c. AFAICT, all of the
> calls to get_module_symbol eventually trace back to init_module which
> is always called with the big kernel lock. So as long as 8390 code
> does not sleep between calling get_module_symbol and incrementing the
> module use count then there are no races.
I am now trying to use it from somewhere else. I believe that I don't have
the kernel lock at this point because I've just called kmalloc().
I don't think it's sensible to make the kernel lock a prerequisite for
using get_module_symbol() - finer grained locking isn't particularly
difficult to achieve here.
> Macro lock_8390_module increments the module use count so you just
> need to make sure that it is called after a successful
> get_module_symbol and before sleeping. There is no need to change
> get_module_symbol nor to add put_module_symbol.
... if you accept the premise that get_module_symbol() should require the
kernel lock to be held during use. Which I don't.
> Incrementing mod use count inside get_module_symbol would prevent any
> 8390 module from ever being unloaded because of the 5 calls to
> get_module_symbol in NS8390_KSYSMS_PRESENT with no cleanup calls.
I was aware of that - that's why I said it wanted fixing. It shouldn't be
difficult.
> Also there is no need to test for the MOD_DELETED flag, MOD_CAN_QUERY
> already does that.
Oh well, it will get optimised away. If Linus doesn't accept the patch,
I'll remove the extra check when I resubmit it.
-- dwmw2- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:10 EST