linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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;
as well as URLs for NNTP newsgroup(s).