Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp51974imu; Thu, 8 Nov 2018 14:37:12 -0800 (PST) X-Google-Smtp-Source: AJdET5eAwPl1rc1heyc+B/N7eUKl9Iq0jwnQ1devVfmYMUnStVctrEs0TF41W0V9w8Wtc/5RT8us X-Received: by 2002:a17:902:b286:: with SMTP id u6-v6mr6466891plr.89.1541716632381; Thu, 08 Nov 2018 14:37:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541716632; cv=none; d=google.com; s=arc-20160816; b=R2R47A94ariJ8Ohx7H/YTC9ah52p414FaEOV4pAnNL7WCViIzp8Y/+IZrwbcB5lC7W +wx2MgXYzEVtZnf/CzG/xCEwMAEpB/O/hihPsU4e6rixBJojlMhQeKzkAVAsQYG2LgbO bYOr5tnhU2V7YoG8iX5WGeG/mAlwvcfKgdMzFgJsfmNjrxFwhcWZELnRJ0i0qeM1LCwC r8VGmq1vivF4ZHgWnBN6tLQ0qYdoodte+Lyecc9rmUbJ3Nw/X7QlMim+hdgHzcuh1xuC 0B4adLmIp5dP+8WnXLLjsC/H2YtN1USf69AwBDChYRyA2Fiv6ZuvHAnKuBZ7a8rWkkXB 7gEw== 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; bh=CTXT/z1qsgMKZyMQlpfLhwfWcWqVSM6rZsF4I1AkxLA=; b=vN7RGwMwRIlCQLZyItYoTC7GQ7A13P5kdOBpH8Fxj4T0v/wnPG/GRRyMVrBU8LKuje fzOQqcENI+1Hgo1fq2hdSY6/h7N6E0jrjRuA3i2Hz0vgio246En0j2/p/ziGVfWBSX9f JVUgAdAeJECwbxOY2Z3xcfkitvMmorGtHX1lpSC4xlI9xUngUqwv/iQlpY91npSJtler kzTVxyskUA5Bs+75tl+yu/A+wsNmzkn3O2AO6Jy3pR/6zxQnnmmxCeBXFd7CaxU1EUcD F9m/SiQk+nZUqcKZx+jMKTlq6KLpMbb2DxBbRs/QXZksP08Lq79kWMtSKQUm0kOKAdvV 0ugQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q22-v6si4932681pgb.368.2018.11.08.14.36.56; Thu, 08 Nov 2018 14:37:12 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729549AbeKIIOS (ORCPT + 99 others); Fri, 9 Nov 2018 03:14:18 -0500 Received: from mga17.intel.com ([192.55.52.151]:61932 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727800AbeKIIOS (ORCPT ); Fri, 9 Nov 2018 03:14:18 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2018 14:36:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,481,1534834800"; d="scan'208";a="279543465" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga006.fm.intel.com with ESMTP; 08 Nov 2018 14:36:37 -0800 Date: Thu, 8 Nov 2018 15:32:58 -0700 From: Keith Busch To: Greg Kroah-Hartman Cc: Bjorn Helgaas , Alexandru Gagniuc , linux-pci@vger.kernel.org, alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, linux-kernel@vger.kernel.org, Jonathan Derrick , Lukas Wunner , Russell Currey , Sam Bobroff , Oliver O'Halloran , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected Message-ID: <20181108223258.GD2932@localhost.localdomain> References: <20180918221501.13112-1-mr.nuke.me@gmail.com> <20181107234257.GC41183@google.com> <20181108200855.GE41183@google.com> <20181108220117.GA11466@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181108220117.GA11466@kroah.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 08, 2018 at 02:01:17PM -0800, Greg Kroah-Hartman wrote: > On Thu, Nov 08, 2018 at 02:09:17PM -0600, Bjorn Helgaas wrote: > > I'm having second thoughts about this. One thing I'm uncomfortable > > with is that sprinkling pci_dev_is_disconnected() around feels ad hoc > > instead of systematic, in the sense that I don't know how we convince > > ourselves that this (and only this) is the correct place to put it. > > I think my stance always has been that this call is not good at all > because once you call it you never really know if it is still true as > the device could have been removed right afterward. > > So almost any code that relies on it is broken, there is no locking and > it can and will race and you will loose. AIUI, we're not trying to create code to rely on this. This more about reducing reliance on hardware. If the software misses the race once and accesses disconnected device memory, that's usually not a big deal to let hardware sort it out, but the point is not to push our luck. Surprise hot remove is empirically more reliable the less we interact with hardware and firmware. That shouldn't be necessary, but is just an unfortunate reality.