2.6.39-rc6: cdrecord oops

2.6.39-rc6: cdrecord oops

[Alexey Dobriyan]

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
	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

	scsi 8:0:0:0: CD-ROM            Optiarc  DVD RW AD-7700S 1.03 PQ: 0 ANSI: 0
	sr0: scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray

This model is USB device.

Re: 2.6.39-rc6: cdrecord oops

[Linus Torvalds]

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.

                      Linus
--
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

Re: 2.6.39-rc6: cdrecord oops

[Alexey Dobriyan]

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