From: John Beard <john.j.beard@gmail.com>
To: linux-newbie@vger.kernel.org
Subject: Block device driver: how to terminate the block device if media disappears?
Date: Wed, 19 Dec 2012 11:21:59 +0000 [thread overview]
Message-ID: <50D1A357.1030004@gmail.com> (raw)
Hi,
I have block driver for a hot-pluggable device PCIe storage device.
The driver itself is relatively simple and implements the following
block operations:
static struct block_device_operations mydev_ops = {
.owner = THIS_MODULE,
.open = mydev_open,
.release = mydev_release,
.getgeo = mydev_getgeo,
.ioctl = mydev_ioctl
};
and the following PCI driver structure:
static struct pci_driver mydev_driver = {
.name = DRIVER_NAME,
.probe = mydev_pci_init_one,
.remove = mydev_pci_remove_one,
.id_table = mydev_pci_tbl,
};
As well as a request_fn with the following signature:
static void mydev_submit_req(struct request_queue *q);
Whenever I get IO requests, there is the expected pattern of "open, IO,
release", and everything works OK: I can mount the device and access the
filesystem.
However, if the device is physically removed during IO, I never seem to
get a "release", just "open, IO, hang". I believe (but I don't know),
that this is preventing del_gendisk() from completing, thus hanging the
cleanup of the driver, which is triggered by mydev_pci_remove_one() upon
the removal of the device.
I am ending all requests on the queue with __blk_end_request_all() once
an eject happens, but it still doesn't seem to cause a release.
What is the right way to terminate requests and delete the gendisk in
the case of physically vanished PCI devices (or even devices in
general)? I know I'd end up with a ruined transfer and corrupt data, but
that's better than a hung kernel, and if the user is going to rip out a
busy disk, those are the breaks.
Thanks in advance for any pointers to a solution, I have looked through
drivers/block, read LDD3 and asked at KernelNewbies but have been unable
to nail down my error. I'd be happy to provide more code, but I don't
want to spam with reams of code if it's not going to be helpful.
John Beard
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
reply other threads:[~2012-12-19 11:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=50D1A357.1030004@gmail.com \
--to=john.j.beard@gmail.com \
--cc=linux-newbie@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).