[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKNMFv7VTIaTTJwe@lothringen>
Date: Tue, 4 Jul 2023 00:30:46 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
John Stultz <jstultz@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Eric Biederman <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [patch 17/45] posix-cpu-timers: Make k_itimer::it_active
consistent
On Tue, Jun 06, 2023 at 04:37:45PM +0200, Thomas Gleixner wrote:
> @@ -787,6 +790,7 @@ static u64 collect_timerqueue(struct tim
>
> while ((next = timerqueue_getnext(head))) {
> struct cpu_timer *ctmr;
> + struct k_itimer *ktmr;
> u64 expires;
>
> ctmr = container_of(next, struct cpu_timer, node);
> @@ -799,6 +803,8 @@ static u64 collect_timerqueue(struct tim
> /* See posix_cpu_timer_wait_running() */
> rcu_assign_pointer(ctmr->handling, current);
> cpu_timer_dequeue(ctmr);
> + ktmr = container_of(ctmr, struct k_itimer, it.cpu);
> + ktmr->it_active = 0;
Maybe move this to cpu_timer_fire() because:
1) Other posix-timer implementation set it_active = 0
from their actual handler.
2) This place doesn't have the timer locked. Better Make
sure we have this protection to avoid mistakes against
potential future use of it_active.
Thanks.
> list_add_tail(&ctmr->elist, firing);
> }
>
>
Powered by blists - more mailing lists