Received: by 10.213.65.68 with SMTP id h4csp1182151imn; Wed, 21 Mar 2018 04:52:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELufvW4KQZQATR+c3Klc7qodkHEo4eYli+mIX6wbfAzNIAiYpKfuQJnW7a0CtncjsazjwVAV X-Received: by 10.98.159.85 with SMTP id g82mr16616517pfe.15.1521633160723; Wed, 21 Mar 2018 04:52:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521633160; cv=none; d=google.com; s=arc-20160816; b=xMq2Fgjdi5wUZjaP/28/uUpE+TDEnGzxKsDNvzLmBUzR/yPCB9ICBVFLXdAS5b+WgC UsZmVO6EnKllklpvM4w5Sm6VuTLI8h3wLIA2sScCSefmQg9xN4J7apilWkF+WKqxTaT9 LX1AHKK8hydSttua9oT3DoTWhNyXBRbKwJYvMdnIUUfiLTRZ9NH4/DY/rcrDj9shS8iZ BJebRyuvRPD8iDxeK9Ps60edRbQFFdwHnBB06PVDry4a9+ZRUsi2fzEzoDBxSo+LA7Kx GclWHyGNqnLoPOggWwYKGRhpYXItzZnXsX//LdJPdzJ8QbbaeAjhB3G4/IolW1FSJHzU wZFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=E7COf/PFcimhilb+zCiaeYz3Hz34dARwOIKrWVQXGNg=; b=pONQhxhHJWCZiHOGES/AV79+Kq842V9RIItP/AzgjPDZXe1g2YOV0ut2raXkIRbvkI 3UIMfu4jSD3c1wgsmHb9+3DfNPVdwQZA5SmubXJVPHJwDgcXVOsRAe5u3Lp3ageH73ql +mxG7po6S2idyNejcskrT3hkkaupttDf4hpBp4I09RlEu+ZoraMtOiBQUshb5yE3/lUq 6CrcU1tZj+v6m0bteq4VCWjZ90YAS4zGzWW/J8tWdacRQlg1ZXst6u+zyiyMBFe5H8zL bg4o/+emmfH03ETJZV4C3XxrAI3tGmK/JCaezV1RuSGGeGW3JsXBX6nM3qDraySMJ3eb XvDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e10si2604259pgc.772.2018.03.21.04.52.26; Wed, 21 Mar 2018 04:52:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751843AbeCULvE (ORCPT + 99 others); Wed, 21 Mar 2018 07:51:04 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751789AbeCULvB (ORCPT ); Wed, 21 Mar 2018 07:51:01 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F58780AD20C; Wed, 21 Mar 2018 11:51:01 +0000 (UTC) Received: from ming.t460p (ovpn-12-103.pek2.redhat.com [10.72.12.103]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD4B42166BAE; Wed, 21 Mar 2018 11:50:47 +0000 (UTC) Date: Wed, 21 Mar 2018 19:50:43 +0800 From: Ming Lei To: Marta Rybczynska Cc: keith.busch@intel.com, axboe@fb.com, hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, linux-pci@vger.kernel.org, Pierre-Yves Kerbrat Subject: Re: [RFC PATCH] nvme: avoid race-conditions when enabling devices Message-ID: <20180321115037.GA26083@ming.t460p> References: <744877924.5841545.1521630049567.JavaMail.zimbra@kalray.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <744877924.5841545.1521630049567.JavaMail.zimbra@kalray.eu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 21 Mar 2018 11:51:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 21 Mar 2018 11:51:01 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'ming.lei@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 21, 2018 at 12:00:49PM +0100, Marta Rybczynska wrote: > NVMe driver uses threads for the work at device reset, including enabling > the PCIe device. When multiple NVMe devices are initialized, their reset > works may be scheduled in parallel. Then pci_enable_device_mem can be > called in parallel on multiple cores. > > This causes a loop of enabling of all upstream bridges in > pci_enable_bridge(). pci_enable_bridge() causes multiple operations > including __pci_set_master and architecture-specific functions that > call ones like and pci_enable_resources(). Both __pci_set_master() > and pci_enable_resources() read PCI_COMMAND field in the PCIe space > and change it. This is done as read/modify/write. > > Imagine that the PCIe tree looks like: > A - B - switch - C - D > \- E - F > > D and F are two NVMe disks and all devices from B are not enabled and bus > mastering is not set. If their reset work are scheduled in parallel the two > modifications of PCI_COMMAND may happen in parallel without locking and the > system may end up with the part of PCIe tree not enabled. Then looks serialized reset should be used, and I did see the commit 79c48ccf2fe ("nvme-pci: serialize pci resets") fixes issue of 'failed to mark controller state' in reset stress test. But that commit only covers case of PCI reset from sysfs attribute, and maybe other cases need to be dealt with in similar way too. Thanks, Ming