linux-ext4 - kernel panic using external journal and snapshots

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-next>] [day] [month] [year] [list]

Message-ID: <5281A8A3.80604@gmail.com>
Date:	Mon, 11 Nov 2013 20:03:47 -0800
From:	Gordon Messmer <gordon.messmer@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: kernel panic using external journal and snapshots

I'm developing backup infrastructure for Linux using snapshots.  One of 
the supported configurations is EXT4 on LVM, but I think I've come 
across a bug.

I'm currently testing on CentOS 6, with kernel 2.6.32-358.6.1.el6.x86_64

If I create a snapshot of a filesystem with an external journal, and 
mount that snapshot while the original filesystem is mounted, the system 
will usually kernel panic.  If it does not panic, then the kernel will 
later refuse to mount it because "External journal has more than one 
user."  So, the first bug seems to be that ext4 doesn't check the 
external journal before mounting the new snapshot to ensure that the 
journal is not in use.  Expected behavior is that the kernel would 
refuse to mount a filesystem whose journal already has a "user" in order 
to prevent a kernel panic.

If that were the extent of the problem, I probably wouldn't bother 
reporting the issue.  However, the kernel will STILL panic if I use 
tune2fs to remove the journal, and even if I use tune2fs to create a new 
internal journal.  The second bug, then, seems to be that once an ext4 
filesystem has an external journal, that journal will continue to be 
used after it has been removed, and even if it is replaced with an 
internal journal.

The following commands were used to test the problem.  These are 
basically the commands run by the "snapshot" application.  It sets a 
minimum snapshot size of 10% of the volume size, then reads the size of 
the volume and the size remaining in the volume group.  It creates a 
uuid for the snapshot name, then creates the new snapshot.  I use 
tune2fs first to verify that there is a journal device recorded, then 
remove the journal.  Afterward, I read the value again and find no 
external journal recorded.  When the filesystem is mounted, the kernel 
will usually panic.

Is this a known bug?  I haven't yet built a newer system to test the 
effects on the current kernel version.

min_size=10
lvsize=$(lvs --noheadings --units m --nosuffix -o lv_size 
"VolGroup/lv_var" | cut -f1 -d.)
vgfree=$(vgs --noheadings --units m --nosuffix -o vg_free 
"/dev/VolGroup" | cut -f1 -d.)
test "$vgfree" -gt $(( $lvsize * $min_size / 100 )) || echo Not enough 
free space on "/dev/VolGroup" for snapshot
uuid=$(uuidgen)
lvcreate -s -n "lv_var-snap-${uuid}" -L "$(( $lvsize * $min_size / 100 
))"m "VolGroup/lv_var"
	  Rounding up size to full physical extent 128.00 MiB
	  Logical volume
	"lv_var-snap-66c41691-21c0-4db2-8af2-09a13d87a881" created
tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:"
	Journal device:              0xfd04
tune2fs -O ^has_journal "/dev/VolGroup/lv_var-snap-${uuid}"
	tune2fs 1.41.12 (17-May-2010)
	Journal removed
tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:"
mount "/dev/VolGroup/lv_var-snap-${uuid}" /mnt
	* kernel panic *

https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot
--
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