fuse: in fuse_flush only wait if someone wants the return code
authorEric W. Biederman <ebiederm@xmission.com>
Thu, 26 Jan 2023 16:10:58 +0000 (17:10 +0100)
committerMiklos Szeredi <mszeredi@redhat.com>
Thu, 26 Jan 2023 16:10:58 +0000 (17:10 +0100)
commit5a8bee63b10f6f2f52f6d22e109a4a147409842a
tree00e1f278a3e3bd8f328002dbdd0fef0701f8ac99
parent8ed7cb3f279fe67a93f407ee2ec3ea661a483a65
fuse: in fuse_flush only wait if someone wants the return code

If a fuse filesystem is mounted inside a container, there is a problem
during pid namespace destruction. The scenario is:

1. task (a thread in the fuse server, with a fuse file open) starts
   exiting, does exit_signals(), goes into fuse_flush() -> wait
2. fuse daemon gets killed, tries to wake everyone up
3. task from 1 is stuck because complete_signal() doesn't wake it up, since
   it has PF_EXITING.

The result is that the thread will never be woken up, and pid namespace
destruction will block indefinitely.

To add insult to injury, nobody is waiting for these return codes, since
the pid namespace is being destroyed.

To fix this, let's not block on flush operations when the current task has
PF_EXITING.

This does change the semantics slightly: the wait here is for posix locks
to be unlocked, so the task will exit before things are unlocked. To quote
Miklos:

  "remote" posix locks are almost never used due to problems like this, so
  I think it's safe to do this.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
Link: https://lore.kernel.org/all/YrShFXRLtRt6T%2Fj+@risky/
Tested-by: Tycho Andersen <tycho@tycho.pizza>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
fs/fuse/file.c