linux-kernel - Re: [PATCH 1/3] cleanup: add conditional guard helper

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]

Message-ID: <26605fd6-0ed5-44f9-981e-d378a192bf0d@intel.com>
Date: Fri, 18 Oct 2024 14:31:43 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Peter Zijlstra <peterz@...radead.org>, David Lechner
	<dlechner@...libre.com>
CC: Dan Williams <dan.j.williams@...el.com>, Linus Torvalds
	<torvalds@...ux-foundation.org>, Jonathan Cameron <jic23@...nel.org>,
	Nuno Sá <nuno.sa@...log.com>, Michael Hennerich
	<michael.hennerich@...log.com>, <linux-kernel@...r.kernel.org>,
	<linux-iio@...r.kernel.org>, <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH 1/3] cleanup: add conditional guard helper

On 10/18/24 13:15, Peter Zijlstra wrote:
> On Tue, Oct 01, 2024 at 05:30:18PM -0500, David Lechner wrote:
>> Add a new if_not_cond_guard() macro to cleanup.h for handling
>> conditional guards such as mutext_trylock().
>>
>> This is more ergonomic than scoped_cond_guard() for most use cases.
>> Instead of hiding the error handling statement in the macro args, it
>> works like a normal if statement and allow the error path to be indented
>> while the normal code flow path is not indented. And it avoid unwanted
>> side-effect from hidden for loop in scoped_cond_guard().
>>
>> Signed-off-by: David Lechner <dlechner@...libre.com>

So this is guard()() with error handler for cond class of locks.
I would name such guard_or_err(), or guard_or_err_block(), to make it
obvious why there is a block attached (so bad we could not ENFORCE that
there is a block atached).

Then, having it, it would make sense to not only limit guard_or_err() to
cond class of locks, but also forbid plain guard() with cond locks
(instead just discouraging it in the doc).

>> ---
>>   include/linux/cleanup.h | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/include/linux/cleanup.h b/include/linux/cleanup.h
>> index 038b2d523bf8..682bb3fadfc9 100644
>> --- a/include/linux/cleanup.h
>> +++ b/include/linux/cleanup.h
>> @@ -273,6 +273,10 @@ static inline class_##_name##_t class_##_name##ext##_constructor(_init_args) \
>>    *	an anonymous instance of the (guard) class, not recommended for
>>    *	conditional locks.
>>    *
>> + * if_not_cond_guard(name, args...) { <error handling> }:
>> + *	convenience macro for conditional guards that calls the statement that
>> + *	follows only if the lock was not acquired (typically an error return).
>> + *
>>    * scoped_guard (name, args...) { }:
>>    *	similar to CLASS(name, scope)(args), except the variable (with the
>>    *	explicit name 'scope') is declard in a for-loop such that its scope is
>> @@ -304,6 +308,13 @@ static inline class_##_name##_t class_##_name##ext##_constructor(_init_args) \
>>   
>>   #define __guard_ptr(_name) class_##_name##_lock_ptr
>>   
>> +#define __if_not_cond_guard(_name, _id, args...)	\
>> +	CLASS(_name, _id)(args);			\
>> +	if (!__guard_ptr(_name)(&_id))
>> +
>> +#define if_not_cond_guard(_name, args...) \
>> +	__if_not_cond_guard(_name, __UNIQUE_ID(guard), args)
>> +
>>   #define scoped_guard(_name, args...)					\
>>   	for (CLASS(_name, scope)(args),					\
>>   	     *done = NULL; __guard_ptr(_name)(&scope) && !done; done = (void *)1)
> 
> 
> So if I stick this on top of:
> 
>    https://lkml.kernel.org/r/20241011121535.28049-1-przemyslaw.kitszel@intel.com

I have v4 that fixes non-cond version. Apologies it took me that long.
[v4] 
https://lore.kernel.org/netdev/20241018113823.171256-1-przemyslaw.kitszel@intel.com

I have tested it also with the unrechable() calls removed, as suggested
by David Lechner here:
https://lore.kernel.org/netdev/0f4786e9-d738-435d-afb9-8c0c4a028ddb@baylibre.com

> 
> then I can add the below:
> 
> --- a/include/linux/cleanup.h
> +++ b/include/linux/cleanup.h
> @@ -277,6 +277,8 @@ static inline class_##_name##_t class_##
>    *	convenience macro for conditional guards that calls the statement that
>    *	follows only if the lock was not acquired (typically an error return).
>    *
> + *	Only for conditional locks.
> + *
>    * scoped_guard (name, args...) { }:
>    *	similar to CLASS(name, scope)(args), except the variable (with the
>    *	explicit name 'scope') is declard in a for-loop such that its scope is
> @@ -290,7 +292,6 @@ static inline class_##_name##_t class_##
>    *      acquire fails.
>    *
>    *	Only for conditional locks.
> - *
>    */
>   
>   #define __DEFINE_CLASS_IS_CONDITIONAL(_name, _is_cond)	\
> @@ -342,6 +343,7 @@ _label:										\
>   		       __UNIQUE_ID(label), args)
>   
>   #define __if_not_guard(_name, _id, args...)		\
> +	BUILD_BUG_ON(!__is_cond_ptr(_name));		\
>   	CLASS(_name, _id)(args);			\
>   	if (!__guard_ptr(_name)(&_id))
>   
> 
> That make sense to people?

despite name, looks promising!

> 
> I've queued these two patches:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core
> 
> But lacking if_not_guard() users, the robot isn't really going to give
> me much feedback there, I suppose...

Couldn't you just pick the other patches, that use the newly introduced
macro?