From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: IDE locking problem
Date: 05 Aug 2003 13:18:15 +0200 [thread overview]
Message-ID: <1060082295.600.135.camel@gaston> (raw)
In-Reply-To: <Pine.SOL.4.30.0308051236250.552-100000@mion.elka.pw.edu.pl>
> It only works with default/legacy io bases.
Which is all I care about in this specific situation. The "mediabay"
hotswap controller is driven by ide-pmac, which provides it's own
ide_init_hwif_ports() and ide_default_io_base() arch hooks. (In the
PPC arch, those arch functions can be themselves hooked in by the
actual platform code, on pmac, this goes to ide-pmac, though I also
deal with added PCI cards).
> > Also, look at my patch, we also _NEED_ to add some proper
> > device_unregister calls to ide_unregister() or this function will
> > leave dangling entries in the device list, and since those have the
> > same restrictions as the new blk_cleanup_queue(), we really need to
> > do that without the lock held.
>
> Yes.
That reminds me that without this fix, even ide-cs will break things
when ejecting a CF card for example.
> > I'd suggest merging my patch for now, it won't make things much
> > worse than what they are today regarding racyness of IDE registration
> > and unregistration, we an look into sanitizing this as a 2.7 goal.
>
> Okay :\.
Heh, thanks... Well... who else uses ide_unregister except ide-pmac and
ide-cs anyway ? If it's really that little used, it's quite under control
and we can try to clean it up a bit more then during early 2.6.0...
Right now, I'm waiting to see what we can come up to with Jens Axboe
regarding race-free teardown of the blk queue. Once that's agreed, we
can think about just removing the call to init_hwif_data and just reinit
the drive array ourselves. That would be a good thing anyway as the
current ide_unregister allocation of a full hwif_t on stack is causing
other problems (stack bloat typically, an issue with people trying to
shrink the kernel process stack to 1 page).
Ben.
next prev parent reply other threads:[~2003-08-05 11:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-03 8:42 IDE locking problem Benjamin Herrenschmidt
2003-08-03 9:58 ` Benjamin Herrenschmidt
2003-08-05 0:28 ` Bartlomiej Zolnierkiewicz
2003-08-05 8:08 ` Benjamin Herrenschmidt
2003-08-05 10:49 ` Bartlomiej Zolnierkiewicz
2003-08-05 11:18 ` Benjamin Herrenschmidt [this message]
2003-08-05 12:30 ` Bartlomiej Zolnierkiewicz
2003-08-05 17:13 ` Alan Cox
2003-08-03 10:04 ` Jens Axboe
2003-08-03 10:08 ` Jens Axboe
2003-08-03 10:11 ` Benjamin Herrenschmidt
2003-08-03 10:20 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2003-08-03 14:13 Manfred Spraul
2003-08-03 14:25 ` Benjamin Herrenschmidt
2003-08-03 15:35 ` Lou Langholtz
2003-08-04 5:40 ` Jens Axboe
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=1060082295.600.135.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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.