[Bug 216566] [xfstests generic/648] BUG: unable to handle page fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700 [xfs]

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216566

--- Comment #2 from Zorro Lang (zlang@redhat.com) ---
(In reply to Dave Chinner from comment #1)
> On Sun, Oct 09, 2022 at 05:47:49PM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216566
> > 
> >             Bug ID: 216566
> >            Summary: [xfstests generic/648] BUG: unable to handle page
> >                     fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700
> >                     [xfs]
> >            Product: File System
> >            Version: 2.5
> >     Kernel Version: v6.1-rc0
> >           Hardware: All
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: XFS
> >           Assignee: filesystem_xfs@kernel-bugs.kernel.org
> >           Reporter: zlang@redhat.com
> >         Regression: No
> > 
> > xfstests generic/648 hit kernel panic[1] on xfs with 64k directory block
> size
> > (-n size=65536), before panic, there's a kernel assertion (not sure if it's
> > related).
> > 
> > It's reproducable, but not easy. Generally I reproduced it by loop running
> > generic/648 on xfs (-n size=65536) hundreds of time.
> > 
> > The last time I hit this panic on linux with HEAD=
> 
> Given that there have been no changes to XFS committed in v6.1-rc0
> at this point in time, this won't be an XFS regression unless you
> can reproduce it on 6.0 or 5.19 kernels, too. Regardless, I'd suggest
> bisection is in order to find where the problem was introduced.

It's not a regression recently, I even can reproduce it on RHEL-9 (which base
on 5.14 kernel).

> 
> -Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.