From: "Theodore Ts'o" <tytso@mit.edu>
To: Zorro Lang <zlang@redhat.com>
Cc: linux-ext4@vger.kernel.org, fstests@vger.kernel.org,
"Darrick J. Wong" <djwong@kernel.org>,
Daniel Gomez <da.gomez@samsung.com>
Subject: Re: [Bug report]: fstests g/388 crash on ext4, BUG: kernel NULL pointer dereference, address: 0000000000000000
Date: Mon, 15 Jul 2024 00:28:03 -0400 [thread overview]
Message-ID: <20240715042803.GM10452@mit.edu> (raw)
In-Reply-To: <20240714034624.qz3l7f52pi6m27yx@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On Sun, Jul 14, 2024 at 11:46:24AM +0800, Zorro Lang wrote:
>
> A weird kernel panic on ext4 happened when I tried to test a
> fstests patchset:
> https://lore.kernel.org/fstests/20240712093341.ftesijixy2yrjlxx@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/T/#med4b8d2fe14ef627519d84474b4cd1a25d386f75
I'm confused; this patch set:
Daniel Gomez (5):
common/config: fix RECREATE_TEST_DEV initialization
common/rc: add recreation support for tmpfs
common/config: enable section parsing when recreation
common/rc: read config section mount options for scratch devs
common/rc: print test mount options
seems to be mostly about how xfstest config section handling
especially for tmpfs. Is this realy the right patch set? If so, I'm
guessing that the reproducer would be very specific to the xfstests
config.
My {kvm,gce}-xfstest setup doesn't use the config sections at
all, but instead uses shell script fragments, since it predates config
sections by three years --- and I need something that works well with
sharding separate configs to run on separate cloud VM's.
So I'm not sure I'm going to be able to reprduce this easily using my
test setup. Can you translate the stack trace to source file names /
line numbers? Maybe that will give me a hint what's going on:
> [35346.372867] Call Trace:
> [35346.375319] <TASK>
> [35346.377426] ? __die+0x20/0x70
> [35346.380493] ? page_fault_oops+0x116/0x230
> [35346.384602] ? __pfx_page_fault_oops+0x10/0x10
> [35346.389048] ? _raw_spin_unlock+0x29/0x50
> [35346.393072] ? rcu_is_watching+0x11/0xb0
> [35346.397006] ? exc_page_fault+0x59/0xe0
> [35346.400854] ? asm_exc_page_fault+0x22/0x30
> [35346.405049] ? folio_mark_dirty+0x2a/0xf0
> [35346.409072] __ext4_block_zero_page_range+0x50c/0x7b0 [ext4]
> [35346.414809] ext4_truncate+0xcd3/0x1210 [ext4]
Getting line numbers for these two functions would be especially
helpful.
Thanks,
- Ted
next prev parent reply other threads:[~2024-07-15 4:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240714034640eucas1p20269c99db76a1958bb4207df92552896@eucas1p2.samsung.com>
2024-07-14 3:46 ` [Bug report]: fstests g/388 crash on ext4, BUG: kernel NULL pointer dereference, address: 0000000000000000 Zorro Lang
2024-07-15 4:28 ` Theodore Ts'o [this message]
2024-07-15 8:01 ` Daniel Gomez
2024-07-15 14:24 ` Theodore Ts'o
2024-07-16 6:20 ` Zorro Lang
2024-07-16 12:23 ` Daniel Gomez
2024-07-16 15:43 ` Zorro Lang
2024-07-15 8:05 ` Daniel Gomez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240715042803.GM10452@mit.edu \
--to=tytso@mit.edu \
--cc=da.gomez@samsung.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=zlang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox