[lkml]   [2020]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 5/5] exec: Add a exec_update_mutex to replace cred_guard_mutex

On 3/9/20 8:02 PM, Eric W. Biederman wrote:
> Bernd Edlinger <> 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:
> Link:
> Link:
> Link:
> Link:
> 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" <>
> 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 <>

> 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?


 \ /
  Last update: 2020-03-09 20:25    [W:0.215 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site