linux-kernel - [scheduler] questions around scheduler, task states, etc.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <d9c750c7-6a30-437b-90a5-e6e786f803fc@windriver.com>
Date: Mon, 14 Apr 2025 12:00:36 -0600
From: Chris Friesen <chris.friesen@...driver.com>
To: LKML <linux-kernel@...r.kernel.org>
Subject: [scheduler] questions around scheduler, task states, etc.

In do_wait(), we basically do:

add_wait_queue()
set_current_state(TASK_INTERRUPTIBLE)
__do_wait()
schedule()
__set_current_state(TASK_RUNNING)
remove_wait_queue()

Would it be valid to move the set_current_state(TASK_INTERRUPTIBLE) call 
to *after* the call to __do_wait()?   Or would that break something?

The reason I ask is that I'm working on a system (6.6 kernel with RT 
patches) that uses stalld, and it only evaluates tasks in the 
TASK_RUNNING state.  There seems to be a code path in __do_wait() where 
the code can be preempted by a high-priority CPU hog while partially 
holding tasklist_lock, and this leads to bad things because stalld 
doesn't consider the preempted task as actually being runnable due to 
the task state being TASK_INTERRUPTIBLE.

If we could defer setting the state to TASK_INTERRUPTIBLE until right 
before we call schedule(), I think that would avoid the issue.

I'm not currently subscribed to the list, so please CC me on replies.

Thanks,
Chris Friesen