We're seeing a number of ext4 BUG_ON's when using unionfs. They can
be triggered using fsx, so we've seen it with xfstests generic/074,
generic/112, generic/127, and generic/198, for example. None of these
tests are failing if we use ext4 w/o unionfs.
The BUG_ON is being triggered by the page_buffers() macro in
mpage_prepare_extent_to_map in fs/ext4/inode.c. The stack trace shows
that fsx is calling fsync on a unionfs, and unionfs_fsync() is calling
vfs_sync_range() on the lower file, which ends up calling ext4's fsync
handler, which then calls filemap_write_and_wait_range(), which then
calls ext4_writepages(), which eventually ends up
mpage_prepare_extent_to_map(). The page_buffers() macro has the
following BUG_ON, which is getting fired:
BUG_ON(!PagePrivate(page);
What his means is that buffer heads have not been attached to the
buffer. For some file systems, such as ext3, this happens when
create_empty_buffer() gets called from its writepage() function.
But ext4, as with more advanced file systems, such as xfs and btrfs,
has a page_mkwrite function which is defined in the
vm_operations_struct(). It looks like unionfs's vm_operation_struct
does not dispatch page_mkwrite() or remap_pages().
In the case of ext4, there are a number of ext4-specific things which
we handle in the page_mkwrite() function, which gets called whenever a
page needs to be made writeable (i.e., when a page is first dirtied).
Some of the things handled by ext4_page_mkwrite() include attaching
the buffer_head(s) to the page (this happens via the call to
__block_page_mkwrite() which then calls __block_write_begin().)
A really simple way of repro'ing this which doesn't require using the
full xfstests machinery modified to support unionfs:
mount -t ext4 /dev/vdb /vdb
mkdir -p /vdb/rw
mount -t unionfs -o dirs=/vdb/rw=rw:/usr/bin=ro unionfs /mnt
cd /mnt
/root/xfstests/ltp/fsx -d -N 100 -S 6152 fsx
(BTW, if you need xfstests pre-built, you can grab a VM image from
https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests, and
get the driver scripts from my xfstests-bld repository at
git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git. Put the VM
image in kvm-xfstests/test-appliance/root_fs.img, edit
kvm-xfstests/config to point at a monolithic kernel, then cd to
kvm-xfstests, and run the command "./kvm-xfstests shell". The above
commands should then work out of the box. For more information,
please see:
https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/README
and https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/README)
The stack trace you will see is:
[ 102.294376] kernel BUG at /usr/projects/linux/ext4/fs/ext4/inode.c:2366!
[ 102.295167] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 102.295828] Modules linked in:
[ 102.296189] CPU: 1 PID: 2601 Comm: fsx Not tainted
3.14.2-00610-g6cde9ca-dirty #1849
[ 102.296679] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 102.296679] task: f45f27d0 ti: f4514000 task.ti: f4514000
[ 102.296679] EIP: 0060:[<c02a5e77>] EFLAGS: 00010246 CPU: 1
[ 102.296679] EIP is at mpage_prepare_extent_to_map+0x15b/0x1bb
[ 102.296679] EAX: 00000000 EBX: f4515e24 ECX: 00000000 EDX: 80000000
[ 102.296679] ESI: f7839fb8 EDI: 00000000 EBP: f4515dd4 ESP: f4515d64
[ 102.296679] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 102.296679] CR0: 8005003b CR2: b7588000 CR3: 351b1000 CR4: 000006f0
[ 102.296679] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 102.296679] DR6: fffe0ff0 DR7: 00000400
[ 102.296679] Stack:
[ 102.296679] 0000000e 0000000c 00000000 0000002e f4ab535c 7fffffff ffffffff
00000002
[ 102.296679] 0000003c 0000000e 00000000 f7839fb8 f7839f94 f7839f70 f7839f4c
f7839f28
[ 102.296679] f7839f04 f7839ee0 f7839ebc f782821c f7828240 f7828264 f7828288
f78282ac
[ 102.296679] Call Trace:
[ 102.296679] [<c02a9886>] ext4_writepages+0x30a/0x513
[ 102.296679] [<c08316f9>] ? _raw_spin_unlock+0x22/0x2c
[ 102.296679] [<c0209b72>] do_writepages+0x1c/0x29
[ 102.296679] [<c020259e>] __filemap_fdatawrite_range+0x5c/0x67
[ 102.296679] [<c0202607>] filemap_write_and_wait_range+0x2b/0x61
[ 102.296679] [<c02a2bcc>] ext4_sync_file+0x185/0x31e
[ 102.296679] [<c02a2a47>] ? rcu_read_lock_sched_held+0x67/0x67
[ 102.296679] [<c025b001>] vfs_fsync_range+0x1e/0x2d
[ 102.296679] [<c0300495>] unionfs_fsync+0x147/0x1d8
[ 102.296679] [<c030034e>] ? unionfs_splice_read+0xc9/0xc9
[ 102.296679] [<c025b001>] vfs_fsync_range+0x1e/0x2d
[ 102.296679] [<c025b029>] vfs_fsync+0x19/0x1b
[ 102.296679] [<c0223273>] SyS_msync+0xe9/0x152
[ 102.296679] [<c0831ff7>] syscall_call+0x7/0xb
[ 102.296679] Code: 0b 83 7b 20 00 75 06 8b 46 08 89 43 08 8b 46 08 8a 4d 98
40 89 43 0c 8b 46 08 89 45 9c 89 f0 d3 65 9c e8 fc ec ff ff 85 c0 75 02 <0f> 0b
8b 56 1c 89 d8 ff 75 9c 89 d1 e8 91 fd ff ff 89 c6 85 f6
[ 102.296679] EIP: [<c02a5e77>] mpage_prepare_extent_to_map+0x15b/0x1bb SS:ESP
0068:f4515d64
[ 102.317942] ---[ end trace 690164cfcc8c32d9 ]---
- Ted
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
