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.1903071744560.7728@eddie.linux-mips.org>
Date:   Thu, 7 Mar 2019 17:59:42 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Alexandre Oliva <lxoliva@...la.org>
cc:     Aaro Koskinen <aaro.koskinen@....fi>, 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

Hi Alexandre,

 I'm away on holiday and also connectivity is so-so here, so just a quick 
reply.

> >  Is there an MMIO completion barrier missing there somewhere by any chance 
> > causing an IRQ that has been handled already to be redelivered because an 
> > MMIO write meant to clear the IRQ at its origin at handler's completion 
> > has not reached its destination before interrupts have been reenabled in 
> > the issuing CPU?  Just a thought.
> 
> I've finally got a chance to bisect the IRQ14 (nobody cared) regression
> on my yeeloong.  It took me to MIPS: Enforce strong ordering for MMIO
> accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f).

 Thanks for looking into it.

> I've only just started trying to figure out what exactly in the change
> leads to problems.  So far, I've determined that changing both uses of
> __BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1
> removes the undesirable effects, both on top of that patch, and on top
> of v5.0:
> 
>  #define __BUILD_IOPORT_PFX(bus, bwlq, type)				\
> - 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)			\
> - 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
> +	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,)			\
> +	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p)

 So this seems backwards to me, port I/O is supposed to be strongly 
ordered, so if removing the ordering guarantee "fixes" your problem, then 
there must be a second bottom here.  Offhand either there is a race 
condition somewhere which the lack of ordering here covers somehow, or 
there is a silicon erratum of some sort somewhere that the SYNC 
instruction triggers.

 A further investigation is required I'm afraid.  Does your platform use 
`war_io_reorder_wmb'?

  Maciej