Re: 2.6.39-rc6: cdrecord oops

[Alexey Dobriyan <adobriyan@gmail.com>]

On Wed, May 04, 2011 at 12:32:50PM -0700, Linus Torvalds wrote:
> On Wed, May 4, 2011 at 12:07 PM, Alexey Dobriyan <adobriyan@gmail.com> 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.

Second time, burning finished to the end successfully.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html