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. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
