The dmar_get_irq_domain() function uses a mutex to protect the
initialization of the dmar_domain. Using guard(mutex) simplifies the
control flow, removes the need for a 'out' label, and ensures the
lock is automatically released regardless of the return path.

Signed-off-by: Richard Lyu <richard.lyu@suse.com>
---
 arch/x86/kernel/apic/msi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 66bc5d3e79db..3f10b35f7c79 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -7,7 +7,9 @@
  * Jiang Liu <jiang.liu@linux.intel.com>
  *	Convert to hierarchical irqdomain
  */
+#include <linux/cleanup.h>
 #include <linux/mm.h>
+#include <linux/mutex.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
@@ -346,9 +348,9 @@ static struct irq_domain *dmar_get_irq_domain(void)
 	static DEFINE_MUTEX(dmar_lock);
 	struct fwnode_handle *fn;
 
-	mutex_lock(&dmar_lock);
+	guard(mutex)(&dmar_lock);
 	if (dmar_domain)
-		goto out;
+		return dmar_domain;
 
 	fn = irq_domain_alloc_named_fwnode("DMAR-MSI");
 	if (fn) {
@@ -357,8 +359,6 @@ static struct irq_domain *dmar_get_irq_domain(void)
 		if (!dmar_domain)
 			irq_domain_free_fwnode(fn);
 	}
-out:
-	mutex_unlock(&dmar_lock);
 	return dmar_domain;
 }
 
-- 
2.51.0

On 3/11/26 07:59, Richard Lyu wrote:
> The dmar_get_irq_domain() function uses a mutex to protect the
> initialization of the dmar_domain. Using guard(mutex) simplifies the
> control flow, removes the need for a 'out' label, and ensures the
> lock is automatically released regardless of the return path.

I think these are kinda like whitespace fixes: If you're fixing a bug or
otherwise refactoring the code, go right ahead and convert over to
guard(). Otherwise, they're not worth the code churn.

On 2026/03/11 08:03, Dave Hansen wrote:
>On 3/11/26 07:59, Richard Lyu wrote:
>> The dmar_get_irq_domain() function uses a mutex to protect the
>> initialization of the dmar_domain. Using guard(mutex) simplifies the
>> control flow, removes the need for a 'out' label, and ensures the
>> lock is automatically released regardless of the return path.
>
>I think these are kinda like whitespace fixes: If you're fixing a bug or
>otherwise refactoring the code, go right ahead and convert over to
>guard(). Otherwise, they're not worth the code churn.

Thank you for the feedback.

That makes total sense. I understand the concern about unnecessary code
churn and will avoid sending pure stylistic cleanups unless they are
part of a larger functional change or bug fix in the future.

Richard