On Fri, Dec 08, 2023 at 09:00:56AM +0100, Johan Hovold wrote:
On Thu, Dec 07, 2023 at 02:47:16PM -0600, Bjorn Helgaas wrote:
On Tue, Nov 28, 2023 at 09:15:07AM +0100, Johan Hovold wrote:
Add a helper for enabling link states that can be used in contexts where a pci_bus_sem read lock is already held (e.g. from pci_walk_bus()).
This helper will be used to fix a couple of potential deadlocks where the current helper is called with the lock already held, hence the CC stable tag.
As far as I can see, we end up with pci_enable_link_state() defined but never called and pci_enable_link_state_locked() being called only by pcie-qcom.c and vmd.c.
Correct, I mentioned this in the cover letter.
Ah, right. I really don't like these exported locked/unlocked interfaces because pci_bus_sem is internal to the PCI core, and the caller shouldn't need to know or be able to specify whether it is held or not. They exist for now, but I think we should try to get rid of them.
Can we just rename pci_enable_link_state() to pci_enable_link_state_locked() and assert that pci_bus_sem is held, so we don't end up with a function that's never used?
That would work too. I went with adding a new helper to facilitate stable backports and to mirror pci_disable_link_state(). The variants are simple wrappers around the implementation so there's no real cost to having the unused one.
Makes good sense. There's no real machine cost to the unused one; I'm more concerned about the human cost here.
But it seems like you think there will never be a need to call this helper outside of pci_walk_bus() and if so we can drop the unlocked variant right away.
Would you prefer basically squashing the first three patches and mark the result for stable even though that patch will fail to apply to older kernels as the Qualcomm bits went into -rc1?
Or should I send a follow-on patch removing the unused helper after merging this series?
I think you did the right thing.
Bjorn