From: Thierry Reding <thierry.reding@gmail.com>
To: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Global lock for PCI configuration accesses
Date: Wed, 9 Sep 2015 17:11:27 +0200 [thread overview]
Message-ID: <20150909151126.GA1366@ulmo.nvidia.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
Hi,
There's currently an issue with PCI configuration space accesses on
Tegra. The PCI host controller driver's ->map_bus() implementation
remaps I/O memory on-demand to avoid potentially wasting 256 MiB of
virtual address space. The reason why this is done is because the
mapping isn't compatible with ECAM and the extended register number
is encoded in the uppermost 4 bits. This means that if we want to
address the configuration space for a single bus we already need to
map 256 MiB of memory, even if only 1 MiB is really used.
tegra_pcie_bus_alloc() is therefore used to stitch together a 1 MiB
block of virtual addresses per bus made up of 16 64 KiB chunks each
so that only what's really needed is mapped.
That function gets called the first time a PCI configuration access
is performed on a bus. The code calls functions that may sleep, and
that causes problems because the PCI configuration space accessors
are called with the global pci_lock held. This works in practice
but it blows up when lockdep is enabled.
I remember coding up a fix for this using the ARM/PCI ->add_bus()
callbacks at one point and then forgetting about it. When I wanted
to revive that patch a little while ago I noticed that ->add_bus()
is now gone.
What I'm asking myself now is how to fix this. I suppose it'd be
possible to bring back ->add_bus(), though I suspect there were good
reasons to remove it (portability?). Another possible fix would be
to get rid of the spinlock protecting these accesses. It seems to me
like it's not really necessary in the majority of cases. For drivers
that do a simple readl() or writel() on some memory-mapped I/O the
lock doesn't protect anything.
Then again, there are a lot of pci_ops implementations in the tree,
and simply removing the global lock seems like it'd have a good chance
of breaking things for somebody.
So short of auditing all pci_ops implementations and pushing the lock
down into drivers, does anyone have any good ideas on how to fix this?
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next reply other threads:[~2015-09-09 15:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 15:11 Thierry Reding [this message]
2015-09-09 17:27 ` Global lock for PCI configuration accesses Bjorn Helgaas
2015-09-10 13:00 ` Thierry Reding
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=20150909151126.GA1366@ulmo.nvidia.com \
--to=thierry.reding@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).