Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <Y00b31dX1mIfgnBP@xpf.sh.intel.com>
In-Reply-To: <Y00b31dX1mIfgnBP@xpf.sh.intel.com>
From:   Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue, 18 Oct 2022 11:23:17 +0200
Message-ID: <CAOssrKfakpGguAV=102jpW4m+YfpRx=+cBBO1O43bt3iwJHiSA@mail.gmail.com>
Subject: Re: [Syzkaller] INFO: task hung in fuse_lookup with v6.0 kernel in guest
To:     Pengfei Xu <pengfei.xu@intel.com>
Cc:     linux-kernel@vger.kernel.org, heng.su@intel.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Oct 17, 2022 at 11:17 AM Pengfei Xu <pengfei.xu@intel.com> wrote:
>
> Hi Miklos,
>
> Greeting!
>
> Platform: Tiger lake CPU platform.
>
> We found 1 "task hung in fuse_lookup" issue by syzkaller with v6.0 mainline
> kernel in guest.
>
> Bisected and found the bad commit:
> "
> commit:  62dd1fc8cc6b22e3e568be46ebdb817e66f5d6a5
> fuse: move fget() to fuse_get_tree()
> "
>
> Reproduced code generated by syzkaller, binary, bisect log and all the dmesg
> info are in attached package.

Thanks for the report.

I tried out the reproducer, and the deadlock can be triggered.
Unfortunately killing the deadlocked processes is not enough, but it
still should be possible to recover with "echo 1 >
/sys/fs/fuse/connections/$FUSE_DEV/abort".    In my tests this works,
so I'm not sure there's anything to fix here.

Is there a real life situation where this occurs, or is this just
triggered with fuzzing?

I'm wondering why syzbot didn't try aborting using the "abort" file in
sysfs, AFAICS it does know this trick.

Thanks,
Miklos