From: John Garry <john.g.garry@oracle.com>
To: JiangJianJun <jiangjianjun3@huawei.com>,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org
Cc: bvanassche@acm.org, hewenliang4@huawei.com, yangyun50@huawei.com,
wuyifeng10@huawei.com
Subject: Re: scsi: scsi_debug: make timeout faults by set delay to maximum value
Date: Sat, 8 Nov 2025 09:38:43 +0000 [thread overview]
Message-ID: <da25e95c-8895-4a0b-ad7d-9f88f58a91e0@oracle.com> (raw)
In-Reply-To: <20251108082959.1831-1-jiangjianjun3@huawei.com>
On 08/11/2025 08:29, JiangJianJun wrote:
>> When we get discard the command, we get a timeout, and the scsi error
>
>> handling kicks in eventually. The first thing that the scsi error
>
>> handler tries to do is abort the command. All that the scsi_debug abort
>
>> handler can do is ensure that we no longer have a reference to the
>
>> scsi_command, which may mean cancelling any pending completion (if
>
>> possible). Is your problem that sometimes the abort handler may fail,
>
>> and we have to escalate?
>
> What I mean is, in fault injection, we need to set a timeout, and then we expect a successful aborting.
I don't think that you can always expect successful aborting.
As an example of this, if the completion callback for a command is
running at the same time as the abort handler, then we cannot
successfully abort.
> On the other hand, we can make a failed aborting by injecting-fault.
>
> Before your modifications, the above objectives were achievable. The purpose of my current modification is also to restore the previous functionality.
Which modifications are you specifically referring to?
next prev parent reply other threads:[~2025-11-08 9:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 11:55 [PATCH 0/4] scsi_debug improvements John Garry
2025-02-24 11:55 ` [PATCH 1/4] scsi: scsi_debug: Remove sdebug_device_access_info John Garry
2025-02-24 18:04 ` Bart Van Assche
2025-02-24 11:55 ` [PATCH 2/4] scsi: scsi_debug: Remove a reference to in_use_bm John Garry
2025-02-24 11:55 ` [PATCH 3/4] scsi: scsi_debug: Simplify command handling John Garry
2025-02-24 11:55 ` [PATCH 4/4] scsi: scsi_debug: Do not sleep in atomic sections John Garry
2025-11-05 11:57 ` [PATCH] scsi: scsi_debug: make timeout faults by set delay to maximum value JiangJianJun
2025-11-05 12:00 ` JiangJianJun
2025-11-05 12:01 ` JiangJianJun
2025-11-05 11:54 ` John Garry
2025-11-06 12:03 ` JiangJianJun
2025-11-07 10:05 ` John Garry
2025-11-08 8:29 ` JiangJianJun
2025-11-08 9:38 ` John Garry [this message]
2025-11-11 10:59 ` JiangJianJun
2025-11-12 8:53 ` John Garry
2025-11-12 13:38 ` JiangJianJun
2025-11-12 16:02 ` John Garry
2025-11-13 11:22 ` JiangJianJun
2025-11-13 11:48 ` John Garry
2025-02-25 1:57 ` [PATCH 0/4] scsi_debug improvements Martin K. Petersen
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=da25e95c-8895-4a0b-ad7d-9f88f58a91e0@oracle.com \
--to=john.g.garry@oracle.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bvanassche@acm.org \
--cc=hewenliang4@huawei.com \
--cc=jiangjianjun3@huawei.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=wuyifeng10@huawei.com \
--cc=yangyun50@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