Kernel oops in sym_int_sir

DISCUSSION Stefan Bader 2 participants 2 messages May 2, 2012 – May 3, 2012 SCSI

Share & tools

Stefan Bader

author

2012-05-02 14:25 UTC #0 lore raw

While looking at a bug report [1] I found that the immediate cause of the crash was in that specific case the reference cp->cmd for a printk:

/*
* The device didn't switch to MSG IN phase after
* having reselected the initiator.
*/
case SIR_RESEL_NO_MSG_IN:

         scmd_printk(KERN_WARNING, cp->cmd,
                         "No MSG IN phase after reselection\n");
         goto out_stuck;

Unfortunately cp (that is returned by sym_ccb_from_dsa()) is NULL. This probably is as old as 2.6.24 when this patch added the scmd_printk:

commit 3fb364e089e05c35ead55a08d56d3004193681f6
Author: Matthew Wilcox <[email protected]>
Date: Fri Oct 5 15:55:10 2007 -0400

[SCSI] sym53c8xx: Use scmd_printk where appropriate

A quick research looks like it might be other cases where this happened[2]. Maybe more often (or solely?) when running in a VM (KVM). I even found some post that looks like it tries to fix just this problem[3].

However without more knowledge about that driver it could also be a problem in the hardware emulation so that normally cp == NULL should never happen. Or it might be that the emulation is just running sufficiently "different" to cause races to happen which never would be observed on real hardware.

Would [3] still make sense?

Thanks,
Stefan

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992328
[2] http://www.mail-archive.com/[email protected]/msg08927.html
[3] https://lkml.org/lkml/2010/11/18/495

Hannes Reinecke

2012-05-03 15:05 UTC #1 lore raw

Quoted 25 lines · Stefan Bader

While looking at a bug report [1] I found that the immediate cause of the crash was in that specific case the reference cp->cmd for a printk:
/*
* The device didn't switch to MSG IN phase after
* having reselected the initiator.
*/
case SIR_RESEL_NO_MSG_IN:
         scmd_printk(KERN_WARNING, cp->cmd,
                         "No MSG IN phase after reselection\n");
         goto out_stuck;
Unfortunately cp (that is returned by sym_ccb_from_dsa()) is NULL. This probably is as old as 2.6.24 when this patch added the scmd_printk:
commit 3fb364e089e05c35ead55a08d56d3004193681f6
Author: Matthew Wilcox <[email protected]>
Date: Fri Oct 5 15:55:10 2007 -0400
[SCSI] sym53c8xx: Use scmd_printk where appropriate
A quick research looks like it might be other cases where this happened[2]. Maybe more often (or solely?) when running in a VM (KVM). I even found some post that looks like it tries to fix just this problem[3].

Quoted 7 lines

However without more knowledge about that driver it could also be a problem in the hardware emulation so that normally cp == NULL should never happen. Or it might be that the emulation is just running sufficiently "different" to cause races to happen which never would be observed on real hardware.
Would [3] still make sense?

cp->cmd == NULL would point to a race with SCSI command completion, basically the same issue USB is facing right now.
So yes, it can happen (as you've seen), so I would got for [3]. And if only to avoid the Oops and figure out what _really_ went wrong here.

Cheers,

Hannes

Signature · 4 lines

Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)