From: "Richard Purdie" <rpurdie@rpsys.net>
To: <linux-kernel@vger.kernel.org>
Subject: Flaw in ide_unregister()
Date: Fri, 31 Dec 2004 12:04:54 -0000 [thread overview]
Message-ID: <007e01c4ef30$f23ba3c0$0f01a8c0@max> (raw)
I've been having some problems with calls to ide_unregister() (in ide.c).
This function is declared void which should mean it always succeeds and yet
it can fail *silently* under the following condition:
if (drive->usage || DRIVER(drive)->busy) goto abort;
(it also fails if (!hwif->present) although that is not a problem)
The driver I've been having problems with is ide-cs.c. Specifically if a CF
card is removed without ejecting and unmounting the card first. In this
case, the hardware is gone so we want the ide_unregister call to succeed and
yet the above code aborts the unregister (silently). This makes it an ide
problem rather than an ide-cs/pcmcia problem.
There are several solutions:
1. Fix ide_unregister so it always succeeds. (Preferred Solution)
2. Add parameter to ide_unregister to state whether it should abort on
busy/usage or not. (ugly)
3. Add a return value. What does ide-cs.c do with it though? The hardware is
gone. (doesn't help)
Only a limited number of drivers use ide_unregister():
drivers/ide/ide-pnp.c
drivers/ide/arm/rapide.c
drivers/ide/legacy/ide-cs.c
drivers/macintosh/mediabay.c
Of these, I can't see anything that would break if we make ide_unregister
always succeed.
I've tried removing the if statement above and just letting ide_unregister
succeed but the call then just deadlocks. I had to make some small changes
to ide.c and ide-disk.c to stop it using interfaces we've marked as dead and
allow deregistration of dead devices.
The bare minimum of code I needed to make ide_unregister succeed when called
from ide-cs.c is in the following patch:
http://www.rpsys.net/openzaurus/ide.patch
There are probably other places checks are needed. I would appreciate it if
someone could comment on whether these changes can be made to the ide
drivers, what else may need to be done or if there is an alternative
solution I've overlooked.
Thanks,
Richard
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004
next reply other threads:[~2004-12-31 12:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-31 12:04 Richard Purdie [this message]
2005-01-02 14:36 ` Flaw in ide_unregister() Alan Cox
2005-01-09 22:37 ` Richard Purdie
2005-01-10 11:09 ` Alan Cox
2005-01-10 12:39 ` Richard Purdie
2005-01-10 19:23 ` Alan Cox
2005-01-10 21:17 ` Richard Purdie
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='007e01c4ef30$f23ba3c0$0f01a8c0@max' \
--to=rpurdie@rpsys.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox