deadlock from exec_update_lock and reading procfs

[Benjamin Peterson]

After receiving a kernel with 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)"), we encountered a new deadlock in a FUSE server. The FUSE server reads /proc/PID/stat in the file flush callback, where PID is the pid of flushing process. This can deadlock in exec_update_lock acquisition when the flushing process is closing O_CLOEXEC files.

Specifically, a process running execve is blocked with this stack:

__schedule+0x505/0xc00
schedule+0x27/0xc0
request_wait_answer+0x158/0x2a0
__fuse_simple_request+0xd7/0x290
fuse_flush+0x1a4/0x1e0
filp_flush+0x30/0x60
filp_close+0x13/0x30
do_close_on_exec+0x114/0x160
begin_new_exec+0x553/0xb50
load_elf_binary+0x2da/0x1770
? load_misc_binary+0x275/0x390 [binfmt_misc]
bprm_execve+0x241/0x5f0
do_execveat_common.isra.0+0x182/0x1c0
__x64_sys_execve+0x36/0x40
do_syscall_64+0x87/0x180

while the FUSE server is blocked here:

__schedule+0x505/0xc00
schedule+0x27/0xc0
schedule_preempt_disabled+0x15/0x30
rwsem_down_read_slowpath+0x25c/0x480
down_read_killable+0x48/0xc0
do_task_stat+0x7f/0xec0
proc_single_show+0x51/0xc0
seq_read_iter+0x11f/0x460
seq_read+0x12d/0x160
vfs_read+0xe8/0x360
ksys_read+0x6d/0xf0
do_syscall_64+0x87/0x180


This problems seems to have been acknowledged as a theoretical possibility in the original patch review thread [1]. Now that it's a practical problem, is it feasible to move do_close_on_exec outside the scope of exec_update_lock?

Best regards, Benjamin

[1] https://lore.kernel.org/all/CAG48ez2pmuoTCZh_AVKDDLeQEYmm=gLMgThnqFhRMFfZvABpdw@xxxxxxxxxxxxxx/