After a thread is awakened, its state is already task_running
Signed-off-by: Lizhe <[email protected]>
---
kernel/time/hrtimer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 760793998cdd..b123e9f4401a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -2310,8 +2310,6 @@ schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
hrtimer_cancel(&t.timer);
destroy_hrtimer_on_stack(&t.timer);
- __set_current_state(TASK_RUNNING);
-
return !t.task ? 0 : -EINTR;
}
EXPORT_SYMBOL_GPL(schedule_hrtimeout_range_clock);
--
2.25.1
On Wed, Jan 10 2024 at 06:13, Lizhe wrote:
> After a thread is awakened, its state is already task_running
That's correct, but please look at hrtimer_wakeup() and the conditional
schedule() invocation in schedule_hrtimeout_range_clock(). You break the
guarantee that this function returns with task state == TASK_RUNNING.
Thanks,
tglx
Hi,
Please review this patch, It does not check the condition when executing the scheduler() function.
Lizhe
thanks
At 2024-01-12 00:44:20, "Thomas Gleixner" <[email protected]> wrote:
>On Wed, Jan 10 2024 at 06:13, Lizhe wrote:
>> After a thread is awakened, its state is already task_running
>
>That's correct, but please look at hrtimer_wakeup() and the conditional
>schedule() invocation in schedule_hrtimeout_range_clock(). You break the
>guarantee that this function returns with task state == TASK_RUNNING.
>
>Thanks,
>
> tglx