From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: [PATCH for_v23 4/4] x86/sgx: Drop mmap_sem before EEXTENDing an enclave page
Date: Thu, 10 Oct 2019 15:55:30 -0700 [thread overview]
Message-ID: <20191010225530.26400-5-sean.j.christopherson@intel.com> (raw)
In-Reply-To: <20191010225530.26400-1-sean.j.christopherson@intel.com>
Drop mmap_sem, which needs to be held for read across EADD, prior to
doing EEXTEND on the newly added page to avoid holding mmap_sem for an
extended duration. EEXTEND doesn't access user pages and holding
encl->lock without mmap_sem is perfectly ok, while EEXTEND is a _slow_
operation, to the point where it operates on 256-byte chunks
instead of 4k pages to maintain a reasonable latency for a single
instruction.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
---
arch/x86/kernel/cpu/sgx/ioctl.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index fd4117f18564..46f2769d16fe 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -403,11 +403,15 @@ static int sgx_encl_add_page(struct sgx_encl *encl,
*/
ret = radix_tree_insert(&encl->page_tree, PFN_DOWN(encl_page->desc),
encl_page);
- if (ret)
+ if (ret) {
+ up_read(¤t->mm->mmap_sem);
goto err_out_unlock;
+ }
ret = __sgx_encl_add_page(encl, encl_page, epc_page, secinfo,
addp->src);
+ up_read(¤t->mm->mmap_sem);
+
if (ret)
goto err_out;
@@ -427,7 +431,6 @@ static int sgx_encl_add_page(struct sgx_encl *encl,
sgx_mark_page_reclaimable(encl_page->epc_page);
mutex_unlock(&encl->lock);
- up_read(¤t->mm->mmap_sem);
return ret;
err_out:
@@ -437,7 +440,6 @@ static int sgx_encl_add_page(struct sgx_encl *encl,
err_out_unlock:
sgx_encl_shrink(encl, va_page);
mutex_unlock(&encl->lock);
- up_read(¤t->mm->mmap_sem);
err_out_free:
sgx_free_page(epc_page);
--
2.22.0
next prev parent reply other threads:[~2019-10-10 22:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 22:55 [PATCH for_v23 0/4] x86/sgx: Fix add page bugs Sean Christopherson
2019-10-10 22:55 ` [PATCH for_v23 1/4] x86/sgx: Pass EADD the kernel's virtual address for the source page Sean Christopherson
2019-10-10 22:55 ` [PATCH for_v23 2/4] x86/sgx: Check the validity of the source page address for EADD Sean Christopherson
2019-10-10 22:55 ` [PATCH for_v23 3/4] x86/sgx: Fix EEXTEND error handling Sean Christopherson
2019-10-10 22:55 ` Sean Christopherson [this message]
2019-10-14 21:03 ` [PATCH for_v23 0/4] x86/sgx: Fix add page bugs Jarkko Sakkinen
2019-10-16 16:39 ` Sean Christopherson
2019-10-17 16:25 ` Jarkko Sakkinen
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=20191010225530.26400-5-sean.j.christopherson@intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-sgx@vger.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;
as well as URLs for NNTP newsgroup(s).