From: Megha Dey <megha.dey@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, marc.zyngier@arm.com,
ashok.raj@intel.com, jacob.jun.pan@linux.intel.com
Subject: Re: [RFC V1 RESEND 5/6] PCI/MSI: Free MSI-X resources by group
Date: Mon, 12 Aug 2019 11:13:44 -0700 [thread overview]
Message-ID: <1565633624.7042.23.camel@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908110912470.7324@nanos.tec.linutronix.de>
On Sun, 2019-08-11 at 09:18 +0200, Thomas Gleixner wrote:
> On Tue, 6 Aug 2019, Megha Dey wrote:
>
> >
> > On Sat, 2019-06-29 at 10:08 +0200, Thomas Gleixner wrote:
> > >
> > > Megha,
> > >
> > > On Fri, 21 Jun 2019, Megha Dey wrote:
> > > >
> > > >
> > > > +static int free_msi_irqs_grp(struct pci_dev *dev, int
> > > > group_id)
> > > > +{
> > > >
> > > > +
> > > > + for_each_pci_msi_entry(entry, dev) {
> > > > + if (entry->group_id == group_id && entry->irq)
> > > > + for (i = 0; i < entry->nvec_used; i++)
> > > > + BUG_ON(irq_has_action(entry-
> > > > >irq +
> > > > i));
> > > BUG_ON is wrong here. This can and must be handled gracefully.
> > >
> > Hmm, I reused this code from the 'free_msi_irqs' function. I am not
> > sure why it is wrong to use BUG_ON here but ok to use it there,
> > please
> > let me know.
> We are not adding BUG_ON() anymore except for situations where there
> is
> absolutely no way out. Just because there is still older code having
> BUG_ON() does not make it any better. Copying it surely is no
> justification.
>
> If there is really no way out, then you need to explain it.
>
Ok, got it. I will look into it closely to see if the BUG_ON is
absolutely required.
>
> >
> > >
> > > >
> > > > +static void pci_msix_shutdown_grp(struct pci_dev *dev, int
> > > > group_id)
> > > > +{
> > > > + struct msi_desc *entry;
> > > > + int grp_present = 0;
> > > > +
> > > > + if (pci_dev_is_disconnected(dev)) {
> > > > + dev->msix_enabled = 0;
> > > Huch? What's that? I can't figure out why this is needed and of
> > > course it
> > > completely lacks a comment explaining this.
> > >
> > Again, I have reused this code from the pci_msix_shutdown()
> > function.
> > So for the group case, this is not required?
> Copy and paste is not an argument, really. Can this happen here? If
> so,
> then please add a comment.
>
Ok, will do.
> >
> > >
> > > >
> > > >
> > > > + return;
> > > > + }
> > > > +
> > > > + /* Return the device with MSI-X masked as initial
> > > > states
> > > > */
> > > > + for_each_pci_msi_entry(entry, dev) {
> > > > + if (entry->group_id == group_id) {
> > > > + /* Keep cached states to be restored
> > > > */
> > > > + __pci_msix_desc_mask_irq(entry, 1);
> > > > + grp_present = 1;
> > > > + }
> > > > + }
> > > > +
> > > > + if (!grp_present) {
> > > > + pci_err(dev, "Group to be disabled not
> > > > present\n");
> > > > + return;
> > > So you print an error and silently return
> > >
> > This is a void function, hence no error value can be returned. What
> > do
> > you think is the right thing to do if someone wants to delete a
> > group
> > which is not present?
> Well, you made it a void function.
ok sure, got your point.
>
> >
> > >
> > > >
> > > >
> > > > + }
> > > > +}
> > > > +
> > > > +int pci_disable_msix_grp(struct pci_dev *dev, int group_id)
> > > > +{
> > > > + int num_vecs;
> > > > +
> > > > + if (!pci_msi_enable || !dev)
> > > > + return -EINVAL;
> > > > +
> > > > + pci_msix_shutdown_grp(dev, group_id);
> > > > + num_vecs = free_msi_irqs_grp(dev, group_id);
> > > just to call in another function which has to do the same
> > > group_id
> > > lookup
> > > muck again.
> > Even with the new proposal, we are to have 2 sets of functions: one
> > to
> > delete all the msic_desc entries associated with the device, and
> > the
> > other to delete those only belonging a 'user specified' group. So
> > we do
> > need to pass a group_id to these functions right? Yes, internally
> > the
> > deletion would be straightforward with the new approach.
> That does not matter. If pci_msix_shutdown_grp() does not find a
> group, why
> proceeding instead of having a proper error return and telling the
> caller?
>
Oh ok, I got it now, I will return a proper error code in the
pci_msi_shutdown_grp and do the free_msi_irqs_grp only if the group is
found.
> Thanks,
>
> tglx
next prev parent reply other threads:[~2019-08-12 17:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-22 0:19 [RFC V1 RESEND 0/6] Introduce dynamic allocation/freeing of MSI-X vectors Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 1/6] PCI/MSI: New structures/macros for dynamic MSI-X allocation Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 2/6] PCI/MSI: Dynamic allocation of MSI-X vectors by group Megha Dey
2019-06-29 7:59 ` Thomas Gleixner
2019-08-06 19:05 ` Megha Dey
2019-08-07 13:56 ` Thomas Gleixner
2019-08-07 14:18 ` Marc Zyngier
2019-08-11 7:20 ` Thomas Gleixner
2019-08-12 17:54 ` Megha Dey
2019-08-12 17:48 ` Megha Dey
2019-08-12 17:47 ` Megha Dey
2021-01-07 22:30 ` Jacob Keller
2019-06-22 0:19 ` [RFC V1 RESEND 3/6] x86: Introduce the dynamic teardown function Megha Dey
2019-06-29 8:01 ` Thomas Gleixner
2019-08-06 19:06 ` Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 4/6] PCI/MSI: Introduce new structure to manage MSI-x entries Megha Dey
2019-06-22 0:19 ` [RFC V1 RESEND 5/6] PCI/MSI: Free MSI-X resources by group Megha Dey
2019-06-29 8:08 ` Thomas Gleixner
2019-08-06 19:09 ` Megha Dey
2019-08-11 7:18 ` Thomas Gleixner
2019-08-12 18:13 ` Megha Dey [this message]
2019-06-22 0:19 ` [RFC V1 RESEND 6/6] Documentation: PCI/MSI: Document dynamic MSI-X infrastructure Megha Dey
2019-08-02 0:24 ` [RFC V1 RESEND 0/6] Introduce dynamic allocation/freeing of MSI-X vectors Bjorn Helgaas
2019-08-06 19:12 ` Megha Dey
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=1565633624.7042.23.camel@intel.com \
--to=megha.dey@intel.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.