Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex
From: Bernd Edlinger <hidden>
Date: 2020-03-09 13:46:02
Also in:
linux-api, linux-doc, linux-fsdevel, lkml, stable
Possibly related (same subject, not in this thread)
- 2020-03-17 · Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex · Kirill Tkhai <hidden>
- 2020-03-15 · Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex · Bernd Edlinger <hidden>
- 2020-03-15 · Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex · Bernd Edlinger <hidden>
- 2020-03-13 · Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex · Kirill Tkhai <hidden>
- 2020-03-13 · Re: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex · Bernd Edlinger <hidden>
On 3/8/20 10:38 PM, Eric W. Biederman wrote:
The cred_guard_mutex is problematic. The cred_guard_mutex is held over the userspace accesses as the arguments from userspace are read. The cred_guard_mutex is held of PTRACE_EVENT_EXIT as the the other
... is held while waiting for the trace parent to handle PTRACE_EVENT_EXIT or something? I wonder if we also should mention that it is held while waiting for the trace parent to receive the exit code with "wait"?
threads are killed. The cred_guard_mutex is held over "put_user(0, tsk->clear_child_tid)" in exit_mm(). Any of those can result in deadlock, as the cred_guard_mutex is held over a possible indefinite userspace waits for userspace. Add exec_update_mutex that is only held over exec updating process
Add ?
with the new contents of exec, so that code that needs not to be confused by exec changing the mm and the cred in ways that can not happen during ordinary execution of a process. The plan is to switch the users of cred_guard_mutex to exec_udpate_mutex one by one. This lets us move forward while still
s/udpate/update/ Bernd.