linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Kleffel <tk@maintech.de>
To: bzolnier@gmail.com, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH] fix kernel oops, when IDE-Device (CF-Card) is removed while mounted.
Date: Mon, 12 Sep 2005 20:09:12 +0200	[thread overview]
Message-ID: <4325C448.6000303@maintech.de> (raw)
In-Reply-To: <58cb370e05091207435b91206f@mail.gmail.com>

Hi,

Bartlomiej Zolnierkiewicz wrote:

>> [...]
>>1b) When a disk is released by disk_release(), its queue's reference
>>count shall be decremented by calling blk_cleanup_queue().
> 
> 
> Which conflicts with IDE layer reference counting  & locking scheme
> as IDE layer can send (special) requests to the device without any
> device driver loaded.

But the IDE layer won't do that anymore after ide_unregister() was 
called, while a device driver doesn't know that the device doesn't exist 
anymore, so it may still access the queue until it releases the disk.

> 
> 
>>2a) When a physical drive is released by drive_release_dev(), the
>>corresponding queue is marked dead, so that no further calls to the
>>physical device's queue-handler are made.
>>
>>2b) When a request is submitted to a dead queue using
>>generic_make_request(), the request shall be failed immedaiately with
>>-ENXIO which causes the caller to recive a "Bus error". This is the same
>>beaviour as when a USB-Storage device gets pulled while in use.
> 
> 
> The fix would be to fail the previous requests during removal of the
> device [ somebody already posted a patch to do that but I didn't have
> time to give it proper thought ] or alternatively to add the offline state to
> the device [ so processing of the requests would be resumed after device
> is online again ].

I don't think it'd be wise to resume request processing on the same 
device as the CF Card inserted again might not be the same one as the 
user pulled out before. Performing old, cached writes on the new card 
could destroy innocent data.

 From your responses I read that the correct solution would be to keep 
the old pysical device as long as the ide layer still has references to 
it and to fail all requests in the meantime.

Is that correct?

Best regards,

Thomas

  reply	other threads:[~2005-09-12 18:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 18:54 [PATCH] fix kernel oops, when IDE-Device (CF-Card) is removed while mounted Thomas Kleffel
2005-09-12 14:43 ` Bartlomiej Zolnierkiewicz
2005-09-12 18:09   ` Thomas Kleffel [this message]
2005-09-13  8:36     ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2005-09-14  7:02 Chuck Ebbert

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=4325C448.6000303@maintech.de \
    --to=tk@maintech.de \
    --cc=bzolnier@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --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).