Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 17 Nov 2020 19:35:06 +0200
From:   Jarkko Sakkinen <jarkko@kernel.org>
To:     Hillf Danton <hdanton@sina.com>
Cc:     x86@kernel.org, linux-sgx@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Jethro Beekman <jethro@fortanix.com>,
        Serge Ayoun <serge.ayoun@intel.com>, akpm@linux-foundation.org
Subject: Re: [PATCH v41 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
Message-ID: <20201117173506.GB8524@kernel.org>
References: <20201112220135.165028-13-jarkko@kernel.org>
 <20201115044044.11040-1-hdanton@sina.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201115044044.11040-1-hdanton@sina.com>
Precedence: bulk

On Sun, Nov 15, 2020 at 12:40:44PM +0800, Hillf Danton wrote:
> On Fri, 13 Nov 2020 00:01:23 +0200 Jarkko Sakkinen wrote:
> > 
> > +long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
> > +{
> > +	struct sgx_encl *encl = filep->private_data;
> > +	int ret;
> > +
> > +	if (test_and_set_bit(SGX_ENCL_IOCTL, &encl->flags))
> > +		return -EBUSY;
> 
> Looks like encl->ioctl_mutex is needed to exlusively serialize
> concurrent ioctl threads and make encl->flags free of the duty.
> Plus it can cut the confusing EBUSY in userspace as it is not
> a critical path in any form.

The reason it is there was lock juggling with sgx_encl_grow() [*].

Andd since you never should use these ioctl's in parallel so why not
explicitly signal it to the user space?

[*] https://lore.kernel.org/linux-sgx/20190827001128.25066-4-sean.j.christopherson@intel.com/

/Jarkko