public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	jarkko@kernel.org, ira.weiny@intel.com,
	dave.hansen@linux.intel.com, linux-sgx@vger.kernel.org,
	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>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86/sgx: Replace kmap/kunmap_atomic calls
Date: Wed, 16 Nov 2022 12:58:41 +0100	[thread overview]
Message-ID: <87cz9nqff2.ffs@tglx> (raw)
In-Reply-To: <CAPj211ugzBFJHgDNtSgR2zB7ZcGa_EqOAQGhFSu938718u+yMQ@mail.gmail.com>

On Wed, Nov 16 2022 at 11:16, Fabio M. De Francesco wrote:
> On martedì 15 novembre 2022 17:16:26 CET Kristen Carlson Accardi wrote:
>> The use of kmap_atomic() in the SGX code was not an explicit design
>> choice to disable page faults or preemption, and there is no compelling
>> design reason to using kmap_atomic() vs. kmap_local_page().
>
> This is at the core of the reasons why you are converting, that is to avoid
> the potential overhead (in 32 bit architectures) of switching in atomic
> context where it is not required.

No. The point is that kmap_atomic() is an historical artifact of 32bit
HIGHMEM support.

The back then chosen implementation was to disable preemption and
pagefaults and use a temporary per CPU mapping. Disabling preemption was
required to protect the temporary mapping against a context switch.

Disabling pagefaults was an implicit side effect of disabling
preemption. The separation of preempt_disable() and pagefault_disable()
happened way later.

On 64bit and on 32bit systems with CONFIG_HIGHMEM=n this is not required
at all because the pages are already in the direct map.

That means support for 32bit highmem forces code to accomodate with the
preemption disabled section, where in the most cases this is absolutely
not required. That results often in suboptimal and horrible code:

again:
    kmap_atomic();
    remaining = copy_to_user_inatomic();
    kunmap_atomic();
    if (remaining) {
    	if (try_to_handle_fault())
            goto again;
        ret = -EFAULT;
    }

instead of:

    kmap_local();
    ret = copy_to_user();
    kunmap_local();
    
It obsiously does not allow to sleep or take sleeping locks in the
kmap_atomic() section which puts further restrictions on code just to
accomodate 32bit highmem.

So a few years ago we implemented kmap_local() and related interfaces to
replace kmap_atomic() completely, but we could not do a scripted
wholesale conversion because there are a few code pathes which rely on
the implicit preemption disable and of course something like the above
monstrosity needs manual conversion.

kmap_local() puts a penalty exclusively on 32bit highmem systems. The
temporary mapping is still strict per CPU, which is guaranteed by an
implicit migrate_disable(), and it is context switched in case of
[un]voluntary scheduling.

On plain 32bit and 64bit systems kmap_local() is pretty much a NOP. All
it does is to return the page address. It does not disable migration in
that case either. kunmap_local() is a complete NOP.

The goal is to eliminate _all_ use cases of kmap_atomic*() and replace
them with kmap_local*(). This is a prerequisite for system protection
keys and other things.

Thanks,

        tglx









  reply	other threads:[~2022-11-16 12:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 16:16 [PATCH v2] x86/sgx: Replace kmap/kunmap_atomic calls Kristen Carlson Accardi
2022-11-15 23:43 ` Jarkko Sakkinen
2022-11-16 10:16 ` Fabio M. De Francesco
2022-11-16 11:58   ` Thomas Gleixner [this message]
2022-11-16 14:01     ` Fabio M. De Francesco
2022-11-16 17:21       ` Ira Weiny
2022-11-16 20:00         ` Fabio M. De Francesco
2022-11-16 21:57           ` Thomas Gleixner
2022-11-16 22:03 ` Ira Weiny
2022-11-16 22:45 ` Fabio M. De Francesco
2022-12-02 14:04 ` [tip: x86/sgx] x86/sgx: Replace kmap/kunmap_atomic() calls tip-bot2 for Kristen Carlson Accardi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cz9nqff2.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fmdefrancesco@gmail.com \
    --cc=hpa@zytor.com \
    --cc=ira.weiny@intel.com \
    --cc=jarkko@kernel.org \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox