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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Feb 2024 17:51:26 +0100
From: "Fabio M. De Francesco" <fabio.maria.de.francesco@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>,
 Dan Williams <dan.j.williams@...el.com>, linux-kernel@...r.kernel.org
Cc: linux-cxl@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
 Dave Jiang <dave.jiang@...el.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Ira Weiny <ira.weiny@...el.com>
Subject: Re: [PATCH 1/2 v4] cleanup: Add cond_guard() to conditional guards

On Thursday, 8 February 2024 14:04:23 CET Fabio M. De Francesco wrote:
> Add cond_guard() macro to conditional guards.
> 
> cond_guard() is a guard to be used with the conditional variants of locks,
> like down_read_trylock() or mutex_lock_interruptible().
> 
> It takes a statement (or statement-expression) that is passed as its
> second argument. That statement (or statement-expression) is executed if
> waiting for a lock is interrupted or if a _trylock() fails in case of
> contention.
> 
> Usage example:
> 
> 	cond_guard(mutex_intr, return -EINTR, &mutex);
> 
> Consistent with other usage of _guard(), locks are unlocked at the exit of
> the scope where cond_guard() is called.
> 
[snip]
> 
> +#define cond_guard(_name, _fail, args...) \
> +	CLASS(_name, scope)(args); \
> +	if (!__guard_ptr(_name)(&scope)) _fail; \
> +	else { }
> +

I have converted and tested several functions in drivers/cxl and found that 
there are cases where this macro needs to be called twice in the same scope.

The current implementation fails to compile because any subsequent call to 
cond_guard() redefines "scope".

I have a solution for this, which is to instantiate a differently named 
variable each time cond_guard() is used:

#define __UNIQUE_LINE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
#define cond_guard(_name, _fail, args...) \
        CLASS(_name, __UNIQUE_LINE_ID(scope))(args); \
        if (!__guard_ptr(_name)(&__UNIQUE_LINE_ID(scope))) _fail; \
        else { }

But, before sending v5, I think it's best to wait for comments from those with 
more experience than me.

Fabio




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ