From: John Garry <john.g.garry@oracle.com>
To: Jason Yan <yanaijie@huawei.com>,
yangxingui <yangxingui@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org,
hare@suse.com, hch@lst.de
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxarm@huawei.com, prime.zeng@hisilicon.com,
kangfenglong@huawei.com
Subject: Re: [PATCH V2] scsi: libsas: Directly kick-off EH when ATA device fell off
Date: Wed, 21 Dec 2022 09:40:42 +0000 [thread overview]
Message-ID: <ad3804e6-37f8-aa43-19f6-2ef30c0ccca1@oracle.com> (raw)
In-Reply-To: <fe4ed9f7-4032-f1e2-d6c0-6a7bc99ec3b1@huawei.com>
On 20/12/2022 09:49, Jason Yan wrote:
>
> Itering tagset in libsas is odd.
Itering with block layer APIs is just a method to deal with each active
IO. However, libsas should not be aborting IO directly. It may provide
helper routines, but the LLDD should be dealing with aborting IO.
>
> The question is, shall we implement the aborting from the driver side,
> such as what sas_ata_device_link_abort() do. Or shall we implement the
> aborting from the upper side(scsi middle layer or block layer), such as
> trigger block layer time out handler immediately after we found device
> is gone?
As mentioned, aborting each IO should be the job of the LLDD. However,
just making the IO timeout will lead to EH kicking in earlier, and EH
will do usual per-IO handling in sas_eh_handle_sas_errors() that would
happen when the IO timesout normally - so what are we really gaining
here? Just EH kicks in earlier. But we still have the problem of all
other per-host IO being blocked while EH is active.
Thanks,
John
next prev parent reply other threads:[~2022-12-21 9:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 10:03 [PATCH V2] scsi: libsas: Directly kick-off EH when ATA device fell off Xingui Yang
2022-12-19 2:19 ` Jason Yan
2022-12-19 9:23 ` John Garry
2022-12-19 12:59 ` yangxingui
2022-12-19 14:53 ` John Garry
2022-12-20 2:34 ` yangxingui
2022-12-20 9:49 ` Jason Yan
2022-12-21 9:40 ` John Garry [this message]
2022-12-21 10:29 ` Jason Yan
2022-12-21 9:28 ` yangxingui
2022-12-19 15:28 ` Jason Yan
2022-12-19 15:55 ` John Garry
2022-12-19 23:00 ` Damien Le Moal
2022-12-20 8:43 ` John Garry
2022-12-19 22:59 ` Damien Le Moal
2022-12-20 2:39 ` Jason Yan
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=ad3804e6-37f8-aa43-19f6-2ef30c0ccca1@oracle.com \
--to=john.g.garry@oracle.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=kangfenglong@huawei.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=prime.zeng@hisilicon.com \
--cc=yanaijie@huawei.com \
--cc=yangxingui@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.