Re: [Syzkaller] INFO: task hung in fuse_lookup with v6.0 kernel in guest

Re: [Syzkaller] INFO: task hung in fuse_lookup with v6.0 kernel in guest

[Pengfei Xu]

Hi,

I received the email that:"BOUNCE linux-kernel@vger.kernel.org: Message too
long (>6000000 chars)".

To avoid missing the attached log, I put all the info in below link:
https://github.com/xupengfe/syzkaller_logs/tree/main/221017_task_hung_in_fuse_lookup

It's reproduced in v6.0 mainline guest on TGL-H platform.
The dmesg that reproduces the issue with the v6.0 kernel in the guest is also
in the link above.

Thanks!
BR.


On 2022-10-17 at 17:09:51 +0800, Pengfei Xu 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.
> 
> Hope it's helpful.
> 
> Thanks!
> BR.

Re: [Syzkaller] INFO: task hung in fuse_lookup with v6.0 kernel in guest

[Miklos Szeredi]

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

Re: [Syzkaller] INFO: task hung in fuse_lookup with v6.0 kernel in guest

[Pengfei Xu]

Hi Miklos,

On 2022-10-18 at 11:23:17 +0200, Miklos Szeredi wrote:
> 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.
  Thanks for the solution: "echo 1 >  /sys/fs/fuse/connections/$FUSE_DEV/abort"

> 
> Is there a real life situation where this occurs, or is this just
> triggered with fuzzing?
  It only could be reproduced by repro.c from syzkaller, and we have not
  encountered this problem in real life yet.
  So it's a low priority issue and it's not even clear if it's worth solving?

> 
> I'm wondering why syzbot didn't try aborting using the "abort" file in
> sysfs, AFAICS it does know this trick.
  Yes, maybe syzbot should improve it? :)

  Thanks!
  BR.

> 
> Thanks,
> Miklos
>