[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87msdu397r.ffs@tglx>
Date: Sun, 09 Mar 2025 09:21:44 +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>
Subject: Re: [patch V2 08/17] posix-timers: Rework timer removal
On Sat, Mar 08 2025 at 23:48, Frederic Weisbecker wrote:
> Le Sat, Mar 08, 2025 at 09:34:06AM +0100, Thomas Gleixner a écrit :
>> >> --- a/kernel/time/posix-timers.c
>> >> +++ b/kernel/time/posix-timers.c
>> >> @@ -279,7 +279,7 @@ static bool __posixtimer_deliver_signal(
>> >> * since the signal was queued. In either case, don't rearm and
>> >> * drop the signal.
>> >> */
>> >> - if (timr->it_signal_seq != timr->it_sigqueue_seq || WARN_ON_ONCE(!timr->it_signal))
>> >> + if (timr->it_signal_seq != timr->it_sigqueue_seq || !posixtimer_valid(timr))
>> >
>> > Hmm, should it still warn here? ie: WARN_ON_ONCE(!posixtimer_valid(timr)) ?
>>
>> No, because the timer is invalidated early now.
>
> But the signal can only be queued before posix_timer_delete(). So
> if the bit 0 of it_signal has been reset, it_signal_seq must have been
> incremented along, right?
>
> And if so then timr->it_signal_seq == timr->it_sigqueue_seq must imply
> posixtimer_valid(). And if not we should warn. Or am I missing something?
You're just missing the fact, that I managed to confuse myself :)
Powered by blists - more mailing lists