From: Steven Scholz <steven.scholz@imc-berlin.de>
To: Jens Axboe <axboe@suse.de>
Cc: linux-ide@vger.kernel.org
Subject: Re: Crash in ide_do_request() on card removal
Date: Tue, 02 Aug 2005 14:09:15 +0200 [thread overview]
Message-ID: <42EF626B.6090103@imc-berlin.de> (raw)
In-Reply-To: <20050802113328.GK22569@suse.de>
Jens Axboe wrote:
> On Tue, Aug 02 2005, Steven Scholz wrote:
>
>>Jens Axboe wrote:
>>
>>
>>>On Tue, Aug 02 2005, Steven Scholz wrote:
>>>
>>>
>>>>Jens Axboe wrote:
>>>>
>>>>
>>>>
>>>>>On Tue, Aug 02 2005, Steven Scholz wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Jens Axboe wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>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);
>>>>>>>}
>>>>>>
>>>>>>No.
>>>>>>drivers/ide/ide-disk.c: In function `ide_disk_release':
>>>>>>drivers/ide/ide-disk.c:1057: error: structure has no member named `disk'
>>>>>
>>>>>
>>>>>Eh, typo, should be g->queue of course :-)
>>>>>
>>>>>--- 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
>>>>>13:12:54.000000000 +0200
>>>>>@@ -1054,6 +1054,7 @@
>>>>> drive->driver_data = NULL;
>>>>> drive->devfs_name[0] = '\0';
>>>>> g->private_data = NULL;
>>>>>+ g->queue = NULL;
>>>>> put_disk(g);
>>>>> kfree(idkp);
>>>>>}
>>>>
>>>>No. That does not work:
>>>>
>>>>~ # umount /mnt/pcmcia/
>>>>generic_make_request(2859) q=c02d3040
>>>>__generic_unplug_device(1447) calling q->request_fn() @ c00f97ec
>>>>
>>>>do_ide_request(1281) HWIF=c01dee8c (0), HWGROUP=c089cea0 (1038681856),
>>>>drive=c01def1c (0, 0), queue=c02d3040 (00000000)
>>>>do_ide_request(1287) HWIF is not present anymore!!!
>>>>do_ide_request(1291) DRIVE is not present anymore. SKIPPING REQUEST!!!
>>>>
>>>>As you can see generic_make_request() still has the pointer to that queue!
>>>>It gets it with
>>>>
>>>> q = bdev_get_queue(bio->bi_bdev);
>>>>
>>>>So the pointer is still stored soemwhere else...
>>>
>>>
>>>Hmmm, perhaps just let ide end requests where the drive has been
>>>removed might be better.
>>
>>I don't understand what you mean.
>>
>>If requests are issued (e.g calling umount) after the drive is gone, then I
>>get either a kernel crash or umount hangs cause it waits in
>>__wait_on_buffer() ...
>
>
> No, those waiters will be woken up when ide does an end_request for
> requests coming in for a device which no longer exists.
But that would mean generating requests for devices, drives and hwifs that no
longer exists. But exactly there it will crash! In do_ide_request() and
ide_do_request().
ide_unregister() restores some old hwif structure. drive and queue are set to
NULL. When I wait "long enough" between "cardctl eject" and "umount" it looks
like this:
~ # cardctl eject
ide_release(398)
ide_unregister(585): index=0
ide_unregister(698) old HWIF restored!
hwif=c01dee8c (0), hwgroup=c0fac2a0, drive=00000000, queue=00000000
ide_detach(164)
cardmgr[253]: shutting down socket 0
cardmgr[253]: executing: './ide stop hda'
cardmgr[253]: executing: 'modprobe -r ide-cs'
exit_ide_cs(514)
~ # umount /mnt/pcmcia/
sys_umount(494)
generic_make_request(2859) q=c02d3040
__generic_unplug_device(1447) calling q->request_fn() @ c00f97e4
do_ide_request(1279) HWIF=c01dee8c (0), HWGROUP=c0fac2a0 (738987520),
drive=c01def1c (0, 0), queue=c02d3040 (00000000)
Assertion '(hwif->present)' failed in drivers/ide/ide-io.c:do_ide_request(1284)
Assertion '(drive->present)' failed in drivers/ide/ide-io.c:do_ide_request(1290)
ide_do_request(1133) hwgroup is busy!
ide_do_request(1135) hwif=01000406
The "738987520" above is hwgroup->busy! Obviously completly wrong. This seems to
be a hint that an invalid pointer is dereferenced! The pointer hwif=01000406
also does not look very healthy! drive=c01def1c is the result of
drive = choose_drive(hwgroup);
but can't be as it was set to NULL before.
If I don't wait "long enough" between "cardctl eject" and "umount" the kernel
crashes with:
~ # cardctl eject; umount /mnt/pcmcia
ide_release(398)
ide_unregister(585): index=0
ide_unregister(698) old HWIF restored!
hwif=c01dee8c (0), hwgroup=c0268080, drive=00000000, queue=00000000
ide_detach(164)
cardmgr[253]: shutting down socket 0
cardmgr[253]: executing: './ide stop hda'
sys_umount(494) retval=0
generic_make_request(2859) q=c02d3040
__generic_unplug_device(1447) calling q->request_fn() @ c00f97e4
do_ide_request(1279) HWIF=c01dee8c (0), HWGROUP=c0268080 (0), drive=c01def1c (0,
0), queue=c02d3040 (00000000)
Assertion '(hwif->present)' failed in drivers/ide/ide-io.c:do_ide_request(1284)
Assertion '(drive->present)' failed in drivers/ide/ide-io.c:do_ide_request(1290)
Assertion '(hwgroup->drive)' failed in drivers/ide/ide-io.c:ide_do_request(1124)
ide_do_request(1127) hwgroup->drive=00000000 !!!!!!!!!!!
Unable to handle kernel NULL pointer dereference at virtual address 00000010
...
Internal error: Oops: 17 [#1]
Modules linked in: ide_cs pcmcia at91_cf pcmcia_core
CPU: 0
PC is at ide_do_request+0xe0/0x4f4
It crashes in choose_drive()...
So how could you generate requests (and handle them sanely) for devices that
where removed?
If the drive would only had a hardware failure then probably a timeout would
occure and some error handling would take place.
But when the drive was officially unregistered then no more requests should be
generated! I think that's why generic_make_request() checks
q = bdev_get_queue(bio->bi_bdev);
if (!q) {
printk(KERN_ERR
"generic_make_request: Trying to access "
"nonexistent block-device %s (%Lu)\n",
bdevname(bio->bi_bdev, b),
(long long) bio->bi_sector);
(You probably noted that I am not too deep into the IDE/block devices buisness...)
--
Steven
next prev parent reply other threads:[~2005-08-02 12:09 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
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 [this message]
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=42EF626B.6090103@imc-berlin.de \
--to=steven.scholz@imc-berlin.de \
--cc=axboe@suse.de \
--cc=linux-ide@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).