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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Feb 2019 14:07:26 +0000 From: Julien Grall <julien.grall@....com> To: Julia Cartwright <julia@...com> Cc: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "bigeasy@...utronix.de" <bigeasy@...utronix.de>, "Dave.Martin@....com" <Dave.Martin@....com>, "linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>, "catalin.marinas@....com" <catalin.marinas@....com>, "will.deacon@....com" <will.deacon@....com>, "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state On 12/02/2019 17:13, Julia Cartwright wrote: > Hello Julien- Hello Julien, > > On Fri, Feb 08, 2019 at 04:55:13PM +0000, Julien Grall wrote: >> When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of >> the kernel may be able to use FPSIMD/SVE. This is for instance the case >> for crypto code. >> >> Any use of FPSIMD/SVE in the kernel are clearly marked by using the >> function kernel_neon_{begin, end}. Furthermore, this can only be used >> when may_use_simd() returns true. >> >> The current implementation of may_use_simd() allows softirq to use >> FPSIMD/SVE unless it is currently in used (i.e kernel_neon_busy is true). >> When in used, softirqs usually fallback to a software method. >> >> At the moment, as a softirq may use FPSIMD/SVE, softirqs are disabled >> when touching the FPSIMD/SVE context. This has the drawback to disable >> all softirqs even if they are not using FPSIMD/SVE. >> >> As a softirq should not rely on been able to use simd at a given time, >> there are limited reason to keep softirq disabled when touching the >> FPSIMD/SVE context. Instead, we can only disable preemption and tell >> the NEON unit is currently in use. >> >> This patch introduces two new helpers kernel_neon_{disable, enable} to >> mark the area using FPSIMD/SVE context and use them in replacement of >> local_bh_{disable, enable}. The functions kernel_neon_{begin, end} are >> also re-implemented to use the new helpers. >> >> Signed-off-by: Julien Grall <julien.grall@....com> >> >> --- >> >> I have been exploring this solution as an alternative approach to the RT >> patch "arm64: fpsimd: use preemp_disable in addition to local_bh_disable()". >> >> So far, the patch has only been lightly tested. >> >> For RT-linux, it might be possible to use migrate_{enable, disable}. I >> am quite new with RT and have some trouble to understand the semantics >> of migrate_{enable, disable}. So far, I am still unsure if it is possible >> to run another userspace task on the same CPU while getting preempted >> when the migration is disabled. > > Yes, a thread in a migrate_disable()-protected critical section can be > preempted, and another thread on the same CPU may enter the critical > section. > > If it's necessary to prevent this from happening, then you need to also > make use of a per-CPU mutex. On RT, this would do the right thing > w.r.t. priority inheritance. Thank you for the explanation, I now understand better the concept of migrate_disable. Best regards, -- Julien Grall
Powered by blists - more mailing lists