From: Ira Weiny <ira.weiny@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "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>
Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls
Date: Thu, 6 Oct 2022 14:26:41 -0700 [thread overview]
Message-ID: <Yz9IEX1uFNllLjAD@iweiny-desk3> (raw)
In-Reply-To: <d64e6e9f-27b9-9bbb-aaf8-fca1681eada5@intel.com>
On Thu, Oct 06, 2022 at 01:45:56PM -0700, Hansen, Dave wrote:
> On 10/6/22 13:37, Fabio M. De Francesco wrote:
> > kmap() were not suited in those cases because it might sleep. If the intents
> > of the author are simply map a page while in atomic, so to avoid sleeping in
> > atomic bugs, your conversions looks good.
> >
> > For the reasons above, can you please say something more about why this code
> > needed a kmap_atomic() instead of calling kmap()?
>
> This question is backwards. kmap_atomic() is the default that folks
> use. You use kmap_atomic() *always* unless you _need_ to sleep or one
> of the other kmap()-only things.
>
> Folks don't and shouldn't have to explain why this was using kmap_atomic().
I've not looked at the code closely enough but there was some concern that
kmap_atomic() callers are depending on preemption being disabled vs the more
common case of them being used in an atomic context where kmap() can't work.
Ira
next prev parent reply other threads:[~2022-10-06 21:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 16:06 [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls Kristen Carlson Accardi
2022-09-30 21:55 ` Jarkko Sakkinen
2022-10-06 20:37 ` Fabio M. De Francesco
2022-10-06 20:45 ` Dave Hansen
2022-10-06 21:26 ` Ira Weiny [this message]
2022-10-06 22:02 ` Fabio M. De Francesco
2022-10-06 22:29 ` Dave Hansen
2022-10-06 23:17 ` Ira Weiny
2022-10-07 15:23 ` Ira Weiny
2022-10-12 7:15 ` Jarkko Sakkinen
2022-10-12 7:26 ` Jarkko Sakkinen
2022-10-12 14:13 ` Dave Hansen
2022-10-12 14:50 ` Jarkko Sakkinen
2022-10-12 15:50 ` Jarkko Sakkinen
2022-10-13 16:03 ` 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=Yz9IEX1uFNllLjAD@iweiny-desk3 \
--to=ira.weiny@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fmdefrancesco@gmail.com \
--cc=hpa@zytor.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=tglx@linutronix.de \
--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