On Thu, Feb 13, 2025 at 11:21:22AM +0530, Venkat Rao Bagalkote wrote:
> Greetings!!!
>
> I am observing kernel OOPs, while running FStests generic/451 on EXT4 with
> linux-next kernel(next-20250212) on IBM Power Servers.
I'm running daily spinnner tests on the fs-next branch on the
linux-next tree, via:
gce-xfstests ltm -c ext4/all,xfs/all,btrfs/all,f2fs/all -g auto --repo \
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next \
--watch fs-next
The fs-next branch is a subset of linux-next which only has file
system related branches. This avoids instability caused by non-fs
related changes. I'm not seeing any kernel oops on today's fs-next
running on an x86 cloud server, using a standardized config.
Looking at the kernel stack trace of your report, it appears that a
linked list used by the workqueue handler (in process_one_work) had
gotten corrupted. This could be caused by anything (which is one of
the reasons why I test using fs-next instead of linux-next; we didn't
want to spend time debugging problems that aren't under our control).
Is this something which you can easily reproduce? If so, can you try
seeing if it reproduces on the fs-next branch, and could you try
bisecting the to find the guilty commit? If this was something we
could reproduce in my test infrastructure, the bisection could be
trivially accomplished via:
gce-xfstests ltm -c ext4/4k generic/451 --repo linux-next.git \
--bisect-bad linux-next --bisect-good v6.14-rc1
... and then wait for an e-mailed report to land in my inbox. :-)
Can you do something similar using your test infrastructure?
Unfortuantely, given the stack trace, I doubt kernel developers would
be able to do much more with your report.
Thanks,
- Ted
