From: Jens Axboe <axboe@suse.de>
To: Steven Scholz <steven.scholz@imc-berlin.de>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Crash in ide_do_request() on card removal
Date: Tue, 2 Aug 2005 12:48:59 +0200 [thread overview]
Message-ID: <20050802104859.GG22569@suse.de> (raw)
In-Reply-To: <42EF439C.5000903@imc-berlin.de>
On Tue, Aug 02 2005, Steven Scholz wrote:
> Steven Scholz wrote:
>
> >Hi there,
> >
> >when surprisingly removing a CF ATA card (without unmounting before) I
> >sometimes get kernel crashes in ide_do_request() (linux-2.6.13-rc4 on ARM):
> >
> >cardmgr[194]: shutting down socket 0
> >cardmgr[194]: executing: './ide stop hda'
> >cardmgr[194]: + umount -v /dev/hda1
> >Assertion '(hwgroup->drive)' failed in
> >drivers/ide/ide-io.c:ide_do_request(1130)
> >Assertion '(drive)' failed in drivers/ide/ide-io.c:choose_drive(1035)
> >Unable to handle kernel NULL pointer dereference at virtual address
> >00000010
> >pgd = c0e34000
> >[00000010] *pgd=20eb0031, *pte=00000000, *ppte=00000000
> >Internal error: Oops: 17 [#1]
> >Modules linked in: ide_cs pcmcia at91_cf pcmcia_core
> >CPU: 0
> >PC is at ide_do_request+0x100/0x480
> >LR is at 0x1
> >pc : [<c00f9980>] lr : [<00000001>] Not tainted
> >...
> >
> >As the assertions show "drive" is NULL (due to the card removal?) and
> >thus the kernel crashes ...
> >
> >Upon card removal the pcmcia cardmgr tries to unmount the drive which
> >disapeared.
> >
> >("sometimes" above means that the rest of the time the kernel is not
> >dumping core, but the umount process hangs forever.)
>
> (I think) I found the reason for this behaviour:
>
> Upon card removal the functions
>
> ~ # cardctl eject
> ide_release(398)
> ide_unregister(585): index=0
> blk_unregister_queue(3603)
> elv_unregister_queue(549)
> ide_unregister(698)
> ide_detach(164)
>
> are called. Thus the request queue for the drive is discarded which is fair
> enough. But disk->queue would still point to a (now invalid)
> request_queue_t structure. Thus if I/O requests (e.g. "umount") are started
> _after_ the drive was removed bad things can happen! So I think we should
> explicitly remove the reference to that queue by doing
>
> void blk_unregister_queue(struct gendisk *disk)
> {
> request_queue_t *q = disk->queue;
>
> if (q && q->request_fn) {
> elv_unregister_queue(q);
> kobject_unregister(&q->kobj);
> + disk->queue = NULL;
> kobject_put(&disk->kobj);
> }
> }
That's not quite true, q is not invalid after this call. It will only be
invalid when it is freed (which doesn't happen from here but rather from
the blk_cleanup_queue() call when the reference count drops to 0).
This is still not perfect, but a lot better. Does it work for you?
--- linux-2.6.12/drivers/ide/ide-disk.c~ 2005-08-02 12:48:16.000000000 +0200
+++ linux-2.6.12/drivers/ide/ide-disk.c 2005-08-02 12:48:32.000000000 +0200
@@ -1054,6 +1054,7 @@
drive->driver_data = NULL;
drive->devfs_name[0] = '\0';
g->private_data = NULL;
+ g->disk = NULL;
put_disk(g);
kfree(idkp);
}
--
Jens Axboe
next prev parent reply other threads:[~2005-08-02 10:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-29 12:01 Crash in ide_do_request() on card removal Steven Scholz
2005-08-02 9:57 ` Steven Scholz
2005-08-02 10:48 ` Jens Axboe [this message]
2005-08-02 11:10 ` Steven Scholz
2005-08-02 11:13 ` Jens Axboe
2005-08-02 11:17 ` Steven Scholz
2005-08-02 11:28 ` Jens Axboe
2005-08-02 11:30 ` Steven Scholz
2005-08-02 11:33 ` Jens Axboe
2005-08-02 12:09 ` Steven Scholz
2005-08-02 12:26 ` Jens Axboe
2005-08-02 12:40 ` Steven Scholz
2005-08-02 12:54 ` Jens Axboe
2005-08-02 13:03 ` Steven Scholz
2005-08-02 13:06 ` Jens Axboe
2005-08-02 13:38 ` Steven Scholz
2005-08-02 13:45 ` Jens Axboe
2005-08-02 13:54 ` Steven Scholz
2005-08-02 14:11 ` Jens Axboe
2005-08-08 9:00 ` Steven Scholz
2005-08-02 13:28 ` Bartlomiej Zolnierkiewicz
2005-08-18 12:59 ` Steven Scholz
2006-01-31 14:28 ` Steven Scholz
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=20050802104859.GG22569@suse.de \
--to=axboe@suse.de \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steven.scholz@imc-berlin.de \
/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).