Re: [RFC PATCH] cleanup: Add cond_guard() to conditional guards

[Fabio M. De Francesco]

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