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 09:03:16 -0700 [thread overview]
Message-ID: <20200318160316.GE24357@linux.intel.com> (raw)
In-Reply-To: <20200318155043.GA37726@linux.intel.com>
On Wed, Mar 18, 2020 at 05:50:43PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 18, 2020 at 05:39:07PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Mar 16, 2020 at 10:15:39PM -0700, Sean Christopherson wrote:
> > > @@ -223,10 +229,22 @@ int sgx_encl_mm_add(struct sgx_encl *encl, struct mm_struct *mm)
> > >
> > > spin_lock(&encl->mm_lock);
> > > list_add_rcu(&encl_mm->list, &encl->mm_list);
> > > + /*
> > > + * Ensure the mm is added to the list before updating the version.
> > > + * Pairs with the smp_rmb() in sgx_reclaimer_block().
> > > + */
> > > + smp_wmb();
> > > + encl->mm_list_version++;
> > > spin_unlock(&encl->mm_lock);
> > >
> > > - synchronize_srcu(&encl->srcu);
> > > -
> > > + /*
> > > + * DO NOT call synchronize_srcu()! When this is called via dup_mmap(),
> > > + * mmap_sem is held for write in both the old mm and new mm, and the
> > > + * reclaimer may be holding srcu for read while waiting on down_read()
> > > + * for the old mm's mmap_sem, i.e. synchronizing will deadlock.
> > > + * Incrementing the list version ensures readers that must not race
> > > + * with a mm being added will see the updated list.
> > > + */
>
> For this comment, please completely remove it. We either call something
> or do not call it. We do !call anything.
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.
> > > return 0;
> > > }
> > >
> > > diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
> > > index 44b353aa8866..f0f72e591244 100644
> > > --- a/arch/x86/kernel/cpu/sgx/encl.h
> > > +++ b/arch/x86/kernel/cpu/sgx/encl.h
> > > @@ -74,6 +74,7 @@ struct sgx_encl {
> > > struct mutex lock;
> > > struct list_head mm_list;
> > > spinlock_t mm_lock;
> > > + unsigned long mm_list_version;
> > > struct file *backing;
> > > struct kref refcount;
> > > struct srcu_struct srcu;
next prev parent reply other threads:[~2020-03-18 16:03 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 [this message]
2020-03-18 19:40 ` Jarkko Sakkinen
2020-03-18 19:41 ` Jarkko Sakkinen
2020-03-18 20:07 ` Sean Christopherson
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=20200318160316.GE24357@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 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).