Re: [PATCH RFC v4 09/18] fs: make close_cloexec_files() synchronous

[Oleg Nesterov <oleg@redhat.com>]

On 09/10, Christian Brauner wrote:
>
> Punting file closing to task work during exec slows down exec
> significantly when its done with a bunch of file descriptors. We can
> do this in-band instead. Flush already runs synchronous. Jann moved
> close-on-exec in e780259b54e6 ("exec: do_close_on_exec() before taking
> exec_update_lock") outside of exec_update_lock.
>
> The only lock that's still held now is cred_guard_mutex. It's deprecated
> and has five takers
>
> (1) exec
> (2) ptrace_attach()
> (3) seccomp() with SECCOMP_FILTER_FLAG_TSYNC
> (4) writes to /proc/<pid>/attr/*
> (5) lsm_set_self_attr()
>
> Four of them take the task's own cred_guard_mutex. When
> close_cloexec_files() runs, de_thread() ensured that the calling task is
> the only one alive in its thread-group. That leaves ptrace() waiting on
> cred_guard_mutex of the tracee going through exec. exec already sleeps
> under cred_guard_mutex in de_thread() when it reads binary and
> interpreter. So while we add wait-time to an attaching ptracer no new
> lock dependency is added.

Plus ptrace has other issues with cred_guard_mutex, ptrace_attach() may
deadlock ;) So I agree this is not a problem.

I like 1-9 and believe they are correct with the additional fix

	[PATCH v3 08/17] exit: hang up the tty before closing the files
	https://lore.kernel.org/all/20260921-work-coredump-fixes-v3-8-8e4adb1619e6@kernel.org/

feel free to add

Reviewed-by: Oleg Nesterov <oleg@redhat.com>