linux-kernel - Re: [PATCH] arm64: mm: force write fault for atomic RMW instructions

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]

Date: Mon, 13 May 2024 15:39:46 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Anshuman Khandual <anshuman.khandual@....com>
cc: Yang Shi <yang@...amperecomputing.com>, catalin.marinas@....com, 
    will@...nel.org, scott@...amperecomputing.com, 
    linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: mm: force write fault for atomic RMW
 instructions

On Thu, 9 May 2024, Anshuman Khandual wrote:

>
>>> Okay, I was about to ask, but is not calling get_user() for all data
>>> read page faults increase the cost for a hot code path in general for
>>> some potential savings for a very specific use case. Not sure if that
>>> is worth the trade-off.
>>
>> The instruction is cache hot since it must be present in the cpu cache for the fault. So the overhead is minimal.
>>
>
> But could not a pagefault_disable()-enable() window prevent concurring
> page faults for the current process thus degrading its performance.

The cpu is already executing a fault handler in kernel space. There cannot 
be an additional user space fault since we do not execute that code 
currently.