linux-kernel - RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Jun 2007 16:39:28 -0000
From:	"Miller, Mike (OS Dev)" <Mike.Miller@...com>
To:	<vgoyal@...ibm.com>, "Neil Horman" <nhorman@...driver.com>
Cc:	<linux-kernel@...r.kernel.org>,
	"ISS StorageDev" <iss_storagedev@...com>,
	<akpm@...ux-foundation.org>,
	"SCSI Mailing List" <linux-scsi@...r.kernel.org>
Subject: RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot

Vivek wrote: 

> 
> I think this is not the right usage of reset_devices 
> parameter. This parameter instructs the driver to reset the 
> device before going ahead with rest of the initialization 
> before as underlying device might not be in a sane state. 
> kexec/kdump is one of the usages and this can also be useful 
> in the case of BIOS not doing its job.
> 
> When I had proposed crash_boot parameter for kexec/kdump 
> purposes, that time andrew had suggested that he is afraid 
> that driver authors will use this parameter to solve all kind 
> of problems. 
> 
> I think we should stick to the theme of the parameter and 
> implement the reset routine for cciss driver instead of 
> simply returning back. Consider the case of hypothetical 
> scenario where somebody booted the kernel with reset_device 
> parameter (because of unreliable bios) and if there is a 
> problem on kernel side that after it issues the command it 
> lost track of that (because of kernel bug) then driver will 
> never catch that bug as upon receiving the response it will 
> simply ignore that.
> 
> Mike, you know most about this device. Can you please help 
> out with implementing a reset routing for it?
> 
Vivek
I think I finally have an idea that will work. (`bout time!) We actually
have 2 different issues. One is that there may outstanding commands on
the controller when the kdump kernel initializes. Our SAS controllers
support the reset message defined in the open CISS spec which will
(hopefully) resolve this issue. The second problem is that I cannot
allocate my MSI-X vectors because I couldn't free the vectors then
disable MSI. So the cciss driver would most likely panic at that time.
My idea for this is to put the card into INTx mode rather than MSI or
MSI-X. That should the 2nd issue.
I haven't tested the 64xx series to see if they support the reset
message. I should to write the code today, maybe test by tomorrow and
then send something upstream.

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