linux-kernel - Re: [RFC PATCH] cleanup: Add cond

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <13504735.uLZWGnKmhe@fdefranc-mobl3>
Date: Wed, 31 Jan 2024 14:09:13 +0100
From: "Fabio M. De Francesco" <fabio.maria.de.francesco@...ux.intel.com>
To: linux-kernel@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
 Dan Williams <dan.j.williams@...el.com>, Ira Weiny <ira.weiny@...el.com>
Subject: Re: [RFC PATCH] cleanup: Add cond_guard() to conditional guards

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