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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Jun 2007 18:16:03 -0000
From:	"Miller, Mike (OS Dev)" <Mike.Miller@...com>
To:	"Neil Horman" <nhorman@...driver.com>,
	<linux-kernel@...r.kernel.org>
Cc:	"ISS StorageDev" <iss_storagedev@...com>,
	<akpm@...ux-foundation.org>
Subject: RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot

 

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@...driver.com] 
> Sent: Thursday, June 14, 2007 10:31 AM
> To: linux-kernel@...r.kernel.org
> Cc: Miller, Mike (OS Dev); ISS StorageDev; 
> akpm@...ux-foundation.org; nhorman@...driver.com
> Subject: [PATCH] cciss: force ignore of responses to unsent 
> scsi commands after kexec reboot
> 
> Hey -
> 	cciss hardware currently can continue to send responses 
> to scsi commands after the host system has undergone a kexec 
> reboot.  The way the drier is currently written, reception of 
> these commands results in a BUG halt, since it can't match 
> the response to any issued command since the boot.  This 
> patch corrects that by using the kexec reset_devices command 
> line paramter to force ignore any commands that it cant correlate.
> 
> Regards
> Neil
> 
> Signed-off-by: Neil Horman <nhorman@...driver.com>
> 
> 
>  cciss.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> 
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c 
> index 5acc6c4..ec1c1d2 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -2131,6 +2131,14 @@ static int add_sendcmd_reject(__u8 
> cmd, int ctlr, unsigned long complete)
>  		       ctlr, complete);
>  		/* not much we can do. */
>  #ifdef CONFIG_CISS_SCSI_TAPE
> +		/* We might get notification of completion of commands
> +		 * which we never issued in this kernel if this boot is
> +		 * taking place after previous kernel's crash. Simply
> +		 * ignore the commands in this case.
> +		 */
> +		if (reset_devices)
> +			return 0;
> +
>  		return 1;
>  	}
>  
I don't understand how this will help. We need to reset the controller
which reset_devices cannot do alone. I just haven't have the time to
implement the fix yet.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ