linux-kernel - RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for console device

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <B70A50D07063384EB9BCE3330D18414F0327EBC5@nonameb.ptu.promise.com>
Date:	Mon, 2 Apr 2007 11:14:56 -0700
From:	"Ed Lin" <ed.lin@...mise.com>
To:	"James Bottomley" <James.Bottomley@...elEye.com>
Cc:	"linux-scsi" <linux-scsi@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"jeff" <jeff@...zik.org>,
	"Promise_Linux" <Promise_Linux@...mise.com>
Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for console device



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@...elEye.com] 
> Sent: Saturday, March 31, 2007 11:46 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: Re: [PATCH 3/4] [SCSI]stex: fix reset recovery for 
> console device
> 
> 
> On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote:
> > After reset completed, the scsi error handler sends out START_STOP
> > and TEST_UNIT_READY to the device. For 'normal' devices these
> > commands will be handled by firmware. However, because the RAID
> > console only interfaces to scsi mid layer, the firmware 
> will not process
> > these commands for it. This will make the console to be 
> offlined right
> > after reset. Add the handling in driver to fix this problem.
> 
> I don't see how this explanation can be correct.  The error 
> handler only
> sends a START_STOP command if sdev->allow_restart is one, 
> which you have
> to set in the slave_configure routines (which stex doesn't).  
> If you're
> seeing a START_STOP in the eh path, there's something else wrong.
> TEST_UNIT_READY, certainly ... it's part of a restart check.
> 

I just saw the routine name scsi_eh_try_stu, and didn't notice the
allow_restart (partly because I thought it was not harmful...).
But the TEST_UNIT_READY must stay.
-
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/