From: Lukas Wunner <lukas@wunner.de>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, Rob Herring <robh@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Krzysztof Wilczy??ski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/17] PCI: Add concurrency safe clear_and_set variants for LNKCTL{,2}
Date: Sun, 14 May 2023 12:10:41 +0200 [thread overview]
Message-ID: <20230514101041.GA1881@wunner.de> (raw)
In-Reply-To: <51577aaa-dc96-d588-2ecf-5bac4b59284@linux.intel.com>
On Fri, May 12, 2023 at 11:25:32AM +0300, Ilpo Järvinen wrote:
> On Thu, 11 May 2023, Lukas Wunner wrote:
> > On Thu, May 11, 2023 at 10:55:06AM -0500, Bjorn Helgaas wrote:
> > > I didn't see the prior discussion with Lukas, so maybe this was
> > > answered there, but is there any reason not to add locking to
> > > pcie_capability_clear_and_set_word() and friends directly?
> > >
> > > It would be nice to avoid having to decide whether to use the locked
> > > or unlocked versions.
> >
> > I think we definitely want to also offer lockless accessors which
> > can be used in hotpaths such as interrupt handlers if the accessed
> > registers don't need any locking (e.g. because there are no concurrent
> > accesses).
> >
> > So the relatively lean approach chosen here which limits locking to
> > Link Control and Link Control 2, but allows future expansion to other
> > registers as well, seemed reasonable to me.
>
> I went through every single use of these functions in the mainline tree
> excluding LNKCTL/LNKCTL2 ones which will be having the lock anyway:
>
> - pcie_capability_clear_and_set_*
> - pcie_capability_set_*
> - pcie_capability_clear_*
We're also performing RMW through pcie_capability_read_word() +
pcie_capability_write_word() combos, see drivers/pci/hotplug/pciehp_hpc.c
for examples.
> Do you still feel there's a need to differentiate this per capability
> given all the information above?
What I think is unnecessary and counterproductive is to add wholesale
locking of any access to the PCI Express Capability Structure.
It's fine to have a single spinlock, but I'd suggest only using it
for registers which are actually accessed concurrently by multiple
places in the kernel.
> spinlock + irq / work drivers/pci/pcie/pme.c: pcie_capability_set_word(dev, PCI_EXP_RTCTL,
> spinlock + irq / work drivers/pci/pcie/pme.c: pcie_capability_clear_word(dev, PCI_EXP_RTCTL,
[...]
> What's more important though, isn't it possible that AER and PME RMW
> PCI_EXP_RTCTL at the same time so it would need this RMW locking too
> despite the pme internal spinlock?
Yes that looks broken, so RTCTL would be another register besides
LNKCTL and LNKCTL2 that needs protection, good catch.
Thanks,
Lukas
next prev parent reply other threads:[~2023-05-14 10:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 13:14 [PATCH 00/17] PCI: Improve LNKCTL & LNKCTL2 concurrency control Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 01/17] PCI: Add concurrency safe clear_and_set variants for LNKCTL{,2} Ilpo Järvinen
2023-05-11 15:55 ` Bjorn Helgaas
2023-05-11 17:35 ` Ilpo Järvinen
2023-05-11 19:22 ` Bjorn Helgaas
2023-05-11 19:58 ` Ilpo Järvinen
2023-05-11 20:07 ` Lukas Wunner
2023-05-11 20:28 ` Ilpo Järvinen
2023-05-11 22:21 ` Bjorn Helgaas
2023-05-11 21:27 ` Bjorn Helgaas
2023-05-11 20:23 ` Lukas Wunner
2023-05-12 8:25 ` Ilpo Järvinen
2023-05-14 10:10 ` Lukas Wunner [this message]
2023-05-15 11:59 ` Ilpo Järvinen
2023-05-15 18:28 ` Bjorn Helgaas
2023-05-15 22:12 ` Lukas Wunner
2023-05-11 13:14 ` [PATCH 02/17] PCI: pciehp: Protect LNKCTL changes Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 03/17] PCI/ASPM: Use pcie_lnkctl_clear_and_set() Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 04/17] drm/amdgpu: Use pcie_lnkctl{,2}_clear_and_set() for changing LNKCTL{,2} Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 05/17] drm/radeon: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 06/17] IB/hfi1: " Ilpo Järvinen
2023-05-11 15:19 ` Dean Luick
2023-05-11 20:02 ` Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 07/17] e1000e: Use pcie_lnkctl_clear_and_set() for changing LNKCTL Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 08/17] net/mlx5: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 09/17] wifi: ath9k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 10/17] mt76: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 11/17] Bluetooth: hci_bcm4377: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 12/17] misc: rtsx: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 13/17] net/tg3: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 14/17] r8169: " Ilpo Järvinen
2023-05-11 19:49 ` Heiner Kallweit
2023-05-11 20:00 ` Ilpo Järvinen
2023-05-11 20:10 ` Lukas Wunner
2023-05-11 20:11 ` Heiner Kallweit
2023-05-11 20:02 ` Lukas Wunner
2023-05-11 20:17 ` Heiner Kallweit
2023-05-11 13:14 ` [PATCH 15/17] wifi: ath11k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 16/17] wifi: ath12k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 17/17] wifi: ath10k: " Ilpo Järvinen
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=20230514101041.GA1881@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=robh@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).