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.DEB.2.21.2503211747150.35806@angie.orcam.me.uk>
Date: Fri, 21 Mar 2025 20:11:40 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Marco Crivellari <marco.crivellari@...e.com>
cc: linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Frederic Weisbecker <frederic@...nel.org>, 
    Anna-Maria Behnsen <anna-maria@...utronix.de>, 
    Thomas Gleixner <tglx@...utronix.de>, 
    Peter Zijlstra <peterz@...radead.org>, Huacai Chen <chenhuacai@...nel.org>
Subject: Re: [PATCH v6 1/1] MIPS: Fix idle VS timer enqueue

On Fri, 21 Mar 2025, Marco Crivellari wrote:

> >  This instruction sequence still suffers from the coprocessor move delay
> > hazard.  How many times do I need to request to get it fixed (counting
> > three so far)?
> 
> Can I have more details about this?
> 
> I can see it is the same code present also in local_irq_enable()
> (arch_local_irq_enable()),

 Unlike `__r4k_wait' that code is not in a `.set noreorder' region and 
the assembler will therefore resolve the hazard by inserting a NOP where 
required by the architecture level requested (with `-march=...', etc.).  
Try compiling that function for a MIPS III configuration such as 
decstation_r4k_defconfig or just by hand with `-march=mips3' and see 
what machine code is produced.

> and from the manual I've seen:
> 
> "The Spacing column shown in Table 2.6 and Table 2.7 indicates the
> number of unrelated instructions (such as NOPs or SSNOPs) that,
> prior to the capabilities of Release 2, would need to be placed
> between the producer and consumer of the hazard in order to ensure
> that the effects of the first instruction are seen by the second instruction."
> 
> The "Spacing column" value is 3, indeed.
> 
> "With the hazard elimination instructions available in Release 2, the
> preferred method to eliminate hazards is to place one of the
> instructions listed in Table 2.8 between the producer and consumer of the
> hazard. Execution hazards can be removed by using the EHB [...]"

 Whatever manual you quote it refers to MIPS Release 2, which is only 
dated 2003 (following Release 1 from 2001), but `__r4k_wait' has to 
continue handling older architecture revisions going back to MIPS III 
ISA from 1991.  We also support MIPS I ISA from 1985 which has further 
instruction scheduling requirements, but `__r4k_wait' is for newer 
processors only, because older ones had no WAIT instruction, so we can 
ignore them (but note that the MIPS I load delay slot is regardless 
observed in current code in the form of a NOP inserted after LONG_L).

> What am I missing?

 This is common MIPS knowledge really, encoded in the GNU toolchain and 
especially GAS since forever.  While I can't cite a canonical reference, 
the hazard is listed e.g. in Table 13.1 "Instructions with scheduling 
implications" and Table 13.3 "R4xxx/R5000 Coprocessor 0 Hazards" from 
"IDT MIPS Microprocessor Family Software Reference Manual," Version 2.0, 
from October 1996.  I do believe the document is available online.

 I'm fairly sure the hazard is also listed there in Dominic Sweetman's 
"See MIPS Run Linux," but I don't have my copy handy right now.

 Best is to avoid using a `.set noreorder' region in the first place.  
But is it really needed here?  Does the rollback area have to be of a 
hardcoded size rather than one calculated by the assembler based on 
actual machine code produced?  It seems to me having it calculated would 
reduce complexity here and let us use the EI instruction where available 
as well.

 HTH,

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ