Re: PATCH: get_module_symbol() not SMP-safe

From: David Woodhouse (
Date: Mon May 08 2000 - 04:10:08 EST 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

> 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.


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:10 EST