pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaper
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest1 patch 1 replyIn review
- v11 patch 1 replySuperseded
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaperkernel/ | +2 | 1 reply |
Reviews trailers per patch
The patch has a Reviewed-by or Acked-by.
| Patch | Eric W. Biederman |
|---|---|
| 1/1 | A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH v2 -mm 0/1] pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaper
Quoted 10 lines · Eric W. Biederman
Quoted 1 line · Oleg Nesterov
Change
find_new_reaper()to usepid_ns->parent->child_reaper.Oleg this is a good catch for a real problem. However I disagree about the fix.
We should make
unhash_processsay:if ((task_active_pid_ns(parent)->child_reaper == parent) &&
Damn, I hate you^W^W^W thanks a lot Eric.
Indeed! Not only this is more simple, this is just more natural!
Quoted 1 line
And we should just set delete the code after
zap_pid_ns_processes
Yes, this is clear.
Quoted 2 lines
We could set pid_ns.child_reaper to NULL after that but why bother.
Agreed. Plus I do not think that pid_ns.child_reaper == NULL looks good even if this doesn't matter currently.
OK, please see v2. Note that I moved detach_pid(PIDTYPE_PID) back. Yes, yes, there is no real reason to do this. Just I think that if someone look at these changes later, it is not easy to understand why it was moved down.
Thanks!
Oleg.