On Sun, 7 May 2000 16:46:39 +0100 (GMT),
David Woodhouse <David.Woodhouse@mvhi.com> wrote:
>Unless I'm missing something, there was previously no guarantee, when you
>call get_module_symbol and subsequently dereference the pointer it
>returns, that the module containing your symbol will still be present by
>the time you use it.
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.
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.
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. Also
there is no need to test for the MOD_DELETED flag, MOD_CAN_QUERY
already does that.
There may be a race inside 8390.c init_module, lock_8390_module is not
called as soon as a card is found. However that section of code is
peculiar and any changes need to be verified by Donald Becker. I will
take that up with DB off the list.
-
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 : Sun May 07 2000 - 21:00:21 EST