linux-kernel - Re: I/O page faults from 8250_mid PCIe UART after TIOCVHANGUP

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:   Mon, 19 Sep 2022 17:22:32 +0300
From:   Lennert Buytenhek <buytenh@...tstofly.org>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: I/O page faults from 8250_mid PCIe UART after TIOCVHANGUP

On Mon, Sep 19, 2022 at 05:19:35PM +0300, Ilpo Järvinen wrote:

> > > > [...] I'm far from sure if it's the 
> > > > best fix though as I don't fully understand what causes the faults during 
> > > > the THRE tests because the port->irq is disabled by the THRE test block.
> > > 
> > > If the IRQ hasn't been set up yet, the UART will have zeroes in its MSI
> > > address/data registers.  Disabling the IRQ at the interrupt controller
> > > won't stop the UART from performing a DMA write to the address programmed
> > > in its MSI address register (zero) when it wants to signal an interrupt.
> > > 
> > > (These UARTs (in Ice Lake-D) implement PCI 2.1 style MSI without masking
> > > capability, so there is no way to mask the interrupt at the source PCI
> > > function level, except disabling the MSI capability entirely, but that
> > > would cause it to fall back to INTx# assertion, and the PCI specification
> > > prohibits disabling the MSI capability as a way to mask a function's
> > > interrupt service request.)
> > 
> > This sounds to me like a good part to be injected into commit message of
> > the proposed fix.
> 
> I added my own wording already but I could adds of Lennert's far superior 
> descriptions verbatim if he is OK with that?

No objections from me.