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 13:52:56 -0700 [thread overview]
Message-ID: <20191010205256.GG23798@linux.intel.com> (raw)
In-Reply-To: <20191010185607.GE23798@linux.intel.com>
On Thu, Oct 10, 2019 at 11:56:07AM -0700, Sean Christopherson wrote:
> On Thu, Oct 10, 2019 at 11:35:48AM -0700, Sean Christopherson wrote:
> > 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...
>
> Confirmed that we're leaking pages, but it's not related to the -EBUSY
> case in sgx_free_page(). Debug in progress...
>
> As to the sgx_free_page() thing, I think we can invert the old WARN logic
> and make everyone happy. I'll send a patch.
Figured out what's up. I'm testing in a VM with multiple EPC sections.
Because of a change in v23[*], sgx_nr_free_pages is getting corrupted due
to non-atomic concurrent writes. When it drops below 0 and wraps to a
high value the swap thread stops reclaiming and things grind to a halt.
[*] https://patchwork.kernel.org/patch/11146733/#22887361
prev parent reply other threads:[~2019-10-10 20:52 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
2019-10-10 18:56 ` Sean Christopherson
2019-10-10 20:52 ` Sean Christopherson [this message]
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=20191010205256.GG23798@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.