[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+bck9DxYrq89waGAqAyYhk6+nrFg8k99KUiyzJQ=+UdCA@mail.gmail.com>
Date: Tue, 6 Nov 2018 08:32:48 -0800
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: syzbot <syzbot+6339eda9cb4ebbc4c37b@...kaller.appspotmail.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs@...glegroups.com
Subject: Re: INFO: task hung in fuse_sb_destroy
On Mon, Nov 5, 2018 at 4:03 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Mon, Nov 5, 2018 at 11:40 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>> On Thu, Nov 1, 2018 at 12:05 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>>> On Thu, Nov 1, 2018 at 11:49 AM, syzbot
>>> <syzbot+6339eda9cb4ebbc4c37b@...kaller.appspotmail.com> wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit: 59fc453b21f7 Merge branch 'akpm' (patches from Andrew)
>>>> git tree: upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15fb2447400000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=ea045471e4c756e8
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=6339eda9cb4ebbc4c37b
>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=178a105d400000
>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16651133400000
>>>
>>>
>>> I can easily reproduce this.
>>
>> I can't reproduce on my meager dual core notebook.
>>
>>>
>>> The repro gives me a task hanged at:
>>>
>>> # cat /proc/7563/task/*/stack
>>> [<0>] fuse_wait_aborted+0x20b/0x320
>>> [<0>] fuse_sb_destroy+0xe2/0x1d0
>>> [<0>] fuse_kill_sb_anon+0x15/0x20
>>> [<0>] deactivate_locked_super+0x97/0x100
>>> [<0>] deactivate_super+0x2bb/0x320
>>> [<0>] cleanup_mnt+0xbf/0x160
>>> [<0>] __cleanup_mnt+0x16/0x20
>>> [<0>] task_work_run+0x1e8/0x2a0
>>> [<0>] exit_to_usermode_loop+0x318/0x380
>>> [<0>] do_syscall_64+0x6be/0x820
>>> [<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>> [<0>] 0xffffffffffffffff
>>>
>>> I double checked that writing to /sys/fs/fuse/connections/44/abort did
>>> not help (the only entry in fuse/connections). Wrote multiple times,
>>> and tried to kill the task, nothing helps.
>>
>> What's the output of
>>
>> cat /sys/fs/fuse/connections/NN/waiting
>>
>> ?
>
> I think I found the culprit. Does the attached patch fix it?
Hi Miklos,
I am travelling for next weeks, but you can ask syzbot to test any patches:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
Powered by blists - more mailing lists