| Message ID | 5821904A020000780011CF55@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Tue, Nov 08, 2016 at 12:43:54AM -0700, Jan Beulich wrote: > msi_setup_entry() only logs a message when the affinity vector can't be > allocated, and hence pci_irq_get_affinity() indexing entry->affinity is > wrong without a prior check. Looks fine: Reviewed-by: Christoph Hellwig <hch@lst.de> But just curious: did you run into that case in practice? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> On 08.11.16 at 15:59, <hch@lst.de> wrote: > On Tue, Nov 08, 2016 at 12:43:54AM -0700, Jan Beulich wrote: >> msi_setup_entry() only logs a message when the affinity vector can't be >> allocated, and hence pci_irq_get_affinity() indexing entry->affinity is >> wrong without a prior check. > > Looks fine: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > But just curious: did you run into that case in practice? No, I've just noticed it while re-basing other changes onto 4.9-rc. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 08, 2016 at 12:43:54AM -0700, Jan Beulich wrote: > msi_setup_entry() only logs a message when the affinity vector can't be > allocated, and hence pci_irq_get_affinity() indexing entry->affinity is > wrong without a prior check. > > Fixes: ee8d41e53efe "pci/msi: Retrieve affinity for a vector" > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Christoph Hellwig <hch@lst.de> Applied to pci/msi for v4.10 with Christoph's reviewed-by and the following changelog: PCI/MSI: Check for NULL affinity mask in pci_irq_get_affinity() If msi_setup_entry() fails to allocate an affinity mask, it logs a message but continues on and allocates an MSI entry with entry->affinity == NULL. Check for this case in pci_irq_get_affinity() so we don't try to dereference a NULL pointer. > --- > drivers/pci/msi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- 4.9-rc4/drivers/pci/msi.c > +++ 4.9-rc4-PCI-MSI-no-affinity/drivers/pci/msi.c > @@ -1294,7 +1294,8 @@ const struct cpumask *pci_irq_get_affini > } else if (dev->msi_enabled) { > struct msi_desc *entry = first_pci_msi_entry(dev); > > - if (WARN_ON_ONCE(!entry || nr >= entry->nvec_used)) > + if (WARN_ON_ONCE(!entry || !entry->affinity || > + nr >= entry->nvec_used)) > return NULL; > > return &entry->affinity[nr]; > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- 4.9-rc4/drivers/pci/msi.c +++ 4.9-rc4-PCI-MSI-no-affinity/drivers/pci/msi.c @@ -1294,7 +1294,8 @@ const struct cpumask *pci_irq_get_affini } else if (dev->msi_enabled) { struct msi_desc *entry = first_pci_msi_entry(dev); - if (WARN_ON_ONCE(!entry || nr >= entry->nvec_used)) + if (WARN_ON_ONCE(!entry || !entry->affinity || + nr >= entry->nvec_used)) return NULL; return &entry->affinity[nr];
msi_setup_entry() only logs a message when the affinity vector can't be allocated, and hence pci_irq_get_affinity() indexing entry->affinity is wrong without a prior check. Fixes: ee8d41e53efe "pci/msi: Retrieve affinity for a vector" Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Hellwig <hch@lst.de> --- drivers/pci/msi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html