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: Fix deadlock and race conditions between fork() and EPC reclaim
Date: Wed, 18 Mar 2020 13:07:48 -0700 [thread overview]
Message-ID: <20200318200748.GA26164@linux.intel.com> (raw)
In-Reply-To: <20200318194132.GB48177@linux.intel.com>
On Wed, Mar 18, 2020 at 09:41:32PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 18, 2020 at 09:40:06PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Mar 18, 2020 at 09:03:16AM -0700, Sean Christopherson wrote:
> > > How on earth is someone doing to dredge up the above information without a
> > > comment? Anyone looking at this code without a priori knowledge of the
> > > development history will assume the missing synchronize_srcu() is a bug.
> >
> > By reading the source code of the driver obviously.
>
> Secondly, there is no development history. It is in epoch state.
That's exactly my point. Unless someone knows to look through the
pre-historic threads in the intel_sgx mailing list they'll be clueless as
to why synchronizing the srcu when attaching a new mm to an enclave is a
bad idea. And give it a few years and we'll probably be asking ourselves
why there's no synchronize_sruc()...
The locking rules between SGX and the core MMU are complex enough as it is,
I don't understand why we'd want to make our lives even more difficult.
next prev parent reply other threads:[~2020-03-18 20:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 5:15 [PATCH] x86/sgx: Fix deadlock and race conditions between fork() and EPC reclaim Sean Christopherson
2020-03-18 15:39 ` Jarkko Sakkinen
2020-03-18 15:50 ` Jarkko Sakkinen
2020-03-18 15:51 ` Jarkko Sakkinen
2020-03-18 16:03 ` Sean Christopherson
2020-03-18 19:40 ` Jarkko Sakkinen
2020-03-18 19:41 ` Jarkko Sakkinen
2020-03-18 20:07 ` Sean Christopherson [this message]
2020-03-19 14:15 ` Jarkko Sakkinen
2020-03-18 21:30 ` 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=20200318200748.GA26164@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.