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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240715042803.GM10452@mit.edu>
Date: Mon, 15 Jul 2024 00:28:03 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Zorro Lang <zlang@...hat.com>
Cc: linux-ext4@...r.kernel.org, fstests@...r.kernel.org,
        "Darrick J. Wong" <djwong@...nel.org>,
        Daniel Gomez <da.gomez@...sung.com>
Subject: Re: [Bug report]: fstests g/388 crash on ext4, BUG: kernel NULL
 pointer dereference, address: 0000000000000000

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ