[lkml]   [2020]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 4/5] exec: Move exec_mmap right after de_thread in flush_old_exec
Bernd Edlinger <> writes:

> On 3/9/20 8:58 PM, Eric W. Biederman wrote:
>> Ok. I think this has it sorted:
>> exec: Move exec_mmap right after de_thread in flush_old_exec
>> I have read through the code in exec_mmap and I do not see anything
>> that depends on sighand or the sighand lock, or on signals in anyway
>> so this should be safe.
>> This rearrangement of code has two significant benefits. It makes
>> the determination of passing the point of no return by testing bprm->mm
>> accurate. All failures prior to that point in flush_old_exec are
>> either truly recoverable or they are fatal.
>> Further this consolidates all of the possible indefinite waits for
>> userspace together at the top of flush_old_exec. The possible wait
>> for a ptracer on PTRACE_EVENT_EXIT, the possible wait for a page fault
>> to be resolved in clear_child_tid, and the possible wait for a page
>> fault in exit_robust_list.
>> This consolidation allows the creation of a mutex to replace
>> cred_guard_mutex that is not held over possible indefinite userspace
>> waits. Which will allow removing deadlock scenarios from the kernel.
>> Reviewed-by: Bernd Edlinger <>
>> Signed-off-by: "Eric W. Biederman" <>
>> I don't think I usually have this many typos. Sigh.
> OK.
> never mind,

No no. I really appreciate all of the scrutiny. Frequently the issues
that will produce typos or poor patch descriptions are also the issues
that will produce sloppy patches as well. I was just frustrated with


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