proc: deuglify task_state()
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest4 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | proc: task_state: read cred->group_info outside of task_lock()fs/ | +1 | 0 replies | |
| 2/4 | proc: task_state: deuglify the max_fds calculationfs/ | +11 | 0 replies | |
| 3/4 | proc: task_state: move the main seq_printf() outside of rcu_read_lock()fs/ | +6 | 1 reply | |
| 4/4 | proc: task_state: ptrace_parent() doesn't need pid_alive() checkfs/ | +6 | 0 replies |
Reviews trailers per patch
1 of 4 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | Peter Zijlstra (Intel) | Paul E. McKenney | Eric W. Biederman |
|---|---|---|---|
| Series | A-b | R-b | |
| 1/4 | |||
| 2/4 | |||
| 3/4 | R-b | ||
| 4/4 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 3 reviewers.
Cover letter [PATCH 0/4] proc: deuglify task_state()
Hello.
I tried to optimize the usage of tasklist_lock in exit_notify() paths but found the bug which should be fixed first: the EXIT_DEAD setting in reparent_leader() can break the task_ppid_nr_ns()-like code and ptrace_parent().
I am still thinking about the "right" fix, but whatever we do we need to cleanup these users, probably before the fix.
One particular user is task_state(), but it also asks for other off- topic cleanups which I believe make sense anyway, lets do this first.
Oleg.
fs/proc/array.c | 47 ++++++++++++++++++++++------------------------- 1 files changed, 22 insertions(+), 25 deletions(-)