linux-kernel - Re: [PATCH v3] MIPS: Implement ieee754 NAN2008 emulation mode

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <ac94941f-3ac3-4820-b94d-aeb72a7a7a5c@app.fastmail.com>
Date: Mon, 15 Jul 2024 20:35:21 +0800
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Jonathan Corbet" <corbet@....net>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 Philippe Mathieu-Daudé <philmd@...aro.org>
Subject: Re: [PATCH v3] MIPS: Implement ieee754 NAN2008 emulation mode

在2024年7月15日七月 下午8:15，Maciej W. Rozycki写道：
[..]
>  I don't know what prctl(2) has to do with this.  If you don't implement 
> this part, then your change will cause Linux to behave inconsistently and 
> therefore I'll have to NAK it.

I think your concern was regarding user space application needs to set NaN2008 bits
at runtime?

In this case, the best interface to inform kernel about NaN2008 changes is prctl.

I may misinterpret your comments.

>
>  It's not much to do anyway, as I have prepared `ptrace_setfcr31' already 
> to handle masking correctly, so all you have to do is to set the mask as 
> required for the right thing to happen.  I shouldn't have needed to point 
> you at it though, as that code is easy to find.

I think I got your point, will try to implement it.

>
>> We are unable to prevent user applications write NAN2008 bits for the "switchable
>> QEMU" as well. So I'd perfer leave it as is, and let this feature go into 6.11 so people
>> can start to use it.
>
>  This doesn't matter either, as your change only addresses the case where 
> FCSR.NAN2008 isn't writable anyway, which is the sole reason you want to 
> switch between native hard float support and emulation, doesn't it?
>
>  In fact where FCSR.NAN2008 is writable your new mode has to be equivalent
> to "ieee754=strict", because then there is no need to trigger emulation 
> for either NaN mode.  Please do verify that this is the case.

This had been verified with perf math-emu counters to ensure no unnecessary emulation
is triggered.

>
>> This is actually a request from Debian MIPS team so they can get glibc tests run on
>> mismatched NaN hardware.
>
>  That doesn't matter for us here (and I have a bad suspicion anyway), but 
> the Debian team is of course free to do what they want here, the GNU GPL 
> applies.

We care about our downstream users, don't we?

There are some lags on Debian buildd queue for mips64el due to lack of high performance
hardware with huge memory.
They were about to source some Loongson 3A4000, which is NaN2008 only. But many packages
test cases are failing on it due to NaN2008.
They asked me to help and that was my solution. I sincerely want to get this change upstreamed
to cover some downstream use cases.

I don't know what theory do you have here, but that's all stories behind.

>
>  And also they can always use the "nofpu" kernel parameter to run their 
> verification.  I used it for mine back at ImgTec before 2008 NaN hardware 
> was available, also to verify emulation, which I wrote too.  Perhaps that 
> is also the right solution for Debian actually?

I'll suggest to them, thanks.

>
>   Maciej

-- 
- Jiaxun