linux-kernel - 答复: [RFC PATCH v3 00/19] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <9740056c3b1b4da796d86e67cba4c292@huawei.com>
Date: Mon, 31 Mar 2025 03:10:03 +0000
From: Jiangjianjun <jiangjianjun3@...wei.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Jiangjianjun <jiangjianjun3@...wei.com>, "jejb@...ux.ibm.com"
	<jejb@...ux.ibm.com>, "martin.petersen@...cle.com"
	<martin.petersen@...cle.com>, "linux-scsi@...r.kernel.org"
	<linux-scsi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, lixiaokeng <lixiaokeng@...wei.com>,
	"hewenliang (C)" <hewenliang4@...wei.com>, "Yangkunlin(Poincare)"
	<yangkunlin7@...wei.com>
Subject: 答复: [RFC PATCH v3 00/19] scsi: scsi_error: Introduce new error handle mechanism

Sorry for late message! I'm working on fixing and testing these issues before re-emailing.

-----邮件原件-----
发件人: Christoph Hellwig <hch@...radead.org> 
发送时间: 2025年3月20日 14:06
收件人: Hannes Reinecke <hare@...e.de>
抄送: Jiangjianjun <jiangjianjun3@...wei.com>; jejb@...ux.ibm.com; martin.petersen@...cle.com; linux-scsi@...r.kernel.org; linux-kernel@...r.kernel.org; lixiaokeng <lixiaokeng@...wei.com>; hewenliang (C) <hewenliang4@...wei.com>; Yangkunlin(Poincare) <yangkunlin7@...wei.com>
主题: Re: [RFC PATCH v3 00/19] scsi: scsi_error: Introduce new error handle mechanism

On Fri, Mar 14, 2025 at 10:01:40AM +0100, Hannes Reinecke wrote:
> 3. The current EH framework is designed around 'struct scsi_cmnd'.
> Which means that the command _initiating_ the error handling can only 
> be returned once the _entire_ error handling (with all
> escalations) is finished. And more often than not, the application is 
> waiting on that command to be completed before the next I/O is sent. 
> And that really limits the effectiveness of any improved error 
> handler; the application ultimatively has to wait for a host reset 
> before it can contine.

And someone needs to get your old series to fix that merged before we even start talking about any major EH change.