On 3/9/20 8:02 PM, Eric W. Biederman wrote: > Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> writes: > >> On 3/9/20 7:36 PM, Eric W. Biederman wrote: >>> >>> >>> Does that sound better? >>> >> >> almost done. > > I think this text is finally clean. > > exec: Add exec_update_mutex to replace cred_guard_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 make a different system call that winds up 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_update_mutex one by one. This lets us move forward while still > 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") I checked the urls they all work. Just one last question, are these git references? I can't find them in my linux git tree (cloned from linus' git)? Sorry for being pedantically. > Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > > Bernd do you want to give me your Reviewed-by for this part of the > series? > Sure also the other parts of course. Reviewed-by: Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> > After that do you think you can write the obvious patch for mm_access? > Yes, I can do that. I also have some typos in comments, will make them extra patches as well. I wonder if the test case is okay to include the ptrace_attach altough that is not yet passing? Thanks Bernd.
