From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755418AbdESWfz (ORCPT ); Fri, 19 May 2017 18:35:55 -0400 Received: from esa1.hgst.iphmx.com ([68.232.141.245]:46968 "EHLO esa1.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdESWfu (ORCPT ); Fri, 19 May 2017 18:35:50 -0400 X-IronPort-AV: E=Sophos;i="5.38,366,1491235200"; d="scan'208";a="121555938" From: Bart Van Assche To: "caods1@lenovo.com" , "linux-scsi@vger.kernel.org" CC: "linux-kernel@vger.kernel.org" Subject: Re: work queue of scsi fc transports should be serialized Thread-Topic: work queue of scsi fc transports should be serialized Thread-Index: AdLQgybfZvOD7KpeTb2q0AaWEiT1iwAbK2+A Date: Fri, 19 May 2017 22:32:44 +0000 Message-ID: <1495233163.2581.5.camel@sandisk.com> References: <23B7B563BA4E9446B962B142C86EF24A088AE2FB@CNMAILEX03.lenovo.com> In-Reply-To: <23B7B563BA4E9446B962B142C86EF24A088AE2FB@CNMAILEX03.lenovo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lenovo.com; dkim=none (message not signed) header.d=none;lenovo.com; dmarc=none action=none header.from=sandisk.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1536;7:KaDKps/NK8RAkiwHoYYGx/ez4tYhxzINwtABlukZsB/hzbvzUrHTh+IwJzd+0pt5jQtiiYCqDA9P+O/aqTD5yzQ9nYtelrqRTsEZe5Y49a0TLhTxifws/zc6Z/KfbaaLR/ts5Ub19y3BGCu6czWUc+uDr/qSmQdn92S1PdV1xj7NzmLP2iECaOrLtDqTGumy1NULq8nSGDeyAXNWfJRv3Aji3e2fDGi0u/a7prQvW0gp5+u8ONgYmFoYFRfSk4dRLoZmbvW5J5y06/4W9of7YK0UnV+FGjDShLV3KmFabwkznEjVjolAEe/BsONwCPhSikeSy1b5Ww9tGLJC4/sUng==;20:H1mJ9f/e2hL/6Hb7ckUxdZbJhMj0RTP1RCgs+VqWaa9P3xaPBCi338SAmhWpHW2/DTWlhnECfJ1YL3aGvBN695sr8I09uKay96ePWkStPwxxB5iBGFyOtNo4X6EZv3LxfMiJGxMPYVMQkEglAaC2M/dgPTNifLkHXPVBhQsQytk= x-ms-traffictypediagnostic: CY1PR0401MB1536: x-ms-office365-filtering-correlation-id: f9d4fbc9-eb96-4e3d-9762-08d49f06f80e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR: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:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148);SRVR:CY1PR0401MB1536;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1536; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39850400002)(39410400002)(39840400002)(39400400002)(39860400002)(39450400003)(24454002)(377424004)(66066001)(6116002)(102836003)(3846002)(25786009)(50986999)(3660700001)(2501003)(72206003)(54356999)(5660300001)(2906002)(76176999)(2900100001)(3280700002)(189998001)(478600001)(86362001)(53936002)(36756003)(6246003)(38730400002)(4326008)(6512007)(305945005)(6506006)(81166006)(122556002)(99286003)(6436002)(8936002)(229853002)(77096006)(2950100002)(8676002)(33646002)(103116003)(6486002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1536;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <06AFFAA23DC05C4BAB3D66657902A44B@namprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 22:32:44.4689 (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 quoted-printable to 8bit by mail.home.local id v4JMZwNt029964 On Fri, 2017-05-19 at 09:36 +0000, Dashi DS1 Cao wrote: > It seems there is a race of multiple "fc_starget_delete" of the same rport, > thus of the same SCSI host. The race leads to the race of scsi_remove_target > and it cannot be prevented by the code snippet alone, even of the most recent > version: > spin_lock_irqsave(shost->host_lock, flags); > list_for_each_entry(starget, &shost->__targets, siblings) { > if (starget->state == STARGET_DEL || > starget->state == STARGET_REMOVE) > continue; > If there is a possibility that the starget is under deletion(state == > STARGET_DEL), it should be possible that list_next_entry(starget, siblings) > could cause a read access violation. Hello Dashi, Something else must be going on. From scsi_remove_target(): restart: spin_lock_irqsave(shost->host_lock, flags); list_for_each_entry(starget, &shost->__targets, siblings) { if (starget->state == STARGET_DEL ||     starget->state == STARGET_REMOVE) continue; if (starget->dev.parent == dev || &starget->dev == dev) { kref_get(&starget->reap_ref); starget->state = STARGET_REMOVE; spin_unlock_irqrestore(shost->host_lock, flags); __scsi_remove_target(starget); scsi_target_reap(starget); goto restart; } } spin_unlock_irqrestore(shost->host_lock, flags); In other words, before scsi_remove_target() decides to call __scsi_remove_target(), it changes the target state into STARGET_REMOVE while holding the host lock. This means that scsi_remove_target() won't call __scsi_remove_target() twice and also that it won't invoke list_next_entry(starget, siblings) after starget has been freed. Bart.