Received-SPF: pass (google.com: domain of linux-kernel+bounces-46465-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>
To: linux-kernel@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
 Dan Williams <dan.j.williams@intel.com>, Ira Weiny <ira.weiny@intel.com>
Subject: Re: [RFC PATCH] cleanup: Add cond_guard() to conditional guards
Date: Wed, 31 Jan 2024 14:09:13 +0100
Message-ID: <13504735.uLZWGnKmhe@fdefranc-mobl3>
Organization: intel
In-Reply-To:
 <65b82555aaf86_5902829447@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References:
 <20240129190100.329791-1-fabio.maria.de.francesco@linux.intel.com>
 <65b82555aaf86_5902829447@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Monday, 29 January 2024 23:23:17 CET Dan Williams wrote:
> Fabio M. De Francesco wrote: 
> > 2) By using cond_guard() it is not possible to release the lock before
> > calling other functions from the current one. The lock is held until the
> > current function exits. This is not always desirable.
> 
> No, that's not correct, the lock is only held until the exit from the
> current scope, and if you call functions from within that scope the lock
> remains held. So:
> 
>     func1()
>     {
>         guard(...)(lock1);
>         if (condition) {
>             guard(...)(lock2);
>             func2();
>         }
>         func3();
>     }
> 
> func2() is called with lock1 and lock2 held, func3() is only called with
> lock1() held.

Dan,

If I read your example correctly, this is exactly what I wanted to say by 
"it's not possible to release the lock before calling other functions from the 
current one". 

For example, if we use this (not scoped) cond_guard() in cxl_region_probe(), 
we end up to the switch() and then possibly call devm_cxl_add_pmem_region() 
with the cxl_region_rwsem semaphore down, whereas the current code calls a 
up_read() before the switch.

I think that in cxl_region_probe() the only suited conditional guard is 
scoped_cond_guard().

I know that you don't want an indented success path but in cxl_region_probe 
but I suspect that scoped_cond_guard() is the only viable solution, otherwise 
we end up calling the functions that now are called after up_read() with the 
semaphore still down.

I hope that this time I have been clearer.

Thanks,

Fabio