linux-kernel - Re: [PATCH] PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled

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]

Date:   Wed, 14 Mar 2018 20:17:07 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-pci@...r.kernel.org, Mikael Starvik <starvik@...s.com>,
        Jesper Nilsson <jesper.nilsson@...s.com>,
        Tony Luck <tony.luck@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        David Howells <dhowells@...hat.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Cris <linux-cris-kernel@...s.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-ia64@...r.kernel.org, linux-am33-list@...hat.com
Subject: Re: [PATCH] PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled

On Wed, Mar 14, 2018 at 7:49 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:
> On Wed, Mar 14, 2018 at 06:31:38PM +0200, Andy Shevchenko wrote:
>> On Tue, Mar 13, 2018 at 11:45 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:

>> > If a device already has MSI or MSI-X enabled, there's no need to set up its
>> > legacy INTx interrupt.
>>
>> Just point to the actual behaviour of this.
>
> By "point to the actual behaviour", do you mean adding something to
> the changelog along the lines of the following?
>
>   If MSI or MSI-X is enabled, the device uses that.  It uses INTx only
>   if both MSI and MSI-X are disabled (see PCIe r4.0, sec 7.7.1.2).
>
> I did add that because I think that spec reference is useful.  If you
> have something else in mind, maybe an example would help me
> understand.

I meant that the behaviour now is changed from
 check MSI only case
to
 check MSI _or MSI-x_ case

Not all code paths may survive that.

>> In some cases code in question has to distinguish between MSI and
>> MSI-x.  So, this or similar changes has to be done with keeping
>> above in mind.
>>
>> (Existing example is Thunderbolt driver)
>
> Sorry, I didn't get your point here.  Certainly some code needs to
> distinguish between MSI and MSI-X, but I don't think that's the case
> here.  I'm not proposing to change Thunderbolt; I do see that it uses
> dev->msix_enabled (but not dev->msi_enabled), and it doesn't look like
> using pci_dev_msi_enabled() there would be appropriate.

Exactly, that's why I pointed on above.

-- 
With Best Regards,
Andy Shevchenko