Messages in this thread |  | | | Date | Wed, 18 Feb 2004 16:46:59 +0000 | | From | viro@parcelfa ... | | Subject | Re: module unload deadlock |
| |
On Wed, Feb 18, 2004 at 04:40:41PM +0100, Andrea Arcangeli wrote: > On Wed, Feb 18, 2004 at 04:35:55AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote: > It's clear this could be fixed by making sure parport won't call > request_module from cleanup_module, the primary reason I fixed it in the > module code is that I don't know if other drivers are doing this, do > you? What parport did was legitimate, and it was working fine in the > past, sure the parport code could be made slightly more complex and > aware about the fact it doesn't worth to try loading the lowlevel module > in cleanup_exit, but it wasn't obviously wrong, the cleanup/init module > are slow paths, it didn't matter if parport tried to load a lowlevel > module there.
Sigh...
No, it wasn't legitimate. As the matter of fact, _nothing_ outside of parport/share.c has any business looking at the list of ports. IOW, parport_enumerate() should be removed regardless of the request_module() crap.
In particular, parport_pc should keep track of the ports it had created instead of messing with parport_enumerate(). - 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/
|  |