lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Aug 2021 08:51:53 +1200
From:   Barry Song <21cnbao@...il.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Jonathan Corbet <corbet@....net>, Jonathan.Cameron@...wei.com,
        bilbao@...edu, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        leon@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        linux-pci@...r.kernel.org, Linuxarm <linuxarm@...wei.com>,
        luzmaximilian@...il.com, mchehab+huawei@...nel.org,
        schnelle@...ux.ibm.com, Barry Song <song.bao.hua@...ilicon.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 1/2] PCI/MSI: Fix the confusing IRQ sysfs ABI for MSI-X

On Sat, Aug 21, 2021 at 10:42 PM Marc Zyngier <maz@...nel.org> wrote:
>
> Hi Bjorn,
>
> On Sat, 21 Aug 2021 00:33:28 +0100,
> Bjorn Helgaas <helgaas@...nel.org> wrote:
> >
> > [+cc Thomas, Marc]
> >
> > On Sat, Aug 21, 2021 at 10:37:43AM +1200, Barry Song wrote:
> > > From: Barry Song <song.bao.hua@...ilicon.com>
> > >
> > > /sys/bus/pci/devices/.../irq sysfs ABI is very confusing at this
> > > moment especially for MSI-X cases.
> >
> > AFAICT this patch *only* affects MSI-X.  So are you saying the sysfs
> > ABI is fine for MSI but confusing for MSI-X?
> >
> > > While MSI sets IRQ to the first
> > > number in the vector, MSI-X does nothing for this though it saves
> > > default_irq in msix_setup_entries(). Weird the saved default_irq
> > > for MSI-X is never used in pci_msix_shutdown(), which is quite
> > > different with pci_msi_shutdown(). Thus, this patch moves to show
> > > the first IRQ number which is from the first msi_entry for MSI-X.
> > > Hopefully, this can make IRQ ABI more clear and more consistent.
> > >
> > > Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > Signed-off-by: Barry Song <song.bao.hua@...ilicon.com>
> > > ---
> > >  drivers/pci/msi.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > > index 9232255..6bbf81b 100644
> > > --- a/drivers/pci/msi.c
> > > +++ b/drivers/pci/msi.c
> > > @@ -771,6 +771,7 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
> > >     int ret;
> > >     u16 control;
> > >     void __iomem *base;
> > > +   struct msi_desc *desc;
> > >
> > >     /* Ensure MSI-X is disabled while it is set up */
> > >     pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
> > > @@ -814,6 +815,10 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries,
> > >     pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
> > >
> > >     pcibios_free_irq(dev);
> > > +
> > > +   desc = first_pci_msi_entry(dev);
> > > +   dev->irq = desc->irq;
> >
> > This change is not primarily about sysfs.  This is about changing
> > "dev->irq" when MSI-X is enabled, and it's only incidental that sysfs
> > reflects that.
> >
> > So we need to know the effect of changing dev->irq.  Drivers may use
> > the value of dev->irq, and I'm *guessing* this change shouldn't break
> > them since we already do this for MSI, but I'd like some more expert
> > opinion than mine :)
> >
> > For MSI we have:
> >
> >   msi_capability_init
> >     msi_setup_entry
> >       entry = alloc_msi_entry(nvec)
> >       entry->msi_attrib.default_irq = dev->irq;     /* Save IOAPIC IRQ */
> >     dev->irq = entry->irq;
> >
> >   pci_msi_shutdown
> >     /* Restore dev->irq to its default pin-assertion IRQ */
> >     dev->irq = desc->msi_attrib.default_irq;
> >
> > and for MSI-X we have:
> >
> >   msix_capability_init
> >     msix_setup_entries
> >       for (i = 0; i < nvec; i++)
> >         entry = alloc_msi_entry(1)
> >       entry->msi_attrib.default_irq = dev->irq;
> >
> >   pci_msix_shutdown
> >     for_each_pci_msi_entry(entry, dev)
> >       __pci_msix_desc_mask_irq
> > +   dev->irq = entry->msi_attrib.default_irq;   # added by this patch
> >
> >
> > Things that seem strange to me:
> >
> >   - The msi_setup_entry() comment "Save IOAPIC IRQ" seems needlessly
> >     specific; maybe it should be "INTx IRQ".
> >
> >   - The pci_msi_shutdown() comment "Restore ... pin-assertion IRQ"
> >     should match the msi_setup_entry() one, e.g., maybe it should also
> >     be "INTx IRQ".  There are no INTx or IOAPIC pins in PCIe.
> >
> >   - The only use of .default_irq is to save and restore dev->irq, so
> >     it looks like a per-device thing, not a per-vector thing.
> >
> >     In msi_setup_entry() there's only one msi_entry, so there's only
> >     one saved .default_irq.
> >
> >     In msix_setup_entries(), we get nvecs msi_entry structs, and we
> >     get a saved .default_irq in each one?
>
> That's a key point.
>
> Old-school PCI/MSI is represented by a single interrupt, and you
> *could* somehow make it relatively easy for drivers that only
> understand INTx to migrate to MSI if you replaced whatever is held in
> dev->irq (which should only represent the INTx mapping) with the MSI
> interrupt number. Which I guess is what the MSI code is doing.
>
> This is the 21st century, and nobody should ever rely on such horror,
> but I'm sure we do have such drivers in the tree. Boo.
>
> However, this *cannot* hold true for Multi-MSI, nor MSI-X, because
> there is a plurality of interrupts. Even worse, for MSI-X, there is
> zero guarantee that the allocated interrupts will be in a contiguous
> space.
>
> Given that, what is dev->irq good for? "Absolutely Nothing! (say it
> again!)".
>
> MSI-X is not something you can "accidentally" use. You have to
> actively embrace it. In all honesty, this patch tries to move in the
> wrong direction. If anything, we should kill this hack altogether and
> fix the (handful of?) drivers that rely on it. That'd actually be a
> good way to find whether they are still worth keeping in the tree. And
> if it breaks too many of them, then at least we'll know where we
> stand.
>
> I'd be tempted to leave the below patch simmer in -next for a few
> weeks and see if how many people shout:
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index e5e75331b415..2be9a01cbe72 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -591,7 +591,6 @@ msi_setup_entry(struct pci_dev *dev, int nvec, struct irq_affinity *affd)
>         entry->msi_attrib.is_virtual    = 0;
>         entry->msi_attrib.entry_nr      = 0;
>         entry->msi_attrib.maskbit       = !!(control & PCI_MSI_FLAGS_MASKBIT);
> -       entry->msi_attrib.default_irq   = dev->irq;     /* Save IOAPIC IRQ */
>         entry->msi_attrib.multi_cap     = (control & PCI_MSI_FLAGS_QMASK) >> 1;
>         entry->msi_attrib.multiple      = ilog2(__roundup_pow_of_two(nvec));
>
> @@ -682,7 +681,6 @@ static int msi_capability_init(struct pci_dev *dev, int nvec,
>         dev->msi_enabled = 1;
>
>         pcibios_free_irq(dev);
> -       dev->irq = entry->irq;
>         return 0;
>  }
>
> @@ -742,7 +740,6 @@ static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
>                 entry->msi_attrib.is_virtual =
>                         entry->msi_attrib.entry_nr >= vec_count;
>
> -               entry->msi_attrib.default_irq   = dev->irq;
>                 entry->mask_base                = base;
>
>                 addr = pci_msix_desc_addr(entry);
> @@ -964,8 +961,6 @@ static void pci_msi_shutdown(struct pci_dev *dev)
>         mask = msi_mask(desc->msi_attrib.multi_cap);
>         msi_mask_irq(desc, mask, 0);
>
> -       /* Restore dev->irq to its default pin-assertion IRQ */
> -       dev->irq = desc->msi_attrib.default_irq;
>         pcibios_alloc_irq(dev);
>  }
>
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index e8bdcb83172b..a631664c1c38 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -114,7 +114,6 @@ struct ti_sci_inta_msi_desc {
>   * @maskbit:   [PCI MSI/X] Mask-Pending bit supported?
>   * @is_64:     [PCI MSI/X] Address size: 0=32bit 1=64bit
>   * @entry_nr:  [PCI MSI/X] Entry which is described by this descriptor
> - * @default_irq:[PCI MSI/X] The default pre-assigned non-MSI irq
>   * @mask_pos:  [PCI MSI]   Mask register position
>   * @mask_base: [PCI MSI-X] Mask register base address
>   * @platform:  [platform]  Platform device specific msi descriptor data
> @@ -148,7 +147,6 @@ struct msi_desc {
>                                 u8      is_64           : 1;
>                                 u8      is_virtual      : 1;
>                                 u16     entry_nr;
> -                               unsigned default_irq;
>                         } msi_attrib;
>                         union {
>                                 u8      mask_pos;
>

We will also need the below change as  pci_irq_vector() depends on
dev->irq for the MSI case.

int pci_irq_vector(struct pci_dev *dev, unsigned int nr)
{
        if (dev->msix_enabled) {
                struct msi_desc *entry;
                int i = 0;

                for_each_pci_msi_entry(entry, dev) {
                        if (i == nr)
                                return entry->irq;
                        i++;
                }
                WARN_ON_ONCE(1);
                return -EINVAL;
        }

        if (dev->msi_enabled) {
                struct msi_desc *entry = first_pci_msi_entry(dev);

                if (WARN_ON_ONCE(nr >= entry->nvec_used))
                        return -EINVAL;

+                return entry->irq + nr;
        } else {
                if (WARN_ON_ONCE(nr > 0))
                        return -EINVAL;
        }


-        return dev->irq + nr;
+       return dev->irq;
}
EXPORT_SYMBOL(pci_irq_vector);

> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Thanks
barry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ