On 3/9/20 7:36 PM, Eric W. Biederman wrote: > > My rewritten change description reads as follows: > > exec: Add a exec_update_mutex to replace cred_guard_mutex is this "an" exec_update_mutex? > > The cred_guard_mutex is problematic as it is held over possibly > indefinite waits for userspace. The possilbe indefinite waits for > userspace that I have identified are: The cred_guard_mutex is held in > PTRACE_EVENT_EXIT waiting for the tracer. The cred_guard_mutex is > held over "put_user(0, tsk->clear_child_tid)" in exit_mm(). The > cred_guard_mutex is held over "get_user(futex_offset, ...") in > exit_robust_list. The cred_guard_mutex held over copy_strings. > > The functions get_user and put_user can trigger a page fault which can > potentially wait indefinitely in the case of userfaultfd or if > userspace implements part of the page fault path. > > In any of those cases the userspace process that the kernel is waiting > for might userspace might make a different system call that winds up ^-------------^ ^- remove this > taking the cred_guard_mutex and result in deadlock. > > Holding a mutex over any of those possibly indefinite waits for > userspace does not appear necessary. Add exec_update_mutex that will > just cover updating the process during exec where the permissions and > the objects pointed to by the task struct may be out of sync. > > 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 ^-- typo: update > being careful and not introducing any regressions. > > Link: https://lore.kernel.org/lkml/20160921152946.GA24210@xxxxxxxxxxxxxx/ > Link: https://lore.kernel.org/lkml/AM6PR03MB5170B06F3A2B75EFB98D071AE4E60@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > Link: https://lore.kernel.org/linux-fsdevel/20161102181806.GB1112@xxxxxxxxxx/ > Link: https://lore.kernel.org/lkml/20160923095031.GA14923@xxxxxxxxxx/ > Link: https://lore.kernel.org/lkml/20170213141452.GA30203@xxxxxxxxxx/ > Ref: 45c1a159b85b ("Add PTRACE_O_TRACEVFORKDONE and PTRACE_O_TRACEEXIT facilities.") > Ref: 456f17cd1a28 ("[PATCH] user-vm-unlock-2.5.31-A2") > Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > Does that sound better? > almost done. > Eric >