APPLIED: [SRU] [Bionic] [PATCH v2 0/1] fuse: fix deadlock with FUSE_PARALLEL_DIROPS

Khaled Elmously khalid.elmously at canonical.com
Tue Apr 23 05:56:16 UTC 2019


On 2019-04-12 16:35:41 , Andrea Righi wrote:
> Buglink: https://bugs.launchpad.net/bugs/1823972
> 
> [Impact]
> 
>  * Enabling parallel dirops in fuse (FUSE_PARALLEL_DIROPS) may cause a race
>    condition that leave fuse inode's mutex held, triggering a deadlock
> 
>  * The problem is that the lock and unlock paths are relying on
>    get_fuse_conn(inode)->parallel_dirops to decide if the mutex needs to be
>    acquired/released, but its value might be set in the lock path and unset in
>    the unlock path (leaving the mutex held)
> 
>  * See also: https://github.com/hanwen/go-fuse/issues/281
> 
> [Test Case]
> 
>  * A test case that triggers the bug almost immediately can be found here
>    https://github.com/hanwen/go-fuse/pull/288
> 
> [Fix]
> 
>  * Instead of relying on get_fuse_conn(inode)->parallel_dirops both in
>    fuse_lock_inode() and fuse_unlock_inode(), only check this flag in the
>    locking path and pass a variable to fuse_unlock_inode() to determine if the
>    mutex was acquired or not
> 
> [Regression Potential]
> 
>  * Fix has been tested on the affected platform. It is an upstream fix that
>    seems to affect only 4.7+ kernels, more exactly in our case only Bionic
>    kernels (and derived) are affected. Cosmic+ already include this fix. So
>    regression potential is minimal.
> 
> Changes in v2:
>  - resubmit the patch to fix this specific bug, instead of mixing it with a
>    bunch of other stable fixes (I'll create a separate bug to pull the other
>    missing stable fixes for fuse)
> 
> Miklos Szeredi (1):
>       fuse: fix initial parallel dirops
> 
>  fs/fuse/dir.c    | 10 ++++++----
>  fs/fuse/fuse_i.h |  4 ++--
>  fs/fuse/inode.c  | 14 ++++++++++----
>  3 files changed, 18 insertions(+), 10 deletions(-)
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team



More information about the kernel-team mailing list