From: Andrea Arcangeli <andrea@suse.de>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: module unload deadlock
Date: Wed, 18 Feb 2004 16:40:41 +0100 [thread overview]
Message-ID: <20040218154040.GZ4478@dualathlon.random> (raw)
In-Reply-To: <20040218043555.GY8858@parcelfarce.linux.theplanet.co.uk>
On Wed, Feb 18, 2004 at 04:35:55AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Feb 18, 2004 at 02:29:21PM +1100, Rusty Russell wrote:
> > > the actual module doing request_modules in the cleanup handler is
> > > parport_pc, calling parport_enumerate (it calls it for another reason,
> > > and parport enumerate is told to load up a lowlevel driver if none was
> > > present, that's worthless for the unload routine but it's useful for all
> > > other calls of parport_enumerate). It's uncertain if other drivers
>
> Bullshit. Other calls of parport_enumerate() must die - along with that one.
> Patches will go to akpm tomorrow.
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.
next prev parent reply other threads:[~2004-02-18 15:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-17 17:26 module unload deadlock Andrea Arcangeli
2004-02-18 3:29 ` Rusty Russell
2004-02-18 4:35 ` viro
2004-02-18 15:40 ` Andrea Arcangeli [this message]
2004-02-18 16:46 ` viro
2004-02-18 17:24 ` Andrea Arcangeli
2004-02-18 17:37 ` viro
2004-02-18 17:57 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040218154040.GZ4478@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.