summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorMing Lei <ming.lei@redhat.com>2019-01-15 17:31:29 -0600
committerBjorn Helgaas <bhelgaas@google.com>2019-01-15 17:31:29 -0600
commit77f88abd4a6f73a1a68dbdc0e3f21575fd508fc3 (patch)
tree9ddd3f770241252842fb9e40cbad8a65645824fc /kernel
parent2e8cb2cf1bd6e90f58bd517eb9ca1938e64fa51c (diff)
PCI/MSI: Return -ENOSPC from pci_alloc_irq_vectors_affinity()
The API of pci_alloc_irq_vectors_affinity() says it returns -ENOSPC if fewer than @min_vecs interrupt vectors are available for @dev. However, if a device supports MSI-X but not MSI and a caller requests @min_vecs that can't be satisfied by MSI-X, we previously returned -EINVAL (from the failed attempt to enable MSI), not -ENOSPC. When -ENOSPC is returned, callers may reduce the number IRQs they request and try again. Most callers can use the @min_vecs and @max_vecs parameters to avoid this retry loop, but that doesn't work when using IRQ affinity "nr_sets" because rebalancing the sets is driver-specific. This return value bug has been present since pci_alloc_irq_vectors() was added in v4.10 by aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines"), but it wasn't an issue because @min_vecs/@max_vecs removed the need for callers to iteratively reduce the number of IRQs requested and retry the allocation, so they didn't need to distinguish -ENOSPC from -EINVAL. In v5.0, 6da4b3ab9a6e ("genirq/affinity: Add support for allocating interrupt sets") added IRQ sets to the interface, which reintroduced the need to check for -ENOSPC and possibly reduce the number of IRQs requested and retry the allocation. Signed-off-by: Ming Lei <ming.lei@redhat.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Jens Axboe <axboe@fb.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions