From: Dave Hansen <dave.hansen@intel.com>
To: Sean Christopherson <seanjc@google.com>,
Haitao Huang <haitao.huang@linux.intel.com>
Cc: 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>,
Jethro Beekman <jethro@fortanix.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8] x86/sgx: Maintain encl->refcount for each encl->mm_list entry
Date: Wed, 14 Apr 2021 09:58:43 -0700 [thread overview]
Message-ID: <9c09f331-fb3c-4ad3-8887-f27688f49b9c@intel.com> (raw)
In-Reply-To: <YHcPfRqKCx+KXwoJ@google.com>
On 4/14/21 8:51 AM, Sean Christopherson wrote:
>> Could this access to and kfree of encl_mm possibly be after the
>> kfree(encl_mm) noted above?
> No, the mmu_notifier_unregister() ensures that all in-progress notifiers complete
> before it returns, i.e. SGX's notifier call back is not reachable after it's
> unregistered.
>
>> Also is there a reason we do kfree(encl_mm) in notifier_free not directly in
>> notifier_release?
> Because encl_mm is the anchor to the enclave reference
>
> /* 'encl_mm' is going away, put encl_mm->encl reference: */
> kref_put(&encl_mm->encl->refcount, sgx_encl_release);
>
> as well as the mmu notifier reference (the mmu_notifier_put(mn) call chain).
> Freeing encl_mm immediately would prevent sgx_mmu_notifier_free() from dropping
> the enclave reference. And the mmu notifier reference need to be dropped in
> sgx_mmu_notifier_release() because the encl_mm has been taken off encl->mm_list.
Haitao, I think you've highlighted that this locking scheme is woefully
under-documented. Any patches to beef it up would be very welcome.
prev parent reply other threads:[~2021-04-14 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-07 22:14 [PATCH v8] x86/sgx: Maintain encl->refcount for each encl->mm_list entry Jarkko Sakkinen
2021-02-07 22:37 ` Dave Hansen
2021-02-08 18:20 ` [tip: x86/urgent] " tip-bot2 for Jarkko Sakkinen
2021-04-14 1:15 ` [PATCH v8] " Haitao Huang
2021-04-14 15:51 ` Sean Christopherson
2021-04-14 16:58 ` Dave Hansen [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=9c09f331-fb3c-4ad3-8887-f27688f49b9c@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=jethro@fortanix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=seanjc@google.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 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.