From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Tsai <danielsftsai@google.com>,
Jingoo Han <jingoohan1@gmail.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Andrew Chant" <achant@google.com>,
"Brian Norris" <briannorris@google.com>,
"Sajid Dalvi" <sdalvi@google.com>,
"Mark Cheng" <markcheng@google.com>,
"Ben Cheng" <bccheng@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
"Tsai Sung-Fu" <danielsftsai@google.com>
Subject: Re: [PATCH] PCI: dwc: Chain the set IRQ affinity request back to the parent
Date: Mon, 03 Mar 2025 10:10:04 +0100 [thread overview]
Message-ID: <87a5a2cwer.ffs@tglx> (raw)
In-Reply-To: <20250303070501.2740392-1-danielsftsai@google.com>
On Mon, Mar 03 2025 at 07:05, Daniel Tsai wrote:
> +/*
> + * The algo here honor if there is any intersection of mask of
> + * the existing MSI vectors and the requesting MSI vector. So we
> + * could handle both narrow (1 bit set mask) and wide (0xffff...)
> + * cases, return -EINVAL and reject the request if the result of
> + * cpumask is empty, otherwise return 0 and have the calculated
> + * result on the mask_to_check to pass down to the irq_chip.
> + */
> +static int dw_pci_check_mask_compatibility(struct dw_pcie_rp *pp,
> + unsigned long ctrl,
> + unsigned long hwirq_to_check,
> + struct cpumask *mask_to_check)
> +{
> + unsigned long end, hwirq;
> + const struct cpumask *mask;
> + unsigned int virq;
> +
> + hwirq = ctrl * MAX_MSI_IRQS_PER_CTRL;
> + end = hwirq + MAX_MSI_IRQS_PER_CTRL;
> + for_each_set_bit_from(hwirq, pp->msi_irq_in_use, end) {
> + if (hwirq == hwirq_to_check)
> + continue;
> + virq = irq_find_mapping(pp->irq_domain, hwirq);
> + if (!virq)
> + continue;
> + mask = irq_get_affinity_mask(virq);
What protects @mask against a concurrent modification?
> + if (!cpumask_and(mask_to_check, mask, mask_to_check))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void dw_pci_update_effective_affinity(struct dw_pcie_rp *pp,
> + unsigned long ctrl,
> + const struct cpumask *effective_mask,
> + unsigned long hwirq_to_check)
> +{
> + struct irq_desc *desc_downstream;
> + unsigned int virq_downstream;
> + unsigned long end, hwirq;
> +
> + /*
> + * Update all the irq_data's effective mask
> + * bind to this MSI controller, so the correct
> + * affinity would reflect on
> + * /proc/irq/XXX/effective_affinity
> + */
> + hwirq = ctrl * MAX_MSI_IRQS_PER_CTRL;
> + end = hwirq + MAX_MSI_IRQS_PER_CTRL;
> + for_each_set_bit_from(hwirq, pp->msi_irq_in_use, end) {
> + virq_downstream = irq_find_mapping(pp->irq_domain, hwirq);
> + if (!virq_downstream)
> + continue;
> + desc_downstream = irq_to_desc(virq_downstream);
> + irq_data_update_effective_affinity(&desc_downstream->irq_data,
> + effective_mask);
Same here.
> + }
> +}
> +
> +static int dw_pci_msi_set_affinity(struct irq_data *d,
> + const struct cpumask *mask, bool force)
> +{
> + struct dw_pcie_rp *pp = irq_data_get_irq_chip_data(d);
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + int ret;
> + int virq_parent;
> + unsigned long hwirq = d->hwirq;
> + unsigned long flags, ctrl;
> + struct irq_desc *desc_parent;
> + const struct cpumask *effective_mask;
> + cpumask_var_t mask_result;
> +
> + ctrl = hwirq / MAX_MSI_IRQS_PER_CTRL;
> + if (!alloc_cpumask_var(&mask_result, GFP_ATOMIC))
> + return -ENOMEM;
This does not work on a RT enabled kernel. Allocations with a raw spin
lock held are not possible.
> + /*
> + * Loop through all possible MSI vector to check if the
> + * requested one is compatible with all of them
> + */
> + raw_spin_lock_irqsave(&pp->lock, flags);
> + cpumask_copy(mask_result, mask);
> + ret = dw_pci_check_mask_compatibility(pp, ctrl, hwirq, mask_result);
> + if (ret) {
> + dev_dbg(pci->dev, "Incompatible mask, request %*pbl, irq num %u\n",
> + cpumask_pr_args(mask), d->irq);
> + goto unlock;
> + }
> +
> + dev_dbg(pci->dev, "Final mask, request %*pbl, irq num %u\n",
> + cpumask_pr_args(mask_result), d->irq);
> +
> + virq_parent = pp->msi_irq[ctrl];
> + desc_parent = irq_to_desc(virq_parent);
> + ret = desc_parent->irq_data.chip->irq_set_affinity(&desc_parent->irq_data,
> + mask_result, force);
Again. Completely unserialized.
Thanks,
tglx
next prev parent reply other threads:[~2025-03-03 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 7:05 [PATCH] PCI: dwc: Chain the set IRQ affinity request back to the parent Daniel Tsai
2025-03-03 9:10 ` Thomas Gleixner [this message]
2025-03-04 5:48 ` Tsai Sung-Fu
2025-03-04 9:46 ` Thomas Gleixner
2025-03-05 11:21 ` Tsai Sung-Fu
2025-03-06 7:44 ` Thomas Gleixner
2025-03-07 11:10 ` Tsai Sung-Fu
2025-03-07 19:49 ` Thomas Gleixner
2025-03-11 9:52 ` Tsai Sung-Fu
2025-03-11 14:05 ` Thomas Gleixner
2025-03-25 6:38 ` Tsai Sung-Fu
2025-05-07 11:10 ` Krishna Chaitanya Chundru
2025-03-03 9:25 ` kernel test robot
2025-03-03 10:13 ` kernel test robot
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=87a5a2cwer.ffs@tglx \
--to=tglx@linutronix.de \
--cc=achant@google.com \
--cc=bccheng@google.com \
--cc=bhelgaas@google.com \
--cc=briannorris@google.com \
--cc=danielsftsai@google.com \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=markcheng@google.com \
--cc=robh@kernel.org \
--cc=sdalvi@google.com \
/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.