Topic 05: Live Process Tree Surgery, Reparenting & Subtree Termination

Target Duration: 2–4 minutes (~300–450 spoken words)
Focus: Pointwise verbal delivery covering live process hierarchy mutation under tasklist_lock, pointer surgery (parent / real_parent), asynchronous SIGCHLD reaping by adopting parents, and recursive subtree termination.

🎙️ Pointwise Spoken Speech (Word-for-Word Delivery)

• Opening & Scope:
  "In Part 2.2, I implemented a kernel character driver (2.2/chardev.c) that performs live process tree surgery: dynamically reparenting running processes to an unrelated supervisor process without fork(), and executing recursive signal delivery across entire process subtrees."

• Step 1: The Process Reparenting Problem:
  "First, under standard POSIX semantics, a process's parent is immutably set at fork() time. If a process exits, its exit code and resource accounting can only be reaped by its immediate parent; otherwise, it reparents to init (PID 1) upon orphaning. The challenge in Part 2.2 was allowing an independent supervisor (2.2/control_station.c) to adopt worker processes (2.2/soldier.c) on the fly, becoming their legal parent so it can receive their SIGCHLD and reap them."

• Step 2: Tree Surgery Under tasklist_lock:
  "Next, to modify the process hierarchy safely, holding the right lock is critical. The kernel process tree is protected by tasklist_lock. In change_parent() (2.2/chardev.c:26), the driver resolves the new parent via pid_task(find_vpid(tpid)) (2.2/chardev.c:32) and safely synchronizes pointer mutations across scheduler ticks."

• Step 3: Unlinking and Splicing Task Hierarchy Pointers:
  "Then, inside the critical section, I performed the pointer surgery:

  1. I removed the target task from its old parent's children list using list_del_init(&current->sibling) (2.2/chardev.c:40).
  2. I updated both current->parent and current->real_parent to point to the new supervisor task_struct using RCU_INIT_POINTER() (2.2/chardev.c:43-44).
  3. I spliced the task into the new parent's children list using list_add_tail_rcu(&current->sibling, &parent_task->children) (2.2/chardev.c:41). Finally, exiting the critical section made the new hierarchy active system-wide."

• Step 4: Asynchronous Zombie Reaping via SIGCHLD:
  "In user space, when a reparented soldier worker terminates, the kernel delivers SIGCHLD directly to the new adopting control_station. I configured control_station with a dedicated handler (sigchld_handler in 2.2/control_station.c:24) using sigaction with SA_RESTART | SA_NOCLDSTOP. Inside the handler, it executes a non-blocking waitpid(-1, &status, WNOHANG) loop to reap all exited children cleanly, preventing zombie process leaks."

• Step 5: Recursive Subtree Termination (kill_all):
  "Finally, I implemented a recursive subtree teardown command (kill_all() in 2.2/chardev.c:51). Triggered via ioctl, the driver iterates through the supervisor's children list using list_for_each_entry_rcu() (2.2/chardev.c:69), and dispatches signals to every process in the subtree using send_sig() (2.2/chardev.c:72, 85). This guarantees atomic and complete cleanup of multi-tier worker pools."

📋 Step-by-Step Summary (What, How & Why)

❓ Anticipated Interview Questions & Crisp Answers

Q1: Why reparent a running process dynamically without fork()? What practical problem in process supervision does this solve?

Answer: In standard Unix/Linux, parent-child relationships are permanently locked at fork(). If a long-running worker process is spawned by an ephemeral shell or deployment script, and that launcher terminates, the worker is orphaned to init (PID 1) or a subreaper. Standard Linux provides no user-space syscall to reassign parentage. The persistent monitoring daemon cannot receive the worker's exit signals (SIGCHLD) or inspect exit codes via waitpid(). Live reparenting in kernel space transfers custody dynamically, allowing a supervisor to adopt existing running processes without killing or restarting them.

Q2: What race conditions or crashes did you face during live process tree surgery, and why write_lock_irq?

Answer: Rewriting process relationships requires unlinking nodes from old_parent->children and splicing into new_parent->children while updating parent and real_parent pointers. If another CPU forks or exits a process simultaneously, or if a timer/hardware interrupt fires on the current CPU and attempts to read or modify process states (e.g., during scheduling or signal delivery), circular lists get corrupted, causing instant kernel panics or deadlock. We used write_lock_irq(&tasklist_lock), which disables local interrupts and locks the entire global tasklist across all CPUs during the pointer rewrites.

Q3: What happens if a reparented child exits, and how did you prevent zombie process leaks?

Answer: When an adopted worker exits, it enters TASK_ZOMBIE and delivers SIGCHLD to its new parent. Because our supervisor adopted multiple worker processes asynchronously, multiple workers could terminate simultaneously. POSIX signals are not queued—if multiple SIGCHLD signals arrive in rapid succession, the kernel coalesces them into a single delivery. A single waitpid() call would reap only one worker, leaking all others as permanent zombies. In our user-space control station, we installed a non-blocking reaping loop while (waitpid(-1, &status, WNOHANG) > 0) inside the SIGCHLD signal handler, guaranteeing that every adopted child is reaped immediately.