linux-kernel - Re: PCI MSI issue for maxcpus=1

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: <1cbe7daa-8003-562b-06fa-5a50f7ee6ed2@huawei.com>
Date:   Fri, 4 Mar 2022 12:53:31 +0000
From:   John Garry <john.garry@...wei.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        chenxiang <chenxiang66@...ilicon.com>,
        Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "liuqi (BA)" <liuqi115@...wei.com>, <wangxiongfeng2@...wei.com>
Subject: Re: PCI MSI issue for maxcpus=1

> ...

> 
> [ 7.961007]  valid_col+0x14/0x24
> [ 7.964223]  its_send_single_command+0x4c/0x150
> [ 7.968741]  its_irq_domain_activate+0xc8/0x104
> [ 7.973259]  __irq_domain_activate_irq+0x5c/0xac
> [ 7.977865]  __irq_domain_activate_irq+0x38/0xac
> [ 7.982471]  irq_domain_activate_irq+0x3c/0x64
> [ 7.986902]  __msi_domain_alloc_irqs+0x1a8/0x2f4
> [ 7.991507]  msi_domain_alloc_irqs+0x20/0x2c
> [ 7.995764]  __pci_enable_msi_range+0x2ec/0x590
> [ 8.000284]  pci_alloc_irq_vectors_affinity+0xe0/0x140
> [ 8.005410]  hisi_sas_v3_probe+0x300/0xbe0
> [ 8.009494]  local_pci_probe+0x44/0xb0
> [ 8.013232]  work_for_cpu_fn+0x20/0x34
> [ 8.016969]  process_one_work+0x1d0/0x354
> [ 8.020966]  worker_thread+0x2c0/0x470
> [ 8.024703]  kthread+0x17c/0x190
> [ 8.027920]  ret_from_fork+0x10/0x20
> [ 8.031485] ---[ end trace bb67cfc7eded7361 ]---
> 

...

> Ah, of course. the CPU hasn't booted yet, so its collection isn't
> mapped. I was hoping that the core code would keep the interrupt in
> shutdown state, but it doesn't seem to be the case...
> 
>  > Apart from this, I assume that if another cpu comes online later in
>  > the affinity mask I would figure that we want to target the irq to
>  > that cpu (which I think we would not do here).
> 
> That's probably also something that should come from core code, as
> we're not really in a position to decide this in the ITS driver.
> .


Hi Marc,

Have you had a chance to consider this issue further?

So I think that x86 avoids this issue as it uses matrix.c, which handles 
CPUs being offline when selecting target CPUs for managed interrupts.

So is your idea still that core code should keep the interrupt in 
shutdown state (for no CPUs online in affinity mask)?

Thanks,
John