* [PATCH] hrtimer.c : Remove redundant thread state settings
@ 2024-01-10 14:13 Lizhe
2024-01-11 16:44 ` Thomas Gleixner
0 siblings, 1 reply; 3+ messages in thread
From: Lizhe @ 2024-01-10 14:13 UTC (permalink / raw)
To: tglx, ilpo.jarvinen; +Cc: linux-kernel, Lizhe
After a thread is awakened, its state is already task_running
Signed-off-by: Lizhe <sensor1010@163.com>
---
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] hrtimer.c : Remove redundant thread state settings
2024-01-10 14:13 [PATCH] hrtimer.c : Remove redundant thread state settings Lizhe
@ 2024-01-11 16:44 ` Thomas Gleixner
2024-01-12 5:03 ` lizhe
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Gleixner @ 2024-01-11 16:44 UTC (permalink / raw)
To: Lizhe, ilpo.jarvinen; +Cc: linux-kernel, Lizhe
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re:Re: [PATCH] hrtimer.c : Remove redundant thread state settings
2024-01-11 16:44 ` Thomas Gleixner
@ 2024-01-12 5:03 ` lizhe
0 siblings, 0 replies; 3+ messages in thread
From: lizhe @ 2024-01-12 5:03 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: ilpo.jarvinen, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]
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" <tglx@linutronix.de> 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
[-- Attachment #1.2: Type: text/html, Size: 1874 bytes --]
[-- Attachment #2: 0001-drivers-dm-crypt.c-remove-redundant-state-settings-a.patch --]
[-- Type: application/octet-stream, Size: 775 bytes --]
From 81a6920517e5e2d9ac6f5b3e464b64b550f07049 Mon Sep 17 00:00:00 2001
From: Lizhe <sensor1010@163.com>
Date: Thu, 11 Jan 2024 20:57:01 -0800
Subject: [PATCH] drivers/dm-crypt.c : remove redundant state settings after
waking up
The task status has been set to TASK_RUNNING in schedule().
No need to set again here.
Signed-off-by: Lizhe <sensor1010@163.com>
---
drivers/md/dm-crypt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 855b482cbff1..ab1e30630e64 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1948,7 +1948,6 @@ static int dmcrypt_write(void *data)
schedule();
- set_current_state(TASK_RUNNING);
spin_lock_irq(&cc->write_thread_lock);
goto continue_locked;
--
2.25.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-12 5:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-10 14:13 [PATCH] hrtimer.c : Remove redundant thread state settings Lizhe
2024-01-11 16:44 ` Thomas Gleixner
2024-01-12 5:03 ` lizhe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox