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
| ||
|
Date: Thu, 6 Oct 2022 15:29:35 -0700 From: Dave Hansen <dave.hansen@...el.com> To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>, linux-kernel@...r.kernel.org, linux-sgx@...r.kernel.org, Jarkko Sakkinen <jarkko@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, Kristen Carlson Accardi <kristen@...ux.intel.com>, ira.weiny@...el.com Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls On 10/6/22 15:02, Fabio M. De Francesco wrote: > On Thursday, October 6, 2022 10:45:56 PM CEST Dave Hansen wrote: > Am I still missing anything fundamental? Yes. :) kmap() users can sleep. That means the number of them that you need to keep around is unbounded. kmap_atomic()'s fundamentally can't sleep so you need fewer of them. That means that when you kunmap_atomic() you can use a simple, fast, CPU-local TLB flushing operation. kunmap() eventually requires a big fat global TLB flush. So, you're right. On lowmem-only systems, kmap() *can* be cheaper than kmap_atomic(). But, on highmem systems there's no contest: kmap_atomic() is king. That's why kmap_atomic() is and should be the default. >> You use kmap_atomic() *always* unless you _need_ to sleep or one >> of the other kmap()-only things. > > What would happen if you rely on switching in atomic as a side effect of > kmap_atomic() and then you convert to kmap_local_page() without explicitly > disabling, for example, preemption since who converts don't care to know if > the code is in atomic before calling kmap_atomic() before or after the call > (as I said there may be cases where non atomic execution must disable > preemption for some reasons only between the mapping and the unmapping? > > If I were a maintainer I wouldn't trust changes that let me think that the > developer can't tell if we need to disable something while converting to > kmap_local_page(). In this case, it's just not that complicated. The SGX code isn't relying on anything subtle that kmap_local_page() does not provide.
Powered by blists - more mailing lists