Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp336615imm; Thu, 16 Aug 2018 21:52:03 -0700 (PDT) X-Google-Smtp-Source: AA+uWPx0L5nMj2DVjfqJGbTu209OSGxdn9yxErR+SHVlIr8NRnGW8KoGLeccJsSeSaRPzrEzccBQ X-Received: by 2002:a17:902:820e:: with SMTP id x14-v6mr31941838pln.218.1534481523533; Thu, 16 Aug 2018 21:52:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534481523; cv=none; d=google.com; s=arc-20160816; b=Wn4SHDaxSl5EB3tnD+5+QBU5/2wmfSSeOZ09s3pVNECuh4xck/F8+IS9xOHhct2CUg 1PD3q5v03PDdepyjgCGTEbzcVjfjDEVpN9iNgLo8/SI/W5b+fjlKF4EvjCJXOvcqzyki tE76tcDflk+zt/IiNpE/cP2QR91ArXprUCnYwbwWdZbnE0dXX3OpoYjQwNFxCj1EmPmB kVDBArr8NoiUL6+sUHSbCOdfZU0j1n9N15d5Nkrbk1VQtMtVf5+tJBD1piottxKnamdi hH/GVIxvwZBQ1MDdy6rpDtOac1cHCgJicU7IiN6eybrqrizK/uwNiJ6+TkXs8jMXFFW1 XdEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=RKuvJBcL92oEidICRZbBIeMMzwdp0y8itIY8l7WeiHw=; b=GbvXOtGaVGipmRo4gGNO+ltFnne4+WZfLpYpOJEhKQKq87X3HxsiFz7qILG1MhEgzX DGymoUsjiF9LrA/2MW1Zsz/5NbLuyZWRktKJ6kvP1ZQ76rCrYli+Ai5hZPeh6NXIW0rF /dFRm0n1IMq1sd/P+yPWLvfMp0UH04Bh7BndG2BBJBUFUGx+uSVUo+Yqcn4fwHQRjs7B U5/ePfX5DWGBRYTH0q1vtyKAVUM+H21XG6u5eod1M0icfPKgA5mk3CQ+SH+QiI8ur1K6 KOCfNvTTz4qZls9nbN1h5rSK58yvd2GZ+Tx/p3AtnvZpBgo/+UIbwtnjaJmIJHnABydh j1iw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j67-v6si1201771pgc.186.2018.08.16.21.51.35; Thu, 16 Aug 2018 21:52:03 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726223AbeHQHvh (ORCPT + 99 others); Fri, 17 Aug 2018 03:51:37 -0400 Received: from gate.crashing.org ([63.228.1.57]:46710 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725833AbeHQHvh (ORCPT ); Fri, 17 Aug 2018 03:51:37 -0400 Received: from pasglop.ozlabs.ibm.com (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w7H4nAsD017258; Thu, 16 Aug 2018 23:49:11 -0500 From: Benjamin Herrenschmidt To: Bjorn Helgaas , linux-pci@vger.kernel.org Cc: Hari Vyas , Ray Jui , Srinath Mannam , Guenter Roeck , Jens Axboe , Lukas Wunner , Konstantin Khlebnikov , Marta Rybczynska , Pierre-Yves Kerbrat , linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/6] pci: Rework is_added race fix and address bridge enable races Date: Fri, 17 Aug 2018 14:48:56 +1000 Message-Id: <20180817044902.31420-1-benh@kernel.crashing.org> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is really two series but since they conflict a bit separately here they are in one: First we undo the mess of those atomic priv_flags. The atomicity doesn't provide any security since there's no locking against the other state pertaining to those flags, it only protects the flags themselves. The is_added mess is fixed much more simply by moving the assignment of the flag to before we start the driver. This is in line with the rest of the PCI code: until bound to the device model, we are essentially assuming a single threaded environment. is_added is a flag that is logically owned by that part of the PCI code, and thus should be set and cleared within that "safer" environment. This removes the horrid relative includes in the powerpc code as well. The second part aims at fixing the enable/disable/set_master races, and does so by providing a framework for future device state locking issues. It introduces a pci_dev->state_mutex which is used at a lower level than the device_lock (the device lock isn't suitable, as explained in the cset comments) and uses it to protect enablement and set_master.