From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751379AbdKUQxY (ORCPT ); Tue, 21 Nov 2017 11:53:24 -0500 Received: from esa3.hgst.iphmx.com ([216.71.153.141]:48464 "EHLO esa3.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751154AbdKUQxW (ORCPT ); Tue, 21 Nov 2017 11:53:22 -0500 X-IronPort-AV: E=Sophos;i="5.44,432,1505750400"; d="scan'208";a="63349732" From: Bart Van Assche To: "jejb@linux.vnet.ibm.com" , "ptikhomirov@virtuozzo.com" , "martin.petersen@oracle.com" CC: "hch@lst.de" , "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devel@openvz.org" , "khorenko@virtuozzo.com" Subject: Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy Thread-Topic: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy Thread-Index: AQHTJkY4XaohUn75JkqG3J3A/BhUUaMfheiA Date: Tue, 21 Nov 2017 16:53:18 +0000 Message-ID: <1511283197.2692.13.camel@wdc.com> References: <20170905125424.15412-1-ptikhomirov@virtuozzo.com> In-Reply-To: <20170905125424.15412-1-ptikhomirov@virtuozzo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com; x-originating-ip: [199.255.44.171] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1536;20:t1MKcVDE8NwxaTFr5yuvymsTnJvL3U8O6Waq6T2vcxe1Ig7P6TRoQAQVdB+BAdSlBrqIBo3gS3pH+nqQ4yp/1wBgKZSItQ+DRTblKj4l3I/EpNbuoxe1K6nw4A78Btp6wnyRRQ5Ze/eGABOSS6YPb5PfLMQCMDVgGpnbuwvk8r8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 87859e90-27be-4bd1-8386-08d531005e06 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258);SRVR:CY1PR0401MB1536; x-ms-traffictypediagnostic: CY1PR0401MB1536: wdcipoutbound: EOP-TRUE x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB1536;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB1536; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(346002)(376002)(24454002)(51444003)(199003)(377424004)(189002)(110136005)(8936002)(189998001)(86362001)(77096006)(14454004)(6486002)(6506006)(97736004)(5660300001)(106356001)(2950100002)(105586002)(6246003)(53936002)(25786009)(4326008)(6436002)(2900100001)(229853002)(33646002)(68736007)(6512007)(478600001)(72206003)(2201001)(99286004)(3280700002)(3846002)(6116002)(102836003)(7736002)(305945005)(50986999)(76176999)(54356999)(3660700001)(2906002)(103116003)(36756003)(66066001)(316002)(2501003)(101416001)(54906003)(8676002)(81166006)(81156014);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1536;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87859e90-27be-4bd1-8386-08d531005e06 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 16:53:18.8945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1536 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vALGrTRU016790 On Tue, 2017-09-05 at 15:54 +0300, Pavel Tikhomirov wrote: > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index f6097b89d5d3..6c99221d60aa 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -320,12 +320,11 @@ void scsi_device_unbusy(struct scsi_device *sdev) > if (starget->can_queue > 0) > atomic_dec(&starget->target_busy); > > + spin_lock_irqsave(shost->host_lock, flags); > if (unlikely(scsi_host_in_recovery(shost) && > - (shost->host_failed || shost->host_eh_scheduled))) { > - spin_lock_irqsave(shost->host_lock, flags); > + (shost->host_failed || shost->host_eh_scheduled))) > scsi_eh_wakeup(shost); > - spin_unlock_irqrestore(shost->host_lock, flags); > - } > + spin_unlock_irqrestore(shost->host_lock, flags); > > atomic_dec(&sdev->device_busy); > } > @@ -1503,6 +1502,13 @@ static inline int scsi_host_queue_ready(struct request_queue *q, > spin_unlock_irq(shost->host_lock); > out_dec: > atomic_dec(&shost->host_busy); > + > + spin_lock_irq(shost->host_lock); > + if (unlikely(scsi_host_in_recovery(shost) && > + (shost->host_failed || shost->host_eh_scheduled))) > + scsi_eh_wakeup(shost); > + spin_unlock_irq(shost->host_lock); > + > return 0; > } > > @@ -1964,6 +1970,13 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, > > out_dec_host_busy: > atomic_dec(&shost->host_busy); > + > + spin_lock_irq(shost->host_lock); > + if (unlikely(scsi_host_in_recovery(shost) && > + (shost->host_failed || shost->host_eh_scheduled))) > + scsi_eh_wakeup(shost); > + spin_unlock_irq(shost->host_lock); > + > out_dec_target_busy: > if (scsi_target(sdev)->can_queue > 0) > atomic_dec(&scsi_target(sdev)->target_busy); An important achievement of the scsi-mq code was removal of all spin_lock_irq(shost->host_lock) statements from the hot path. The above changes will have a significant negative performance impact, especially if multiple LUNs associated with the same SCSI host are involved. Can the reported race be fixed without slowing down the hot path significantly? I think that both adding spin lock or smp_mb() calls in the hot path will have a significant negative performance impact. Thanks, Bart.