Revert `cgroup.kill` workaround once upstream Linux fixes `clone3(CLONE_INTO_CGROUP)` interaction

[EtiennePerot]

Regarding these lines:

sandboxd/pkg/cgroupmanager/ops_v2.go

Lines 217 to 224 in f8b2833

	// cgroup.kill is sticky while tasks from the previous sandbox are still
	// being reaped. Writing it for an already empty cgroup can therefore kill
	// the first process cloned into a recycled cgroup.
	if len(processes) > 0 {
	if err := group.Kill(); err != nil {
	return err
	}
	}

This behavior is not intended Linux behavior. I have sent an upstream kernel patch here: https://lore.kernel.org/all/20260828215252.4126811-1-eperot@google.com/T/

Once/if this is merged, it may be useful to remove this.

[tianyuzhou95]

Thanks @EtiennePerot for identifying this and for carrying the fix upstream.

You are right that sandboxd's existing workaround was neither elegant nor complete. It only avoided writing cgroup.kill when the cgroup was already empty, which reduced exposure to the kernel bug but did not handle the case where residual processes still required cleanup.

#43 replaces cgroup.kill in the cgroup v2 recycle path with explicit PID enumeration and SIGKILL, matching the current cgroup v1 approach.

We will keep this issue open to track restoring the atomic cgroup.kill path once the upstream fix torvalds/linux@8e35992 has reached the stable kernels supported by sandboxd. Thanks again for the detailed report.