linux-kernel - Re: [PATCH 1/2] cxl/pci: Add generic MSI-X/MSI irq support

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: <20221020223125.hyrfpt2noiicisxa@offworld>
Date:   Thu, 20 Oct 2022 15:31:25 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     dan.j.williams@...el.com, ira.weiny@...el.com,
        dave.jiang@...el.com, alison.schofield@...el.com,
        bwidawsk@...nel.org, vishal.l.verma@...el.com,
        a.manzanares@...sung.com, linux-cxl@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] cxl/pci: Add generic MSI-X/MSI irq support

On Tue, 18 Oct 2022, Jonathan Cameron wrote:

>Reality is that it is cleaner to more or less ignore the infrastructure
>proposed in this patch.
>
>1. Query how many CPMU devices there are. Whilst there stash the maximim
>   cpmu vector number in the cxlds.
>2. Run a stub in this infrastructure that does max(irq, cxlds->irq_num);
>3. Carry on as before.
>
>Thus destroying the point of this infrastructure for that usecase at least
>and leaving an extra bit of state in the cxl_dev_state that is just
>to squirt a value into the callback...

If it doesn't fit, then it doesn't fit.

However, while I was expecting pass one to be in the callback, I wasn't
expecting that both pass 1 and 2 shared the cpmu_regs_array. If the array
could be reconstructed during pass 2, then it would fit a bit better;
albeit the extra allocation, cycles etc., but this is probing phase, so
overhead isn't that important (and cpmu_count isn't big enough to matter).

But if we're going to go with a free-for-all approach, can we establish
who goes for the initial pci_alloc_irq_vectors()? I think perhaps mbox
since it's the most straightforward and with least requirements, I'm
also unsure of the status yet to merge events and pmu, but regardless
they are still larger patchsets. If folks agree I can send a new mbox-only
patch.

Thanks,
Davidlohr