On Wed, May 4, 2011 at 12:07 PM, Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote:
> Got one at the very end of burning session (haven't tried to reproduce yet).
> Apparently happened when cdrecord tried to open the door.
>
> __lock_acquire
> lock_acquire
> _raw_spin_lock_irq
> blk_get_request
Hmm. That would be the
spin_lock_irq(q->queue_lock);
in there, I'm not seeing any other spinlock.
> scsi_execute
> scsi_set_medium_removal
> sr_lock_door
> cdrom_release
> sr_block_release
> __blk_dev_put
> blkdev_put
> blkdev_close
> fput
> filp_close
> sys_close
>
> comm: cdrecord
> RAX was small number like 0x46(?)
> RBX 6b6b6b6b6b6b6b83
> RDI 6b6b6b6b6b6b6b83
And that implies that 'q' has been free'd before it's used, and you
have SLUB-debugging turned on.
> This model is USB device.
Hmm. It looks a bit odd that cdrom_release() does the ->release call
before it does the ->tray_move thing, but I don't think that's it.
Jens/James: What's the sequence to blk_cleanup_queue() for a SCSI
CD-ROM? It really does look like we're releasing the queue before
we're done with it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
