We currently union the UNMASKABLE_SIGNALS set with the new signal mask.
This does the complete opposite of what we wnat, we want to *remove*
those signals from the newly computed signal mask.
This patch removes the UNMASKABLE_SIGNALS set from any newly computed
signal mask.
Make it such that when a ptrace event is hit:
- The current regset is saved in the ptrace state.
- The current task is put to sleep.
- Arrange for a SIGCHLD to be set to the parent.
- Notify any waiters with the appopriate signal.
This commit refactors the signal handling subsystem to address a bug in
process creation and to improve the separation of concerns between
signal delivery and signal disposition.
1. Fix Action Table Sharing:
Previously, the signal action table was wrapped in an `Arc`, causing
forked child processes to inadvertently share signal dispositions with
the parent. `SignalActionState` now contains a direct `SigActionSet` and
implements Clone, ensuring that processes receive a private copy of the
action table upon fork/clone.
2. Decouple Signal Selection from Execution:
The logic for selecting a pending signal has been moved from the
disposition state into a new `take_signal` method on `OwnedTask`. This
decouples the "taking" of a signal (respecting masks and priorities)
from the "actioning" of that signal. This is a prerequisite for
implementing ptrace.
3. Various cleanup bits:
- Renamed `SignalState` to `SignalActionState` to more accurately
reflect that it manages signal dispositions.
- Removed the `pending` signal set out of the action state and directly
into the `ThreadGroup` and `OwnedTask`.
- Renamed `set_pending` to `set_signal` for consistency.
- Simplified the signal delivery loop in `dispatch_userspace_task`
using the new `take_signal` API.
Implement FUTEX_{WAKE,WAIT}_BITSET by using a `u32` as a data
discriminant value.
Also add a bunch of tests to `usertest` to ensure proper functionality.
Currently, each task implements it's own priority value. In Linux, each
thread group (process) has a default process which all tasks in that
group inherit. Tasks can, however, override the default process
priority.
Implement that logic here which also fixes the current compilation error
on master.
This commit refactors the core process representation to decouple
"Identity/Resources" from "Execution/Scheduling". Previously, a
monolithic `Task` struct wrapped in `Arc<SpinLock<>>` caused lock
contention during hot scheduling paths and conflated shared state with
CPU-local state.
The `Task` struct has been split into:
1. `Task` (Shared): Holds process-wide resources (VM, FileTable,
Credentials). Managed via `Arc` and internal fine-grained locking.
2. `OwnedTask` (Private): Holds execution state (Context, v_runtime,
signal mask). Strictly owned by a specific CPU (via the Scheduler) and
accessed lock-free.
Key changes:
* Scheduler:
chedState` now owns tasks via `Box<OwnedTask>`.
- Transitions between `run_queue` and `running_task` involve strictly
moving ownership of the Box, ensuring pointer stability.
- The EEVDF comparison logic now explicitly handles comparisons
between the queued candidates and the currently running task (which is
not in the queue).
* Current Task Access:
- `current()` now returns a `CurrentTaskGuard` which:
1. Disables preemption (preventing context switches while holding
the reference).
2. Performs a runtime borrow check (panic on double-mutable borrow).
3. Dereferences a cached Per-CPU raw pointer for O(1) access.
Make the global `TASK_LIST` struct be a collection of `Task`s, rather
than `task.state` struct members. This allows other cores to access to
any shared task state easily.
Use EEVDF concepts like virtual deadline correctly and actually calculate the necessary deadline and use it to schedule.
Also dynamically preempts based on the deadline.
The `timeout` parameter is only used for `_WAIT` futex ops. For other
ops, the `timeout` parameter is permitted to be an undefied value. The
current implementation would then try to `copy_from_user` using the
garbage pointer and fault, causing a missed wake-up and deadlock the
calling process.
Fix this by only accessing the timeout parmeter for `_WAIT` futex ops
where the parameter's value must be valid.
When a future returns `Poll::Pending`, there is a window where, if a
waker is called, prior to the sched code setting the task's state to
`Sleeping`, the wake-up could be lost. We get around this by
introducing a new state `Woken`.
A waker will set a `Running` task to this state. The sched code then
detects this and *does not* set the task's state to `Sleeping`, instead
it leaves it as running and attempts to re-schedule.
