exit: reparent zombie fix + cleanups/optimizations
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | sched_show_task: fix unsafe usage of ->real_parentkernel/ | +3 | 1 reply | |
| 2/5 | exit: reparent: use ->ptrace_entry rather than ->sibling for EXIT_DEAD taskskernel/ | +3 | 0 replies | |
| 3/5 | exit: reparent: cleanup the changing of ->parentkernel/ | +5 | 0 replies | |
| 4/5 | exit: reparent: cleanup the usage of reparent_leader()kernel/ | +9 | 0 replies | |
| 5/5 | exit: ptrace: shift "reap dead" code from exit_ptrace() to forget_original_parent()include/ kernel/ kernel/ | +8 | 0 replies |
Reviews trailers per patch
1 of 5 patches has a Reviewed-by or Acked-by.
| Patch | Peter Zijlstra (Intel) |
|---|---|
| 1/5 | A-b |
| 2/5 | |
| 3/5 | |
| 4/5 | |
| 5/5 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/5] exit: reparent zombie fix + cleanups/optimizations
Hello.
Quoted 8 lines · Oleg Nesterov
I tried to optimize the usage of
tasklist_lockinexit_notify()paths but found the bug which should be fixed first: theEXIT_DEADsetting inreparent_leader()can break the task_ppid_nr_ns()-like code andptrace_parent().I am still thinking about the "right" fix, but whatever we do we need to cleanup these users, probably before the fix.
Yes, we need to cleanup these users but lets fix the bug first. See the changelog in 2/5.
Plus cleanups + initial (micro)optimizations, more to come.
Oleg.
include/linux/ptrace.h | 2 +- kernel/exit.c | 51 +++++++++++++++++++---------------------------- kernel/ptrace.c | 23 ++------------------ kernel/sched/core.c | 4 ++- 4 files changed, 28 insertions(+), 52 deletions(-)