From: Christoph Hellwig <hch@infradead.org>
To: Hannes Reinecke <hare@suse.de>
Cc: JiangJianJun <jiangjianjun3@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
lixiaokeng@huawei.com, hewenliang4@huawei.com,
yangkunlin7@huawei.com
Subject: Re: [RFC PATCH v3 00/19] scsi: scsi_error: Introduce new error handle mechanism
Date: Wed, 19 Mar 2025 23:05:51 -0700 [thread overview]
Message-ID: <Z9uwP4axlXOSWxQD@infradead.org> (raw)
In-Reply-To: <f35b2485-588b-40c4-a2e7-1bb65fb7a9fc@suse.de>
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.
next prev parent reply other threads:[~2025-03-20 6:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 1:29 [RFC PATCH v3 00/19] scsi: scsi_error: Introduce new error handle mechanism JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 01/19] scsi: scsi_error: Define framework for LUN/target based error handle JiangJianJun
2025-03-14 1:49 ` Bart Van Assche
2025-03-14 1:29 ` [RFC PATCH v3 02/19] scsi: scsi_error: Move complete variable eh_action from shost to sdevice JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 03/19] scsi: scsi_error: Check if to do reset in scsi_try_xxx_reset JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 04/19] scsi: scsi_error: Add helper scsi_eh_sdev_stu to do START_UNIT JiangJianJun
2025-04-24 9:27 ` Diangang Li
2025-03-14 1:29 ` [RFC PATCH v3 05/19] scsi: scsi_error: Add helper scsi_eh_sdev_reset to do lun reset JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 06/19] scsi: scsi_error: Add flags to mark error handle steps has done JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 07/19] scsi: scsi_error: Add helper to handle scsi device's error command list JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 08/19] scsi: scsi_error: Add a general LUN based error handler JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 09/19] scsi: core: increase/decrease target_busy without check can_queue JiangJianJun
2025-03-14 1:35 ` Bart Van Assche
2025-03-14 1:29 ` [RFC PATCH v3 10/19] scsi: scsi_error: Add helper to handle scsi target's error command list JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 11/19] scsi: scsi_error: Add a general target based error handler JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 12/19] scsi: scsi_debug: Add param to control LUN bassed " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 13/19] scsi: scsi_debug: Add param to control target based error handle JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 14/19] scsi: mpt3sas: Add param to control LUN " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 15/19] scsi: mpt3sas: Add param to control target " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 16/19] scsi: smartpqi: Add param to control LUN " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 17/19] scsi: megaraid_sas: Add param to control target " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 18/19] scsi: virtio_scsi: Add param to control LUN " JiangJianJun
2025-03-14 1:29 ` [RFC PATCH v3 19/19] scsi: iscsi_tcp: " JiangJianJun
2025-03-14 9:01 ` [RFC PATCH v3 00/19] scsi: scsi_error: Introduce new error handle mechanism Hannes Reinecke
2025-03-14 15:55 ` Bart Van Assche
2025-04-24 9:44 ` Diangang Li
2025-03-20 6:05 ` Christoph Hellwig [this message]
2025-03-31 3:10 ` 答复: " Jiangjianjun
2025-03-31 7:50 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9uwP4axlXOSWxQD@infradead.org \
--to=hch@infradead.org \
--cc=hare@suse.de \
--cc=hewenliang4@huawei.com \
--cc=jejb@linux.ibm.com \
--cc=jiangjianjun3@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lixiaokeng@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=yangkunlin7@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox