Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3dfccc80-e089-4915-d57e-96d26b237182@intel.com>
Date:   Thu, 6 Oct 2022 15:29:35 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls
Content-Language: en-US
To:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        Kristen Carlson Accardi <kristen@linux.intel.com>,
        ira.weiny@intel.com
References: <20220929160647.362798-1-kristen@linux.intel.com>
 <3694452.kQq0lBPeGt@mypc> <d64e6e9f-27b9-9bbb-aaf8-fca1681eada5@intel.com>
 <8124835.T7Z3S40VBb@mypc>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <8124835.T7Z3S40VBb@mypc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.