[lkml]   [2018]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: INFO: task hung in fuse_reverse_inval_entry
On Mon, Jul 23, 2018 at 10:11 AM, Dmitry Vyukov <> wrote:
> On Mon, Jul 23, 2018 at 9:59 AM, syzbot
> <> wrote:
>> Hello,
>> syzbot found the following crash on:
>> HEAD commit: d72e90f33aa4 Linux 4.18-rc6
>> git tree: upstream
>> console output:
>> kernel config:
>> dashboard link:
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:
>> C reproducer:
> Hi fuse maintainers,
> We are seeing a bunch of such deadlocks in fuse on syzbot. As far as I
> understand this is mostly working-as-intended (parts about deadlocks
> in Documentation/filesystems/fuse.txt). The intended way to resolve
> this is aborting connections via fusectl, right?

Yes. Alternative is with "umount -f".

> The doc says "Under
> the fuse control filesystem each connection has a directory named by a
> unique number". The question is: if I start a process and this process
> can mount fuse, how do I kill it? I mean: totally and certainly get
> rid of it right away? How do I find these unique numbers for the
> mounts it created?

It is the device number found in st_dev for the mount. Other than
doing stat(2) it is possible to find out the device number by reading
/proc/$PID/mountinfo (third field).

> Taking into account that there is usually no
> operator attached to each server, I wonder if kernel could somehow
> auto-abort fuse on kill?

Depends on what the fuse server is sleeping on. If it's trying to
acquire an inode lock (e.g. unlink(2)), which is classical way to
deadlock a fuse filesystem, then it will go into an uninterruptible
sleep. There's no way in which that process can be killed except to
force a release of the offending lock, which can only be done by
aborting the request that is being performed while holding that lock.


 \ /
  Last update: 2018-07-23 14:13    [W:0.072 / U:2.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site