[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230503050444.GB674745@mit.edu>
Date: Wed, 3 May 2023 01:04:44 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Aleksandr Nogikh <nogikh@...gle.com>
Cc: syzbot <syzbot+e6dab35a08df7f7aa260@...kaller.appspotmail.com>,
brauner@...nel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
viro@...iv.linux.org.uk
Subject: Re: [syzbot] [fs?] INFO: task hung in eventpoll_release_file
On Tue, May 02, 2023 at 10:08:44PM +0200, Aleksandr Nogikh wrote:
> Hi Ted,
>
> On Sun, Apr 30, 2023 at 8:34 AM Theodore Ts'o <tytso@....edu> wrote:
> >
> > #syz set subsystem: fs
> >
> > This somehow got tagged with the ext4 label, and not the fs label.
> > (And this is not the first one I've noticed). I'm beginning to
> > suspect there may have been some syzbot database hiccup? Anyway,
> > fixing...
>
> FWIW one of this bug's crashes was attributed to ext4 [1] and syzbot's
> logic in this case was to prefer a more specific subsystem (ext4) to a
> more generic one (fs), even if it's not mentioned in the majority of
> crashes.
>
> [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=171abfaac80000
One of the challenges is that the attribution is not necessasrily
accurate. One of the CPU's was running an ext4 workqueue task (which
was apparntly making forward progress) at the time of the crash.
It should also be noted that apparently there is a potential patch
which seems to fix the problem, and it's solely in the fs/eventpoll.c.
Unfortunately, it was not in the lore.kernel.org archives, since
apparently it wasn't cc'ed there. It's in the syzkaller-bugs Google
Groups archive, though, since Pauolo Abeni cc'ed the
syzkaller-bugs@...glegroups.com, but not the lore archive, on his
test:
https://groups.google.com/g/syzkaller-bugs/c/oiBUmGsqz_Q/m/Xi5iOeJNAgAJ
- Ted
Powered by blists - more mailing lists