On 3/14/25 13:55, Peter Zijlstra wrote:

On Fri, Mar 14, 2025 at 11:15:42AM +0530, Shrikanth Hegde wrote:

quoted

use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.

More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161713@infradead.org/T/#u (local)

There is also an example of using scoped_guard.

Signed-off-by: Shrikanth Hegde <redacted>
---
  arch/powerpc/platforms/book3s/vas-api.c | 19 ++++++-------------
  1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/platforms/book3s/vas-api.c b/arch/powerpc/platforms/book3s/vas-api.c
index 0b6365d85d11..eb1a97271afb 100644
--- a/arch/powerpc/platforms/book3s/vas-api.c
+++ b/arch/powerpc/platforms/book3s/vas-api.c

@@ -425,7 +425,7 @@ static vm_fault_t vas_mmap_fault(struct vm_fault *vmf)
  		return VM_FAULT_SIGBUS;
  	}
  
-	mutex_lock(&txwin->task_ref.mmap_mutex);
+	guard(mutex)(&txwin->task_ref.mmap_mutex);
  	/*
  	 * The window may be inactive due to lost credit (Ex: core
  	 * removal with DLPAR). If the window is active again when

@@ -437,11 +437,9 @@ static vm_fault_t vas_mmap_fault(struct vm_fault *vmf)
  		if (paste_addr) {
  			fault = vmf_insert_pfn(vma, vma->vm_start,
  					(paste_addr >> PAGE_SHIFT));
-			mutex_unlock(&txwin->task_ref.mmap_mutex);
  			return fault;
  		}
  	}
-	mutex_unlock(&txwin->task_ref.mmap_mutex);

I had to open up this file to check, but this seems incorrect since you
now also run do_fail_paste() with the lock held, where previously you
did not.

Yes. Got it. let me use scoped_guard for it as well. There is get_user 
and other things in the fail parse and having it with mutex will not be 
good.

I went through the rest of the patches too. It is mostly return after 
mutex.

Only in Patch 5/6 there is additional debug statement. Let me put a 
comment there.

quoted

  	/*
  	 * Received this fault due to closing the actual window.