linux-kernel - Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

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: <alpine.LFD.2.21.1906102253080.19418@eddie.linux-mips.org>
Date:   Wed, 12 Jun 2019 06:55:28 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Aaro Koskinen <aaro.koskinen@....fi>
cc:     Alexandre Oliva <lxoliva@...la.org>, Tom Li <tomli@...li.me>,
        James Hogan <jhogan@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhc@...ote.com>,
        Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform
 Drivers

On Tue, 11 Jun 2019, Aaro Koskinen wrote:

> However, with your patch the "nobody cared" is never reached so all is
> good. I tried 10 boots with the patch and all were successful. Without
> the patch 8 out of 10 failed with the "nobody cared" warning.

 I wouldn't call it "good", just less obvious or painful.  This is still 
causing wasted CPU cycles that are used for taking the phantom interrupts.

 There is clearly a completion barrier missing somewhere that causes the 
interrupt request to linger beyond the point interrupts are reenabled at 
the CPU.

 One way to attempt to narrow it down might be taking a backtrace from 
where IRQ 14 is found to be spurious.  This would indicate the offending 
interrupt unmask action.  E.g. I see no explicit completion barrier 
between the final `outb' in `mask_and_ack_8259A' and the following call to 
`raw_spin_unlock_irqrestore', which are obviously otherwise unordered WRT 
each other (because `outb' is I/O or MMIO and `raw_spin_unlock_irqrestore' 
is contained within the CPU on UP).  I can see provisions however for 
issuing an architecture-specific barrier in `do_raw_spin_unlock', which is 
the workhorse for `raw_spin_unlock_irqrestore', so maybe this is the place 
to look into?

 Also how's IRQ 14 registered as indicated by /proc/interrupts?

  Maciej