|
From: Sargun Dhillon <sa...@sa...> - 2019-02-27 23:02:15
|
We have a FUSE daemon, and users that access them that run in a pid
namespace. When the pid namespace is torn down, we end up in a
situation where in userspace, a user gets stuck. Specifically, they
get stuck in request_wait_answer.
PID: 3655410 TASK: ffff8bc9f87ada00 CPU: 55 COMMAND: "mount.objective"
#0 [ffffb12820137ca8] __schedule at ffffffffb5aecf8d
#1 [ffffb12820137d40] schedule at ffffffffb5aed492
#2 [ffffb12820137d50] request_wait_answer at ffffffffb558ec1a
#3 [ffffb12820137da8] __fuse_request_send at ffffffffb558ff1f
#4 [ffffb12820137dc8] fuse_readdir at ffffffffb5594022
#5 [ffffb12820137e78] iterate_dir at ffffffffb548a1ae
#6 [ffffb12820137eb8] __x64_sys_getdents at ffffffffb548ad29
#7 [ffffb12820137f38] do_syscall_64 at ffffffffb5204185
#8 [ffffb12820137f50] entry_SYSCALL_64_after_hwframe at ffffffffb5c00088
RIP: 00007fdae2d888eb RSP: 00007fdadcc9fcf0 RFLAGS: 00000206
RAX: ffffffffffffffda RBX: 00007fda840008f0 RCX: 00007fdae2d888eb
RDX: 0000000000020000 RSI: 00007fda840008f0 RDI: 0000000000000040
RBP: 00007fda840008f0 R8: 00007fda84000000 R9: 0000000000000001
R10: 0000000000000000 R11: 0000000000000206 R12: 00007fdadcc9fe20
R13: 00007fda840008c0 R14: 0000000000000000 R15: 00007fdae3ba7250
ORIG_RAX: 000000000000004e CS: 0033 SS: 002b
Is there a reason why at the end of request_wait_answer, it doesn't
wait_killable, and then when a fatal signal comes in, the request is
aborted, if it is not locked?
|