[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o6y823fx.ffs@tglx>
Date: Mon, 10 Mar 2025 18:36:18 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Anna-Maria Behnsen
<anna-maria@...utronix.de>, Benjamin Segall <bsegall@...gle.com>, Eric
Dumazet <edumazet@...gle.com>, Andrey Vagin <avagin@...nvz.org>, Pavel
Tikhomirov <ptikhomirov@...tuozzo.com>, Peter Zijlstra
<peterz@...radead.org>, Cyrill Gorcunov <gorcunov@...il.com>
Subject: Re: [patch V3 10/18] posix-timers: Make lock_timer() use guard()
On Mon, Mar 10 2025 at 12:57, Frederic Weisbecker wrote:
> Le Sat, Mar 08, 2025 at 05:48:34PM +0100, Thomas Gleixner a écrit :
>> --- a/kernel/time/posix-timers.c
>> +++ b/kernel/time/posix-timers.c
>> @@ -63,9 +63,18 @@ static struct k_itimer *__lock_timer(tim
>>
>> static inline void unlock_timer(struct k_itimer *timr)
>> {
>> - spin_unlock_irq(&timr->it_lock);
>> + if (likely((timr)))
>> + spin_unlock_irq(&timr->it_lock);
>> }
>>
>> +#define scoped_timer_get_or_fail(_id) \
>> + scoped_cond_guard(lock_timer, return -EINVAL, _id)
>
> I'm not really fond of the fact this hides a return.
I could drop the macro and let the call sites all do:
scoped_cond_guard(lock_timer, return -EINVAL, $d)
But I'm not sure it's much better :)
Powered by blists - more mailing lists