In message <20021117195258.GC3280@redhat.com> you write:> Because module loading of any incestious, cross-locking modules is horked > :-P> > NOTE: I suspect the same bug applies to IDE devices as well, but you > wouldn't see it unless you compile your IDE drivers as modules and use > initrd or equivelant to load the modules.> > Longer answer:> > Device scans happen almost exclusively at either host module init time or> device module init time. At that point in time, either the host the> device is on or the high level driver accessing the device will still be> in it's init_module() routine. That, of course, implies that either> host->hostt->module->live is 0 or that *_template->module->live is 0 (and> consequently so is fops->owner->live == 0).

Yes, it's an interesting corner case. As I implied before, if amodule is register an interface, you do not need to try_module_get().Why? Because *someone* already has a reference by definition (eitherthe module itself is calling you, or someone else with whom the moduleregistered).

Unfortunately, this does complicate code slightly if you other pathswhich *do* need the try_module_get(). But the existence of thisinterface is no accident: I know Al Viro wants to split every registerinterface to "reserve" and "use", and make all modules use themcorrectly, but I chose to avoid forcing such changes on all moduleauthors and all interface authors for good reason.

[ Mainly to Al ]:

I know what a PITA it is, because I implemented it a year ago. Sofirst the interface had to be changed to two-stage init, *then* themodule had to be changed to use it. If a module uses 5 interfaces,that's a series of five patches, each one interlocked with thecorresponding interface. And implementing it showed me that authorswere unlikely to correctly use any interface more complex than thecurrent one 8(

And it *still* means you need two paths for your code: one for "I knowit's not actually "active" yet, but I'm doing init and I need toaccess it anyway". So every interface gains significant complexity byeffectively implementing their own "live" flag...