Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp56912imu; Thu, 8 Nov 2018 14:43:48 -0800 (PST) X-Google-Smtp-Source: AJdET5cYotmiVwEcOCgfcyUsEdKT75sv2yfya4uag+Pjeu1OJRxmRYkURdzej8y/l8+j4YTqAwbK X-Received: by 2002:a63:8e43:: with SMTP id k64mr5290198pge.346.1541717028538; Thu, 08 Nov 2018 14:43:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541717028; cv=none; d=google.com; s=arc-20160816; b=dqAFIu6InxpWRcm5tMQemX4kMs+XLxpE3I+Xwir9CcZUAsIYpA5a4zqM5vyqEx7tAM hZ813bQHI1PFT3V4KjfQzhpmDcVVVzrY37X3Hdvy1lqI64T86VW01Byu5guSq/nm4icn we4j+1rtDNpOz1Hr2wWkOq25+h1Kz1MpaVY1igd1ECyInw55QQXpiCrsLybSWS9CfUkf Or9a4JRJyQdwOZ0jvq3BTVKHWaQegDrlDAX50VKOgjzKFProxj0u8X3tgarIo3+n0GUz aXTGQYUAIO8JYBP3HS6hs2IlXTOG3ZXW78uD5L0uC5PXH3z/3BvjATmZ4ZI0f/w6lbWp 2tfg== 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:dkim-signature; bh=apGY44KdPf01lE6QoPISoyguH9c8THanm8fG6e8ADlk=; b=PVuNJ3zAHh9zUfNYPRBRFBmdJemLgwSQrPbYce5xgoOwwCGj7BSrL4WiqkR36TEB7h UOdyguiMV07CeAkE4kkvWP/1KUo6e1bOb8Zgex3tTlRYZb00pwphVjK6VhI0uQW4cr25 tKWOklnBxzutSCjbkyjz/TKj5MNvFwPpmWrFHGPGdlHnAQMcSk/TbrC0qJz9cYkMaNVp BZMtWZkhY75EgESR5a4APsuSC5NfX0FxpVHofW0wxA3a+DU0r4jrIlT8D2TwmLOWFP6+ Rb1RNLtLTRG0T0vzziFGQM01yBJeeBh5okIlU4X6dudGNLudeEm+/JIcuXERc4OKkZ78 MLAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A0OgAqMG; 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 n33si4260540pgl.336.2018.11.08.14.43.33; Thu, 08 Nov 2018 14:43:48 -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; dkim=pass header.i=@kernel.org header.s=default header.b=A0OgAqMG; 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 S1729013AbeKIIUn (ORCPT + 99 others); Fri, 9 Nov 2018 03:20:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:58020 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727215AbeKIIUn (ORCPT ); Fri, 9 Nov 2018 03:20:43 -0500 Received: from localhost (unknown [208.72.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5934620844; Thu, 8 Nov 2018 22:43:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541716981; bh=CZ0Ic1ELIM9SJl7Wg6u0NXiSoeVueCcqe0ZVBgVoFAw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A0OgAqMGMabiNBmUU0+4niKxA8gxwcLSEoP2lmRFEj/9WzpHZCi30b4FvyKjhJxhp CzeYe5h3s/2AyLGEAQrawRGze2o+IeSR/eBw9klYcvBN0gRH+HvADixiO6mPsfDMC6 y7soYYn2zbv5GjOwgAQwhNpMtQo4emzQZYQL/RVY= Date: Thu, 8 Nov 2018 14:42:55 -0800 From: Greg Kroah-Hartman To: Keith Busch 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: <20181108224255.GA20619@kroah.com> References: <20180918221501.13112-1-mr.nuke.me@gmail.com> <20181107234257.GC41183@google.com> <20181108200855.GE41183@google.com> <20181108220117.GA11466@kroah.com> <20181108223258.GD2932@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181108223258.GD2932@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) 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 03:32:58PM -0700, Keith Busch wrote: > 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. Then why even care about this call at all? If you need to really know if the read worked, you have to check the value. If the value is FF then you have a huge hint that the hardware is now gone. And you can rely on it being gone, you can never rely on making the call to the function to check if the hardware is there to be still valid any point in time after the call returns. > 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. You are not "interacting", you are reading/writing to the hardware, as you have to do so. So I really don't understand what you are talking about here, sorry. greg k-h