Messages in this thread | | | Date | Thu, 31 Jan 2002 15:58:17 -0800 | From | Dave Hansen <> | Subject | Revealing unload_lock to everyone |
| |
This came up in a conversation about ieee1394_core.c. In 2.5.3, the BKL is used to protect a module from being unloaded. The code looks like this:
lock_kernel(); read_lock(&ieee1394_chardevs_lock); file_ops = ieee1394_chardevs[blocknum].file_ops; module = ieee1394_chardevs[blocknum].module; read_unlock(&ieee1394_chardevs_lock); ... INCREF(module); unlock_kernel();
The question is, how can we keep the module from being unloaded between the file_ops assignment, and the INCREF. Do we have a general purpose way, other than the BKL, to keep a module from being unloaded? There is unload_lock, but it is static to module.c. We can always make it global, but is there a better solution?
-- Dave Hansen haveblue@us.ibm.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |