Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> 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 <bernd.edlinger@xxxxxxxxxx> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> >> >> >> 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 myself. Eric
