linux-kernel - Re: [PATCH v3 1/2] x86/ioremap: fix the pfn calculation mistake in __ioremap_check

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]

Date:   Fri, 2 Jul 2021 18:05:02 +0800
From:   Yaohui Wang <yaohuiwang@...ux.alibaba.com>
To:     Dave Hansen <dave.hansen@...el.com>, tglx@...utronix.de
Cc:     luto@...nel.org, peterz@...radead.org, mingo@...hat.com,
        bp@...en8.de, x86@...nel.org, linux-kernel@...r.kernel.org,
        luoben@...ux.alibaba.com, Tom Lendacky <thomas.lendacky@....com>,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v3 1/2] x86/ioremap: fix the pfn calculation mistake in
 __ioremap_check_ram()

On 2021/7/1 22:41, Dave Hansen wrote:
> Was this issue found by inspection, or is it causing an actual problem
> in practice?

This issus truly caused terrible perforamnce downgrade in the practice.
When developing an out of tree module in our testing environment,
invoking ioremap() on normal RAM causes apparent CLI lag. The Unixbench
score also decreases a lot (5x slowdown in the worst case).

Debugging such performance issue is extremely difficult, especially when
the code of the faulty module itself is already very complex. I tested
the system in many aspects before finally located this problem.

> Also, it would be really nice to include the original authors when you
> send Fixes: for patches.  BTW, scripts/get_maintainer.pl would have done
> this for you.  I've added Tom and Brijesh.  Please cc them in the future.

I'll pay attention to this in the future. Thank you for your time and
patience!