linux-kernel - Re: [PATCH 00/14] scsi: scsi_error: Introduce new error handle mechanism

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

Message-ID: <17230842-0a7a-403e-abc7-a15e3aa5d424@suse.de>
Date: Wed, 20 Aug 2025 14:36:10 +0200
From: Hannes Reinecke <hare@...e.de>
To: JiangJianJun <jiangjianjun3@...wei.com>,
 James.Bottomley@...senPartnership.com, martin.petersen@...cle.com,
 linux-scsi@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, bvanassche@....org,
 michael.christie@...cle.com, hch@...radead.org, haowenchao22@...il.com,
 john.g.garry@...cle.com, hewenliang4@...wei.com, yangyun50@...wei.com,
 wuyifeng10@...wei.com, wubo40@...wei.com, yangxingui@...artners.com
Subject: Re: [PATCH 00/14] scsi: scsi_error: Introduce new error handle
 mechanism

On 8/16/25 13:24, JiangJianJun wrote:
> It's unbearable for systems with large scale scsi devices share HBAs to
> block all devices' IOs when handle error commands, we need a new error
> handle mechanism to address this issue.
> 
> I consulted about this issue a year ago, the discuss link can be found in
> refenence. Hannes replied about why we have to block the SCSI host
> then perform error recovery kindly. I think it's unnecessary to block
> SCSI host for all drivers and can try a small level recovery(LUN based for
> example) first to avoid block the SCSI host.
> 
> The new error handle mechanism introduced in this patchset has been
> developed and tested with out self developed hardware since one year
> ago, now we want this mechanism can be used by more drivers.
> 
> Drivers can decide if using the new error handle mechanism and how to
> handle error commands when scsi_device are scanned,the new mechanism
> makes SCSI error handle more flexible.
> 
Hmm. Yes, and no.

I fully agree that SCSI EH is in need of reworking. But adding
another layer of complexity on top of the existing one ... not sure.

Additionally: TARGET RESET TMF is dead, and has been removed from SAM
since several years. It really is not worthwhile implementing.

Can't we take a simple step, and just try to have a non-blocking version
of device reset?
I think that should cover quite some issues already.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@...e.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich