Date:   Mon, 3 Oct 2016 23:18:55 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Johannes Bauer <dfnsonfsduifb@....de>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Frequent ext4 oopses with 4.4.0 on Intel NUC6i3SYB

On Mon, Oct 03, 2016 at 12:52:20PM +0200, Johannes Bauer wrote:
> Shows also a stacktrace with the same call path, also running on a
> (different) Intel NUC, also running a 4.4.0 kernel. This pastebin is
> nowhere referenced however, so I'm unsure who found it and where exactly
> it was posted. Since the offending process in the unknown guy or girl's
> pastebin was dd, however, I believe that he or she tried to deliberately
> reproduce the problem.

Have you tried using a 4.4.23 kernel?  There are a large number of bug
fixes in the kernel betweeb 4.4.0 and 4.4.23.

The last time I've done a stable kernel test run was against 4.4.17,
and it passed clean:

FSTESTIMG: gce-xfstests/xfstests-201608132226
FSTESTVER: e2fsprogs	v1.43.1-22-g25c4a20 (Wed, 8 Jun 2016 18:11:27 -0400)
FSTESTVER: fio		fio-2.6-8-ge6989e1 (Thu, 4 Feb 2016 12:09:48 -0700)
FSTESTVER: quota		81aca5c (Tue, 12 Jul 2016 16:15:45 +0200)
FSTESTVER: xfsprogs	v4.5.0 (Tue, 15 Mar 2016 15:25:56 +1100)
FSTESTVER: xfstests-bld	75f1eb0 (Sat, 13 Aug 2016 22:18:57 -0400)
FSTESTVER: xfstests	linux-v3.8-1149-g4e58a5b (Mon, 8 Aug 2016 10:50:34 -0400)
FSTESTVER: kernel	4.4.17 #4 SMP Mon Aug 15 23:55:25 EDT 2016 x86_64
FSTESTCFG: "all"
FSTESTSET: "-g auto"
FSTESTEXC: "ext4/022"
FSTESTOPT: "aex"
MNTOPTS: ""
CPUS: "2"
MEM: "7477.49"
MEM: 7680 MB (Max capacity)
BEGIN TEST 4k: Ext4 4k block Tue Aug 16 00:05:28 EDT 2016
Passed all 224 tests

						- Ted

P.S.   Fixes between 4.4.0 and 4.4.17:

% git log --oneline v4.4..v4.4.17 -- fs/ext4 fs/jbd2
26015f0 ext4: verify extent header depth
8b8de1c ext4: silence UBSAN in ext4_mb_init()
12aa7d9 ext4: address UBSAN warning in mb_find_order_for_block()
b2601bb ext4: fix oops on corrupted filesystem
b2044c3 ext4: clean up error handling when orphan list is corrupted
c5ce389 ext4: fix hang when processing corrupted orphaned inode list
fa5613b ext4: iterate over buffer heads correctly in move_extent_per_page()
2122834 ext4: fix races of writeback with punch hole and zero range
1f7b7e9 ext4: fix races between buffered IO and collapse / insert range
e096ade ext4: move unlocked dio protection from ext4_alloc_file_blocks()
0b680de ext4: fix races between page faults and hole punching
c745297 ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()
ee8516a ext4: ignore quota mount options if the quota feature is enabled
321299a ext4: add lockdep annotations for i_data_sem
93272be jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path
7c3d142 ext4: fix bh->b_state corruption
bbfe21c ext4: don't read blocks from disk after extents being swapped
600d41f ext4: fix potential integer overflow
33f48f8 ext4: fix scheduling in atomic on group checksum failure
b80b70e ext4 crypto: add missing locking for keyring_key access

Fixes between 4.4.17 and 4.4.23:

% git log --oneline v4.4.17..v4.4.23 -- fs/ext4 fs/jbd2
bf63b9d fscrypto: require write access to mount to set encryption policy
8d693a2 fscrypto: add authorization check for setting encryption policy
d8aafd0 ext4: use __GFP_NOFAIL in ext4_free_blocks()
1d12bad ext4: avoid modifying checksum fields directly during checksum verification
77ae14d ext4: avoid deadlock when expanding inode size
a79f1f7 ext4: properly align shifted xattrs when expanding inodes
e6abdbf ext4: fix xattr shifting when expanding inodes part 2
f2c06c7 ext4: fix xattr shifting when expanding inodes
dfa0a22 ext4: validate that metadata blocks do not overlap superblock
564e0f8 jbd2: make journal y2038 safe
3a22cf0 ext4: fix reference counting bug on block allocation error
db82c74 ext4: short-cut orphan cleanup on error
f8d4d52 ext4: validate s_reserved_gdt_blocks on mount
175f36c ext4: don't call ext4_should_journal_data() on the journal inode
5a7f477 ext4: fix deadlock during page writeback
9e38db2 ext4: check for extents that wrap around

And note that not all fixes get backported.  Sometimes a patch is too
large or too complex to backport.  Or sometimes we forget to tag a
patch for a stable kernel backport that really should have been
backported.  So trying to see if you can replicate the problem using
the latest 4.8 kernel would also be a good thing to try.

Finally, the oops was inside the memory allocator, so it's possible
the problem was caused by a corrupted freelist, which could have been
caused by a wild pointer dereference in any part of the kernel, not
necessarily ext4.  Which is another reason to go to the latest 4.4.x
kernel or to try the 4.8 kernel.  The bug in some other part of the
subsystem may have since been fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists