Just discovered this flag while tightening a policy for a logging sidecar. Most of us use `SECCOMP_RET_KILL_THREAD` or `SECCOMP_RET_TRAP` in our seccomp filters. The default for a violation in a container runtime is usually `KILL_THREAD`, which, in a single-threaded container, terminates the container.

But `SECCOMP_RET_KILL_PROCESS` (since Linux 4.14) is different. It terminates **every thread in the calling process**, immediately. No signals, no cleanup. It's nuclear.

Why does this matter? If you have a multi-threaded workload and one thread violates the policy, `KILL_THREAD` might just kill that worker thread, potentially leaving the process in a weird, degraded state. `KILL_PROCESS` guarantees the entire workload is taken down, which is often what you actually want for a security violation. The orchestrator (K8s) can then restart it.

Here's a snippet from a filter definition. The key is in the `defaultAction`:

```json
{
"defaultAction": "SCMP_ACT_KILL_PROCESS",
"architectures": [
"SCMP_ARCH_X86_64"
],
"syscalls": [
{
"names": [
"read",
"write",
"close",
"fstat",
...
],
"action": "SCMP_ACT_ALLOW"
}
]
}
```

Deploying this? Remember:
* Your container runtime must support it (most modern ones do).
* This is a sledgehammer. Make sure your allowed syscall list is correct **before** you ship it to prod, or you'll be restarting pods constantly.
* The audit log will show `KILL_PROCESS` as the action, which is useful for forensics.

The blunt take: If you're defining a seccomp profile, you should probably be using `KILL_PROCESS` for your default action instead of `KILL_THREAD`. The degraded-state scenario you avoid is worse than the occasional overzealous restart.