All of lore.kernel.org
 help / color / mirror / Atom feed
From: "haowenchao (C)" <haowenchao2@huawei.com>
To: John Garry <john.g.garry@oracle.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Douglas Gilbert <dgilbert@interlog.com>,
	<linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <linfeilong@huawei.com>, <louhongxiang@huawei.com>
Subject: Re: [PATCH 0/5]scsi:scsi_debug: Add error injection for single device
Date: Fri, 24 Mar 2023 11:42:09 +0800	[thread overview]
Message-ID: <0a6fc4bd-82a1-3200-3061-4634531b5a63@huawei.com> (raw)
In-Reply-To: <750a4b24-6122-6faa-fed4-25e3167ea376@oracle.com>

On 2023/3/24 0:25, John Garry wrote:
> On 23/03/2023 13:13, haowenchao (C) wrote:
>> On 2023/3/23 20:40, John Garry wrote:
>>> On 23/03/2023 11:55, Wenchao Hao wrote:
>>>> The original error injection mechanism was based on scsi_host which
>>>> could not inject fault for a single SCSI device.
>>>>
>>>> This patchset provides the ability to inject errors for a single
>>>> SCSI device. Now we supports inject timeout errors, queuecommand
>>>> errors, and hostbyte, driverbyte, statusbyte, and sense data for
>>>> specific SCSI Command.
>>>
>>> There is already a basic mechanism to generate errors - like timeouts - on "nth" command. Can you say why you want this new interface? What special scenarios are you trying to test/validate (which could not be achieved based on the current mechanism)?
>>>
>>
>> I am testing a new error handle policy which is based on single scsi_device
>> without set host to RECOVERY. So I need a method to generate errors for
>> single SCSI devices.
>>
>> While we can not generate errors for single device with current mechanism
>> because it is designed for host-wide error generation.
>>
>>> With this series we would have 2x methods to inject errors, which is less than ideal, and they seem to possibly conflict as well, e.g. I set timeout for nth command via current interface and then use the new interface to set timeout for some other cadence. What behavior to expect ...?
>>
>> I did not take this issue in consideration. I now assume the users would
>> not use these 2 methods at same time.
>>
>> What's more, I don not know where to write the usage of this newly added
>> interface, maybe we can explain these in doc?
> 
> sysfs entries are described in Documentation/ABI, but please don't add elaborate programming interfaces in sysfs files (like in these patches) - a sysfs file should be just for reading or writing a single value
> 

If sysfs is not recommended, what about proc?

>>
>>>
>>> I'm not saying that I am a huge fan of the current inject mechanism, but at the very least you need to provide more justification for this series.
>>>>>
>>>> The first patch add an sysfs interface to add and inquiry single
>>>> device's error injection info; the second patch defined how to remove
>>>> an injection which has been added. The following 3 patches use the
>>>> injection info and generate the related error type.
>>>>
>>>> Wenchao Hao (5):
>>>>    scsi:scsi_debug: Add sysfs interface to manage scsi devices' error
>>>>      injection
>>>>    scsi:scsi_debug: Define grammar to remove added error injection
>>>>    scsi:scsi_debug: timeout command if the error is injected
>>>>    scsi:scsi_debug: Return failed value if the error is injected
>>>>    scsi:scsi_debug: set command's result and sense data if the error is
>>>>      injected
>>>>
>>>>   drivers/scsi/scsi_debug.c | 296 ++++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 296 insertions(+)
>>>>
>>>
>>>
>>
> 


  parent reply	other threads:[~2023-03-24  3:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 11:55 [PATCH 0/5]scsi:scsi_debug: Add error injection for single device Wenchao Hao
2023-03-23 11:55 ` [PATCH 1/5] scsi:scsi_debug: Add sysfs interface to manage scsi devices' error injection Wenchao Hao
2023-03-23 11:55 ` [PATCH 2/5] scsi:scsi_debug: Define grammar to remove added " Wenchao Hao
2023-03-23 11:55 ` [PATCH 3/5] scsi:scsi_debug: timeout command if the error is injected Wenchao Hao
2023-03-23 11:56 ` [PATCH 4/5] scsi:scsi_debug: Return failed value " Wenchao Hao
2023-03-23 11:56 ` [PATCH 5/5] scsi:scsi_debug: set command's result and sense data " Wenchao Hao
2023-03-23 12:40 ` [PATCH 0/5]scsi:scsi_debug: Add error injection for single device John Garry
2023-03-23 13:13   ` haowenchao (C)
2023-03-23 16:25     ` John Garry
2023-03-23 17:24       ` Douglas Gilbert
2023-03-24  3:42         ` haowenchao (C)
2023-03-24 17:31           ` Douglas Gilbert
2023-03-25  3:23             ` haowenchao (C)
2023-03-24  3:42       ` haowenchao (C) [this message]
2023-03-24 16:01         ` Bart Van Assche

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=0a6fc4bd-82a1-3200-3061-4634531b5a63@huawei.com \
    --to=haowenchao2@huawei.com \
    --cc=dgilbert@interlog.com \
    --cc=jejb@linux.ibm.com \
    --cc=john.g.garry@oracle.com \
    --cc=linfeilong@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=louhongxiang@huawei.com \
    --cc=martin.petersen@oracle.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.