lkml.org 
[lkml]   [2002]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRevealing 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/

\
 
 \ /
  Last update: 2005-03-22 13:16    [W:0.326 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site