linux-kernel - Re: [PATCH] PCI: dwc: Chain the set IRQ affinity request back to the parent

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]

Message-ID: <CAK7fddBSJk61h2t73Ly9gxNX22cGAF46kAP+A2T5BU8VKENceQ@mail.gmail.com>
Date: Tue, 11 Mar 2025 17:52:41 +0800
From: Tsai Sung-Fu <danielsftsai@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Jingoo Han <jingoohan1@...il.com>, 
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kw@...ux.com>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Andrew Chant <achant@...gle.com>, 
	Brian Norris <briannorris@...gle.com>, Sajid Dalvi <sdalvi@...gle.com>, 
	Mark Cheng <markcheng@...gle.com>, Ben Cheng <bccheng@...gle.com>, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Marc Zyngier <maz@...nel.org>
Subject: Re: [PATCH] PCI: dwc: Chain the set IRQ affinity request back to the parent

Running some basic tests with this patch (
https://tglx.de/~tglx/patches.tar ) applied on my device, at first
glance, the affinity feature is working.

I didn't run stress test to test the stability, and the Kernel version
we used is a bit old, so I only applied change in this 2 patches

-> Subject: genirq: Add interrupt redirection infrastructure
-> Subject: PCI: dwc: Enable MSI affinity support

And adding if check on irq_chip_redirect_set_affinity() and
irq_set_redirect_target() to avoid cpumask_first() return nr_cpu_ids

int irq_chip_redirect_set_affinity(struct irq_data *data, const struct
cpumask *dest, bool force) {
     ....
     ....
     if (target >= nr_cpu_ids)
          target = smp_processor_id();
     irq_data_update_effective_affinity(data, cpumask_of(target));
}

static void irq_set_redirect_target(struct irq_desc *desc)
{
    const struct cpumask *m =
irq_data_get_effective_affinity_mask(&desc->irq_data);
    unsigned int cpu = cpumask_first(m);

    if (cpu >= nr_cpu_ids)
       cpu = smp_processor_id();

    WRITE_ONCE(desc->redirect.target_cpu, cpu);
}

May I ask, would this patch be officially added to the 6.14 kernel ?

Thanks

On Sat, Mar 8, 2025 at 3:49 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Fri, Mar 07 2025 at 19:10, Tsai Sung-Fu wrote:
> > Thanks for your detailed explanation and feedback, I am a bit confused about the
> > #4 you mentioned here ->
> >
> >>     4) Affinity of the demultiplex interrupt
> >
> > Are you saying there is a chance to queue this demultiplexing IRQ event
> > to the current running CPU ?
>
> The demultiplexing interrupt (currently a chained handler, which is
> hidden from /proc/irq/) stays at the affinity which the kernel decided
> to assign to it at startup. That means it can't be steered to a
> particual CPU and nobody knows to which CPU it is affine. You can only
> guess it from /proc/interrupts by observing where the associated
> demultiplex interrupts are affine to.
>
> So ideally you want to be able to affine the demultiplexing interrupt
> too. That requires to switch it to a regular interrupt for
> simplicity. We could expose those hidden chained handlers affinity too,
> but that needs some surgery vs. locking etc.
>
> > And that's really an approach worth to try, I will work on it.
>
> I've played with this on top of variant of Marc's changes to use MSI
> parent interrupts for such controllers too:
>
>   https://lore.kernel.org/all/20241204124549.607054-1-maz@kernel.org/
>
> A completely untested and largely uncompiled preview is here:
>
>      https://tglx.de/~tglx/patches.tar
>
> The MSI parent parts are in flux. Marc will look at them in the next
> weeks, but I picked them up because it simplifies the whole business a
> lot. If you find bugs in that series, you can keep them :)
>
> Thanks,
>
>         tglx