Process cleanup semantics#69
Conversation
Co-authored-by: Albert Slepak <FlareCoding@users.noreply.github.com>
Co-authored-by: Albert Slepak <FlareCoding@users.noreply.github.com>
Co-authored-by: Albert Slepak <FlareCoding@users.noreply.github.com>
Co-authored-by: Albert Slepak <FlareCoding@users.noreply.github.com>
|
Cursor Agent can help with this pull request. Just |
Co-authored-by: Albert Slepak <FlareCoding@users.noreply.github.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| task->block_kind = TASK_BLOCK_NONE; | ||
| task->blocked_wait_queue = nullptr; | ||
| task->terminate_requested = 0; | ||
| } |
There was a problem hiding this comment.
Missing __PRIVILEGED_CODE on do_exit_current
High Severity · Logic Bug
do_exit_current was extracted from inline code inside a RUN_ELEVATED block in sched::exit(), but the new standalone function lacks the __PRIVILEGED_CODE annotation. It is called directly from maybe_terminate_current() which IS __PRIVILEGED_CODE, and it itself calls privileged functions like sync::spin_lock_irqsave, sync::wake_all, and store_cleanup_stage. This function needs __PRIVILEGED_CODE to be placed in the privileged code section, matching the annotation pattern of every other static helper in this file that touches scheduler/sync internals.
| } | ||
| } else if (block_kind == TASK_BLOCK_TIMER) { | ||
| timer::cancel_sleep(t); | ||
| } |
There was a problem hiding this comment.
TOCTOU race in terminate vs wait entry
Medium Severity · Potential Edge Case
request_terminate reads t->state without holding the target wait queue's lock. If the target task is between the termination_requested check in sync::wait and setting its state to TASK_STATE_BLOCKED, request_terminate sees RUNNING, skips the cancel_wait/cancel_sleep, and returns. The task then enters blocked state with terminate_requested already set. It stays blocked until whatever it's waiting on fires naturally — if that event never arrives (e.g., blocked on I/O or an unrelated wait queue), the task is stuck and terminate_proc_resource_with_epoch deadlocks waiting for pr->exited.


Add
proc_killsyscall and implement recursive process termination on parent exit or explicit kill.This PR addresses the need for robust process management by ensuring that child processes are properly terminated when their parent exits without waiting, or when explicitly killed, preventing orphaned processes and kernel panics.