linux-kernel - Re: [PATCH v2] PCI/MSI: Avoid torn updates to MSI pairs

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: <87y2tytv5i.fsf@nanos.tec.linutronix.de>
Date:   Thu, 23 Jan 2020 09:49:13 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Evan Green <evgreen@...omium.org>, Rajat Jain <rajatja@...gle.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] PCI/MSI: Avoid torn updates to MSI pairs

Evan Green <evgreen@...omium.org> writes:
> In my experiments, the driver no longer misses the interrupt. XHCI is
> particularly sensitive to this, if it misses one interrupt it seems to
> completely wedge the driver.

That does not make the approach more correct.

> I think in my case the device pends the interrupts until MSIs are
> re-enabled, because I don't see anything other than MSI for xhci in
> /proc/interrupts. But I'm not sure if other devices may fall back to
> line-based interrupts for a moment, and if that's a problem.

Yes they can according to standard and it _IS_ a problem.

> Although, I already see we call pci_msi_set_enable(0) whenever we set
> up MSIs, presumably for this same reason of avoiding torn MSIs.

Please stop making random assumptions. This as absolutely nothing to do
with torn MSIs. The way how MSI setup works requires this. And this is
happening on init _before_ any interrupt can be requested on the device.
Different reason, different context.

> So my fix is really just doing the same thing for an additional
> case.

No, it's absolutely not the same. Your device is active and not in
reset/init state.

> And if getting stuck in a never-to-be-handled line based interrupt
> were a problem, you'd think it would also be a problem in
> pci_restore_msi_state(), where the same thing is done.

Again. I told you already it's not the same thing.

> Maybe my fix is at the wrong level, and should be up in
> pci_msi_domain_write_msg() instead? Though I see a lot of callers to
> pci_write_msi_msg() that I worry have the same problem.

This is not yet debugged fully and as this is happening on MSI-X I'm not
really convinced yet that your 'torn write' theory holds.

Thanks,

        tglx