https://bugzilla.kernel.org/show_bug.cgi?id=216566 --- Comment #2 from Zorro Lang (zlang@xxxxxxxxxx) --- (In reply to Dave Chinner from comment #1) > On Sun, Oct 09, 2022 at 05:47:49PM +0000, bugzilla-daemon@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxx > > Reporter: zlang@xxxxxxxxxx > > 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.
