linux-kernel - Re: [next-20250212] FStests generic/451 on EXT4 FS resulting in kernel OOPs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250213185222.GA398915@mit.edu>
Date: Thu, 13 Feb 2025 13:52:22 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Venkat Rao Bagalkote <venkat88@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-ext4@...r.kernel.org, fstests@...r.kernel.org
Subject: Re: [next-20250212] FStests generic/451 on EXT4 FS resulting in
 kernel OOPs

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