linuxkpi: Only reset task state if non-indefinite timeout in `schedule_timeout()`
AbandonedPublic
Actions

Authored by dumbbell on Apr 19 2025, 2:02 PM.

Tags

None

Referenced Files

	Unknown Object (File)
	Fri, Sep 25, 1:27 PM

	Unknown Object (File)
	Fri, Sep 25, 11:11 AM

	Unknown Object (File)
	Fri, Sep 25, 5:13 AM

	Unknown Object (File)
	Fri, Sep 25, 5:11 AM

	Unknown Object (File)
	Aug 13 2026, 6:07 PM

	Unknown Object (File)
	Aug 12 2026, 3:45 PM

	Unknown Object (File)
	Aug 12 2026, 1:22 AM

	Unknown Object (File)
	Aug 11 2026, 5:30 PM

View All 86 Files

Subscribers

emaste

imp

Details

Reviewers

markj

Group Reviewers

linuxkpi

Summary

On Linux, if there is no specified timeout (i.e., the timeout is set to MAX_SCHEDULE_TIMEOUT), the task state is left unchanged.

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

dumbbell created this revision.Apr 19 2025, 2:02 PM

Herald added subscribers: emaste, imp. · View Herald TranscriptApr 19 2025, 2:02 PM

dumbbell requested review of this revision.Apr 19 2025, 2:02 PM

dumbbell mentioned this in D48755: linuxkpi: Add `woken_wake_function()` and `wait_woken()` .

On Linux, if there is no specified timeout (i.e., the timeout is set to MAX_SCHEDULE_TIMEOUT), the task state is left unchanged.

The herald comment for schedule_timeout() also states that the thread state is guaranteed to be TASK_RUNNING upon return. I'd assume that something in the scheduler resets the task state.

Is one of the drm drivers actually affected by this?

You are right, I misread the comment and code in Linux source code.

I didn’t spot any problem with DRM drivers, just thought there was an inconsistency compared to Linux. I will abandon this review.

Revision Contents
Changeset List

Path

Size

sys/

compat/

linuxkpi/

common/

src/

linux_schedule.c

3 lines

Diff 153917

View Options

sys/compat/linuxkpi/common/src/linux_schedule.c

linuxkpi: Only reset task state if non-indefinite timeout in `schedule_timeout()`AbandonedPublicActions