Re: module unload deadlock

[viro]

On Wed, Feb 18, 2004 at 04:40:41PM +0100, Andrea Arcangeli wrote:
> On Wed, Feb 18, 2004 at 04:35:55AM +0000, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/