All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org, Wei Zhang <wzhang@fb.com>,
	Jens Axboe <axboe@fb.com>
Subject: Re: [PATCH 0/3] Limiting pci access requests
Date: Wed, 17 Aug 2016 17:05:40 -0400	[thread overview]
Message-ID: <20160817210539.GA25146@localhost.localdomain> (raw)
In-Reply-To: <20160809185628.GA6729@wunner.de>

On Tue, Aug 09, 2016 at 08:56:28PM +0200, Lukas Wunner wrote:
> On Tue, Aug 09, 2016 at 02:56:54PM -0400, Keith Busch wrote:
> > There are still more places that we can remove unnecessary config and
> > MMIO, though they're just micro-improvements compared to this series.
> > Even those just repeat the same pattern of looking for a -1 completion
> > or false return from "pci_device_is_present". So the "fixes" do look
> > tedious and piecemeal, but I didn't see how else we could do it. Any
> > thoughts or guidance is much appreciated.
> 
> FWIW, similar checks were added to pciehp with commit 1469d17dd341
> ("PCI: pciehp: Handle invalid data when reading from non-existent
> devices"). So the general idea to handle such faults is already
> present in the kernel, the only improvement I could see here would
> be to harmonize (i.e. make identical everywhere) the way this is
> coded (check for ~0) as well as the message logged with KERN_INFO
> (your patches do not log a message at all AFAICS).

AFAICT, the only thing we can do is have every caller of
pci_read_config_*, pci_bus_read_config_*, and pcie_capability_read_*
check for ~0 completion, and handle accordingly. Is that what you mean
by making this identical everywhere?  That is a lot of places to fix! :)

I could write a coccinelle pattern for that, but the actual handling
would need to be specific to where it's called, and it may accidently
treat a legit all 1's completion as an error.

  reply	other threads:[~2016-08-17 21:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08 19:14 [PATCH 0/3] Limiting pci access requests Keith Busch
2016-08-08 19:14 ` [PATCH 1/3] pcie: Don't search capabilities on removed devices Keith Busch
2016-08-18 22:38   ` Bjorn Helgaas
2016-08-08 19:14 ` [PATCH 2/3] pci/msix: Skip disabling " Keith Busch
2016-08-18 23:29   ` Bjorn Helgaas
2016-08-19 17:11     ` Keith Busch
2016-08-08 19:14 ` [PATCH 3/3] pcie/aer: Cache capability position Keith Busch
2016-08-09 17:33   ` Bjorn Helgaas
2016-09-06 21:05     ` Jon Derrick
2016-09-06 21:18       ` Keith Busch
2016-08-09 17:36 ` [PATCH 0/3] Limiting pci access requests Bjorn Helgaas
2016-08-09 18:56   ` Keith Busch
2016-08-09 18:56     ` Lukas Wunner
2016-08-17 21:05       ` Keith Busch [this message]
2016-08-18 14:02         ` Lukas Wunner
2016-08-18 16:05           ` Keith Busch
2016-08-18 16:59             ` Lukas Wunner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160817210539.GA25146@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=axboe@fb.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=wzhang@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.