Using guard(mutex) instead of mutex_lock/mutex_unlock pair. Simplifies the
error handling to just return in case of error. No need for the 'err_out'
label anymore so remove it.

Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 66f1efa16fbb..b61faa1aed7f 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -501,7 +501,7 @@ static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct *sigstruct,
 
 	sha256(sigstruct->modulus, SGX_MODULUS_SIZE, (u8 *)mrsigner);
 
-	mutex_lock(&encl->lock);
+	guard(mutex)(&encl->lock);
 
 	/*
 	 * ENCLS[EINIT] is interruptible because it has such a high latency,
@@ -534,7 +534,7 @@ static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct *sigstruct,
 
 		if (signal_pending(current)) {
 			ret = -ERESTARTSYS;
-			goto err_out;
+			return ret;
 		}
 	}
 
@@ -550,8 +550,6 @@ static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct *sigstruct,
 		set_bit(SGX_ENCL_INITIALIZED, &encl->flags);
 	}
 
-err_out:
-	mutex_unlock(&encl->lock);
 	return ret;
 }
 
-- 
2.34.1

On 9/1/25 06:22, Liao Yuanhong wrote:
> Using guard(mutex) instead of mutex_lock/mutex_unlock pair. Simplifies the
> error handling to just return in case of error. No need for the 'err_out'
> label anymore so remove it.

I don't plan on applying patches like this. Yes, they marginally
simplify the code, but they do it at the cost of code churn and adding
new bugs. In other words, they're not worth it.

On Mon, Sep 01, 2025 at 11:42:15AM -0700, Dave Hansen wrote:
> On 9/1/25 06:22, Liao Yuanhong wrote:
> > Using guard(mutex) instead of mutex_lock/mutex_unlock pair. Simplifies the
> > error handling to just return in case of error. No need for the 'err_out'
> > label anymore so remove it.
> 
> I don't plan on applying patches like this. Yes, they marginally
> simplify the code, but they do it at the cost of code churn and adding
> new bugs. In other words, they're not worth it.

+1

It has no effect on generated code.

BR, Jarkko