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


On 3/9/20 8:02 PM, Eric W. Biederman wrote:
> Bernd Edlinger <bernd.edlinger@hotmail.de> 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@dhcp22.suse.cz/
> Link: https://lore.kernel.org/lkml/AM6PR03MB5170B06F3A2B75EFB98D071AE4E60@AM6PR03MB5170.eurprd03.prod.outlook.com/
> Link: https://lore.kernel.org/linux-fsdevel/20161102181806.GB1112@redhat.com/
> Link: https://lore.kernel.org/lkml/20160923095031.GA14923@redhat.com/
> Link: https://lore.kernel.org/lkml/20170213141452.GA30203@redhat.com/
> 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@xmission.com>
>
>
> 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@hotmail.de>

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

\
 
 \ /
  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