linux-kernel - Re: Kernel oops in sym_int

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4FA29E9E.8090401@suse.de>
Date:	Thu, 03 May 2012 17:05:02 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Stefan Bader <stefan.bader@...onical.com>
Cc:	linux-scsi@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: Kernel oops in sym_int_sir

On 05/02/2012 04:25 PM, Stefan Bader wrote:
> 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 <matthew@....cx>
> 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?
> 
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
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/