Received-SPF: pass (google.com: domain of linux-kernel+bounces-134113-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sun, 7 Apr 2024 01:48:16 +0100
From: Al Viro <viro@zeniv.linux.org.uk>
To: Hillf Danton <hdanton@sina.com>
Cc: syzbot <syzbot+9a5b0ced8b1bfb238b56@syzkaller.appspotmail.com>,
	amir73il@gmail.com, linux-kernel@vger.kernel.org, miklos@szeredi.hu,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop_llseek
Message-ID: <20240407004816.GE538574@ZenIV>
References: <CAOQ4uxgJ5URyDG26Ny5Cmg7DceOeG-exNt9N346pq9U0TmcYtg@mail.gmail.com>
 <000000000000107743061568319c@google.com>
 <20240406082351.1213-1-hdanton@sina.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240406082351.1213-1-hdanton@sina.com>
Sender: Al Viro <viro@ftp.linux.org.uk>

On Sat, Apr 06, 2024 at 04:23:51PM +0800, Hillf Danton wrote:
> On Sat, 6 Apr 2024 08:11:30 +0100 Al Viro <viro@ftp.linux.org.uk>
> > On Sat, Apr 06, 2024 at 12:05:04AM -0700, syzbot wrote:
> > > commit:         3398bf34 kernfs: annotate different lockdep class for ..
> > > git tree:       https://github.com/amir73il/linux/ vfs-fixes
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=c5cda112a8438056
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=9a5b0ced8b1bfb238b56
> > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
c > > 
> > > Note: no patches were applied.
> > 
> > How about the same test on 6c6e47d69d821047097909288b6d7f1aafb3b9b1?
> > 
> JFYI it works [1]
> 
> [1] https://lore.kernel.org/lkml/000000000000a386f2061562ba6a@google.com/

It works on top of v6.8-8951-gfe46a7dd189e; boot failures on top
of v6.9-rc2-387-g6c6e47d69d82 and on top of v6.9-rc1.  See
https://lore.kernel.org/lkml/00000000000039026a06155b3a12@google.com/
and
https://lore.kernel.org/lkml/000000000000107743061568319c@google.com/
resp.  Both hit refcount_t underflow in virtio_scsi probing, with
very similar call chains (if not outright identical ones - hadn't
checked in details).

I don't believe that this patch introduces a boot failure, let alone
this one - all of that is likely to be shared with the corresponding
points on mainline.

Might be interesting to try and figure out what that is, but that's
a separate bug.