Message ID | 20221109155950.3536976-1-haowenchao@huawei.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp101106wru; Tue, 8 Nov 2022 18:46:58 -0800 (PST) X-Google-Smtp-Source: AMsMyM6dlZ2wbfsLtDb63DpX0p57IYRpJ1aMxdC1irq0qkWojq/8wWyaqJv4SXdiAwRcfF5D+Mgc X-Received: by 2002:a17:907:7f16:b0:7ad:bf79:f9b6 with SMTP id qf22-20020a1709077f1600b007adbf79f9b6mr51663016ejc.61.1667962018191; Tue, 08 Nov 2022 18:46:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667962018; cv=none; d=google.com; s=arc-20160816; b=myivDmYEBG1WdReZuUUS/3dZSPGNd6AuUPpNHBeEa3gowFokWcadx7fwToKGYsZuln +g4zzzi7tIv8WksdFIMm2jvJ/KIhZmu8Wek7ijW1BoDHX21KHvHsTNgz2g49RchPk9k1 ARlTZU8XTrFb24V4pTQuE+XEuWgkwrp1phwcWs2PeX6/1FjRPRHpNdjf5T6Gp/GrSHiS lP73pyFoszETBJ77Szm5zuQQ8rysj/SZguunonq5+MVghUI8kZbkMdtB2DPlxPoypAdC vdjp3Jsjkw2tcJCqo3N+vnWtXbhbcFoIawr05wwrqnsPnzgk/p+a4SkcEmy8ZnOGjzd3 Rwpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=a/TdFrUlDzOJrTvpCV3e0MZuPqucZsdZT/XQTfeBaBA=; b=HCaFV2cY+vFkOkBWikfT6UZ9oKM8py+rupVzcThuglz9laZ3/ogcKBLQrVhQH+UQKJ 4UlcFp8WtYCV61X3M2unqecl3BRgMAfbAX0R7m6EYP2g4AWvfvX2aPkJ0fYHjC0aOKCV A3sU1HKzR26U34bwkhnCXdfZHG4/2t/iPHCGJsNYWpzGThFTPXYYeQRlKdkDWAN0Ep98 IxyS/munA5dc1zPvtkEOf9PaHTLLStWv39uRKr5PR0gVesl2NfBpo+buQvbD9xdMOASu VB2ogXDR352zFdxtgr31FhTqrbIYFY0AIPtsNjJGjxzMSrRhB0qwJTEOgA0fbCLnQmrf orzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gv18-20020a170906f11200b007803e371aedsi10294608ejb.161.2022.11.08.18.46.32; Tue, 08 Nov 2022 18:46:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229591AbiKICnw (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Tue, 8 Nov 2022 21:43:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229492AbiKICnu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Nov 2022 21:43:50 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 196E5FD14; Tue, 8 Nov 2022 18:43:49 -0800 (PST) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4N6Thl1zc8zpWDb; Wed, 9 Nov 2022 10:40:07 +0800 (CST) Received: from dggpemm500017.china.huawei.com (7.185.36.178) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 9 Nov 2022 10:43:47 +0800 Received: from build.huawei.com (10.175.101.6) by dggpemm500017.china.huawei.com (7.185.36.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 9 Nov 2022 10:43:47 +0800 From: Wenchao Hao <haowenchao@huawei.com> To: "James E . J . Bottomley" <jejb@linux.ibm.com>, "Martin K . Petersen" <martin.petersen@oracle.com>, Doug Gilbert <dgilbert@interlog.com> CC: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Wenchao Hao <haowenchao@huawei.com> Subject: [RFC PATCH 0/5] scsi:scsi_debug:Add error injection for single lun Date: Wed, 9 Nov 2022 10:59:45 -0500 Message-ID: <20221109155950.3536976-1-haowenchao@huawei.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.101.6] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500017.china.huawei.com (7.185.36.178) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_12_24, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748984941164369525?= X-GMAIL-MSGID: =?utf-8?q?1748984941164369525?= |
Series |
scsi:scsi_debug:Add error injection for single lun
|
|
Message
Wenchao Hao
Nov. 9, 2022, 3:59 p.m. UTC
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 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 manager single devices' error inject scsi:scsi_debug: Add interface to remove injection which has been added scsi:scsi_debug: make command timeout if timeout error is injected scsi:scsi_debug: Return failed value for specific command's queuecommand scsi:scsi_debug: fail specific scsi command with result and sense data drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 295 insertions(+)
Comments
On 2022-11-09 10:59, 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 > > 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 manager single devices' error inject > scsi:scsi_debug: Add interface to remove injection which has been added > scsi:scsi_debug: make command timeout if timeout error is injected > scsi:scsi_debug: Return failed value for specific command's queuecommand > scsi:scsi_debug: fail specific scsi command with result and sense data > > drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 295 insertions(+) Hi, This patchset seems to assume all scsi_debug devices will be disk (-like) SCSI devices. That leaves out other device types: tapes, enclosures, WLUNs, etc. Have you considered putting these device specific additions under: /sys/class/scsi_device/<hctl>/device/error_inject/ instead of /sys/block/sdb/device/error_inject/ ? Doug Gilbert
On 11/14/22 06:48, Douglas Gilbert wrote: > On 2022-11-09 10:59, 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 >> >> 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 manager single devices' error inject >> scsi:scsi_debug: Add interface to remove injection which has been added >> scsi:scsi_debug: make command timeout if timeout error is injected >> scsi:scsi_debug: Return failed value for specific command's queuecommand >> scsi:scsi_debug: fail specific scsi command with result and sense data >> >> drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 295 insertions(+) > > Hi, > This patchset seems to assume all scsi_debug devices will be disk (-like) SCSI > devices. That leaves out other device types: tapes, enclosures, WLUNs, etc. > > Have you considered putting these device specific additions under: > /sys/class/scsi_device/<hctl>/device/error_inject/ > instead of > /sys/block/sdb/device/error_inject/ But these are the same, no ? At least on my Fedora box, I see: /sys/block/sdp/device/ being /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 and /sys/class/scsi_device/19:0:0:0/device being /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 > > ? > > Doug Gilbert > > >
On 2022-11-13 19:30, Damien Le Moal wrote: > On 11/14/22 06:48, Douglas Gilbert wrote: >> On 2022-11-09 10:59, 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 >>> >>> 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 manager single devices' error inject >>> scsi:scsi_debug: Add interface to remove injection which has been added >>> scsi:scsi_debug: make command timeout if timeout error is injected >>> scsi:scsi_debug: Return failed value for specific command's queuecommand >>> scsi:scsi_debug: fail specific scsi command with result and sense data >>> >>> drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 295 insertions(+) >> >> Hi, >> This patchset seems to assume all scsi_debug devices will be disk (-like) SCSI >> devices. That leaves out other device types: tapes, enclosures, WLUNs, etc. >> >> Have you considered putting these device specific additions under: >> /sys/class/scsi_device/<hctl>/device/error_inject/ >> instead of >> /sys/block/sdb/device/error_inject/ > > But these are the same, no ? > At least on my Fedora box, I see: > > /sys/block/sdp/device/ being > /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 > > and /sys/class/scsi_device/19:0:0:0/device being > /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 Well the patch descriptions are all in terms of /sys/block/sd<letter>/ which will not exist if scsi_debug is called like this: $ modprobe scsi_debug ptype=1 That creates a pseudo host with an attached (virtual) tape drive. If the patchset works for other peripheral device types (i.e. that don't use the sd driver) then the description should at least mention the more general case (i.e. /sys/class/scsi_device/<hctl>/device ) IMO. Doug Gilbert
On 11/14/22 11:54, Douglas Gilbert wrote: > On 2022-11-13 19:30, Damien Le Moal wrote: >> On 11/14/22 06:48, Douglas Gilbert wrote: >>> On 2022-11-09 10:59, 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 >>>> >>>> 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 manager single devices' error inject >>>> scsi:scsi_debug: Add interface to remove injection which has been added >>>> scsi:scsi_debug: make command timeout if timeout error is injected >>>> scsi:scsi_debug: Return failed value for specific command's queuecommand >>>> scsi:scsi_debug: fail specific scsi command with result and sense data >>>> >>>> drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 295 insertions(+) >>> >>> Hi, >>> This patchset seems to assume all scsi_debug devices will be disk (-like) SCSI >>> devices. That leaves out other device types: tapes, enclosures, WLUNs, etc. >>> >>> Have you considered putting these device specific additions under: >>> /sys/class/scsi_device/<hctl>/device/error_inject/ >>> instead of >>> /sys/block/sdb/device/error_inject/ >> >> But these are the same, no ? >> At least on my Fedora box, I see: >> >> /sys/block/sdp/device/ being >> /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 >> >> and /sys/class/scsi_device/19:0:0:0/device being >> /sys/devices/pseudo_0/adapter0/host19/target19:0:0/19:0:0:0 > > Well the patch descriptions are all in terms of /sys/block/sd<letter>/ > which will not exist if scsi_debug is called like this: > $ modprobe scsi_debug ptype=1 > > That creates a pseudo host with an attached (virtual) tape drive. If > the patchset works for other peripheral device types (i.e. that don't > use the sd driver) then the description should at least mention the > more general case (i.e. /sys/class/scsi_device/<hctl>/device ) IMO. Got it. > > Doug Gilbert >
On 2022/11/14 5:48, Douglas Gilbert wrote: > On 2022-11-09 10:59, 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 >> >> 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 manager single devices' error inject >> scsi:scsi_debug: Add interface to remove injection which has been added >> scsi:scsi_debug: make command timeout if timeout error is injected >> scsi:scsi_debug: Return failed value for specific command's queuecommand >> scsi:scsi_debug: fail specific scsi command with result and sense data >> >> drivers/scsi/scsi_debug.c | 295 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 295 insertions(+) > > Hi, > This patchset seems to assume all scsi_debug devices will be disk (-like) SCSI > devices. That leaves out other device types: tapes, enclosures, WLUNs, etc. > > Have you considered putting these device specific additions under: > /sys/class/scsi_device/<hctl>/device/error_inject/ > instead of > /sys/block/sdb/device/error_inject/ > > ? > > Doug Gilbert > Thanks for your reply. I did not notice other device types, but the error_inject interface is added for scsi_device, so it is available for all types. I would update the path in patch description. Do you have other suggestions?