From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
Cc: Naveen Goswamy <naveen.goswamy@polymtl.ca>,
Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Dave Jones <davej@redhat.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Kernel crashing on eject SD card
Date: Tue, 14 Feb 2012 14:31:19 +0100 [thread overview]
Message-ID: <20120214143119.345fead9@stein> (raw)
In-Reply-To: <4F3A4220.4010901@ce.jp.nec.com>
On Feb 14 Jun'ichi Nomura wrote:
> According to the comments by Huajun Li:
> http://www.spinics.net/lists/linux-scsi/msg55698.html
>
> The following commit has changed __blkdev_get() to end up calling
> sd_revalidate_disk() without getting a refcount of scsi_device:
>
> commit 1196f8b814f32cd04df334abf47648c2a9fd8324
> Author: Tejun Heo <tj@kernel.org>
> Date: Thu Apr 21 20:54:45 2011 +0200
>
> block: rescan partitions on invalidated devices on -ENOMEDIA too
>
> that could lead to oops like this:
>
> process A process B
> ----------------------------------------------
> sys_open
> __blkdev_get
> sd_open
> returns -ENOMEDIUM
> scsi_remove_device
> <scsi_device torn down>
> rescan_partitions
> sd_revalidate_disk
> <oops>
>
> Should "revalidate_disk" of block_device_operations work
> without successful open()?
>
> If so, sd_revalidate_disk() (and possibly other drivers) needs to be
> fixed. (e.g. use scsi_disk_get/put by itself)
>
> If not, __blkdev_get() or rescan_partision() should avoid calling
> "revalidate_disk" for -ENOMEDIUM case.
It may very well be that not only sd_revalidate_disk is affected.
I have yet to check whether the "open -> unplug -> ioctl -> oops" bug from
http://www.spinics.net/lists/linux-scsi/msg56254.html
(a) happens under 3.3-rc still (was reported against 3.2-rc7),
(b) affects sd devices too (was reported against sr devices).
--
Stefan Richter
-=====-===-- --=- -===-
http://arcgraph.de/sr/
next prev parent reply other threads:[~2012-02-14 13:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 0:19 Kernel crashing on eject SD card Naveen Goswamy
2012-02-12 21:08 ` Stefan Richter
2012-02-12 21:20 ` Stefan Richter
2012-02-13 1:46 ` Naveen Goswamy
2012-02-13 2:18 ` Dave Jones
2012-02-13 17:40 ` Naveen Goswamy
2012-02-14 11:14 ` Jun'ichi Nomura
2012-02-14 13:31 ` Stefan Richter [this message]
2012-02-14 16:28 ` Tejun Heo
2012-02-15 2:56 ` Jun'ichi Nomura
2012-02-15 17:26 ` Tejun Heo
2012-02-16 1:26 ` Jun'ichi Nomura
2012-02-16 16:36 ` Tejun Heo
2012-03-01 18:58 ` Luis Henriques
2012-03-02 0:12 ` Jun'ichi Nomura
2012-03-02 9:35 ` Luis Henriques
2012-03-02 9:41 ` 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=20120214143119.345fead9@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=axboe@kernel.dk \
--cc=davej@redhat.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=naveen.goswamy@polymtl.ca \
--cc=tj@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).