linux-kernel - Re: [PATCH v2 0/3] genirq: Managed affinity fixes

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] [day] [month] [year] [list]

Date:   Wed, 23 Mar 2022 11:31:27 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Xiongfeng Wang <wangxiongfeng2@...wei.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Garry <john.garry@...wei.com>,
        David Decotigny <ddecotig@...gle.com>
Subject: Re: [PATCH v2 0/3] genirq: Managed affinity fixes

On Wed, 23 Mar 2022 10:58:33 +0000,
Xiongfeng Wang <wangxiongfeng2@...wei.com> wrote:
> 
> 
> 
> On 2022/3/23 16:56, Marc Zyngier wrote:
> > Hi Xiongfeng,
> > 
> > On Wed, 23 Mar 2022 03:52:46 +0000,
> > Xiongfeng Wang <wangxiongfeng2@...wei.com> wrote:
> >>
> >> Hi, Marc
> >>
> >> On 2022/3/22 3:36, Marc Zyngier wrote:
> >>> John (and later on David) reported[1] a while ago that booting with
> >>> maxcpus=1, managed affinity devices would fail to get the interrupts
> >>> that were associated with offlined CPUs.
> >>>
> >>> Similarly, Xiongfeng reported[2] that the GICv3 ITS would sometime use
> >>> non-housekeeping CPUs instead of the affinity that was passed down as
> >>> a parameter.
> >>>
> >>> [1] can be fixed by not trying to activate these interrupts if no CPU
> >>> that can satisfy the affinity is present (a patch addressing this was
> >>> already posted[3])
> >>>
> >>> [2] is a consequence of affinities containing non-online CPUs being
> >>> passed down to the interrupt controller driver and the ITS driver
> >>> trying to paper over that by ignoring the affinity parameter and doing
> >>> its own (stupid) thing. It would be better to (a) get the core code to
> >>> remove the offline CPUs from the affinity mask at all times, and (b)
> >>> fix the drivers so that they can trust the core code not to trip them.
> >>>
> >>> This small series, based on 5.17, addresses the above.
> >>
> >> I have tested this patchset on D06. It works well with kernel parameter
> >> 'maxcpus=1' or 'nohz_full=1-127 isolcpus=nohz,domain,managed_irq,1-127'.
> >> Also the 'effective_affinity' is correct. Thanks!
> > 
> > Thanks for having given it a go.
> > 
> >> By the way, I merged the second patch manually because of conflicts.
> >> Maybe I lack some patches on your local repo.
> > 
> > That's odd, as the patches are directly sitting on top of 5.17 in my
> > tree (see [1]). Do you have any out of tree patches around? Please
> > make sure you test this without any extra change.
> 
> I apply the patchset based on the latest mainline kernel. The latest commit is
>   commit 3bf03b9a0839c9fb06927ae53ebd0f960b19d408
>   Merge branch 'akpm' (patches from Andrew)
> I didn't change the modification of the second patch. Only resolve the
> context conflicts, which is cause by the following commit.
>   commit 04d4e665a60902cf36e7ad39af1179cb5df542ad
>   sched/isolation: Use single feature type while referring to housekeeping cpumask
> It changed 'HK_FLAG_MANAGED_IRQ' to 'HK_TYPE_MANAGED_IRQ'.

Ah, that's on top of linux/master then. Yeah, I expect some small
conflicts (this is a popular spot). I'll rebase things at some point
once (and if) we agree that patch #2 is the right thing to do.

Thanks,

	M.

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