From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
David Lechner <dlechner@baylibre.com>
Cc: "Dan Williams" <dan.j.williams@intel.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Nuno Sá" <nuno.sa@analog.com>,
"Michael Hennerich" <michael.hennerich@analog.com>,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-cxl@vger.kernel.org
Subject: Re: [PATCH 1/3] cleanup: add conditional guard helper
Date: Fri, 18 Oct 2024 14:31:43 +0200 [thread overview]
Message-ID: <26605fd6-0ed5-44f9-981e-d378a192bf0d@intel.com> (raw)
In-Reply-To: <20241018111503.GC36494@noisy.programming.kicks-ass.net>
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@baylibre.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?
next prev parent reply other threads:[~2024-10-18 12:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 22:30 [PATCH 0/3] cleanup: add if_not_cond_guard macro David Lechner
2024-10-01 22:30 ` [PATCH 1/3] cleanup: add conditional guard helper David Lechner
2024-10-04 17:34 ` Dan Williams
2024-10-04 20:27 ` David Lechner
2024-10-18 11:15 ` Peter Zijlstra
2024-10-18 12:31 ` Przemek Kitszel [this message]
2024-10-18 16:29 ` Jonathan Cameron
2024-10-18 19:29 ` Dan Williams
2024-10-23 10:57 ` Peter Zijlstra
2024-10-01 22:30 ` [PATCH 2/3] iio: adc: ad7380: use if_not_cond_guard for claim direct David Lechner
2024-10-03 4:23 ` kernel test robot
2024-10-03 5:35 ` kernel test robot
2024-10-03 14:20 ` David Lechner
2024-10-01 22:30 ` [PATCH 3/3] cxl/region: Use cond_guard() in show_targetN() David Lechner
2024-10-02 2:13 ` [PATCH 0/3] cleanup: add if_not_cond_guard macro Dan Williams
2024-10-06 11:35 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26605fd6-0ed5-44f9-981e-d378a192bf0d@intel.com \
--to=przemyslaw.kitszel@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=nuno.sa@analog.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox