From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH] x86/sgx: WARN once if EREMOVE fails when killing an enclave
Date: Thu, 10 Oct 2019 11:35:48 -0700 [thread overview]
Message-ID: <20191010183548.GD23798@linux.intel.com> (raw)
In-Reply-To: <20191009000450.GA14261@linux.intel.com>
On Wed, Oct 09, 2019 at 03:04:50AM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 07, 2019 at 09:13:34PM -0700, Sean Christopherson wrote:
> > WARN if EREMOVE fails when destroying an enclave. sgx_encl_release()
> > uses the non-WARN __sgx_free_page() when freeing pages as some pages may
> > be in the process of being reclaimed, i.e. are owned by the reclaimer.
> > But EREMOVE should never fail as sgx_encl_destroy() is only called when
> > the enclave cannot have active threads, e.g. prior to EINIT and when the
> > enclave is being released.
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>
> For me this concludes that I will manually convert all the call sites
> to use __sgx_free_page() and add appropriate warnings. I agree with
> Borislav's conclusions here.
Argh, now we have a bunch of call sites that can silently leak EPC pages,
and I'm seeing timeouts during testing that strongly suggest pages are
being leaked...
next prev parent reply other threads:[~2019-10-10 18:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 4:13 [PATCH] x86/sgx: WARN once if EREMOVE fails when killing an enclave Sean Christopherson
2019-10-08 4:15 ` Sean Christopherson
2019-10-09 0:04 ` Jarkko Sakkinen
2019-10-10 18:35 ` Sean Christopherson [this message]
2019-10-10 18:56 ` Sean Christopherson
2019-10-10 20:52 ` Sean Christopherson
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=20191010183548.GD23798@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.