I've decided to use UML when caught some hard to
debug OOpses on btrfs.

The first attempt to use btrfs on UML gave me stable
UML crash. I suspect it's a UML's problem.

So I have some questions here (I'm on x86_64,

1. (major one) BUG_ON trace in UML does not look
   as in real kernel. ud2 handler does not show us nice
   backtrace, but calls some suspicious handler.

/mnt/btr # touch asd-`seq 1 10000`
[   95.540000] Kernel panic - not syncing: Kernel mode signal 4
[   95.540000] Call Trace: 
[   95.540000] 602d9908:  [<60227a48>] panic+0xea/0x1e0
[   95.540000] 602d99b8:  [<600342ed>] do_softirq+0x4d/0x70
[   95.540000] 602d9a08:  [<60016947>] relay_signal+0x87/0xa0
[   95.540000] 602d9a18:  [<60021f70>] set_signals+0x30/0x40
[   95.540000] 602d9a38:  [<60021df9>] sig_handler_common+0x59/0xd0
[   95.540000] 602d9a58:  [<60021f2c>] real_alarm_handler+0x3c/0x50
[   95.540000] 602d9ae0:  [<6018c0a0>] strncpy+0x20/0x30
[   95.540000] 602d9b78:  [<6002200f>] sig_handler+0x3f/0x50
[   95.540000] 602d9b98:  [<600222a1>] handle_signal+0x71/0xb0
[   95.540000] 602d9be8:  [<60023630>] hard_handler+0x10/0x20
[   95.540000] 602d9ca8:  [<6011263c>] lookup_inline_extent_backref+0x2dc/0x3f0
[   95.540000] 
[   95.540000] 
[   95.540000] Pid: 1, comm: sh Not tainted 2.6.39-rc2+

   Here we have BUG_ON in lookup_inline_extent_backref+0x2dc/0x3f0, but that 
   hard_handler. Is it an UML bug or known and expected behaviour?

   Now I use 'gdb -p $pid' to get nicer backtrace:

Program received signal SIGILL, Illegal instruction.
lookup_inline_extent_backref (trans=0x70c6e000, root=<value optimized out>, 
    ref_ret=<value optimized out>, bytenr=<value optimized out>, 
num_bytes=<value optimized out>, parent=0, 
    root_objectid=5, owner=0, offset=0, insert=0) at 
1399            BUG_ON(ret);

   Can UML call the same ud2 handler as the real handler? We would see 
something like:

[  155.038388] kernel BUG at /mnt/archive/src/linux-2.6/fs/btrfs/inode.c:2967!
[  155.038643] invalid opcode: 0000 [#1] PREEMPT SMP 

   How does UML implement running userspace processes and kernel threads in it?
   I guess it's a problem, why UML can't distinct where ud2 comes from and call
   proper handler.

2. btrfs in UML does not work for me at all. It corrupts data right off
   the start. I only need to format the filesystem, touch there ~20
   files and I get corrupted FS:

   I run the following tiny script in UML:

/tools/mkfs.btrfs /dev/ubda
mount /mnt/btr/
cd /mnt/btr/
touch `seq 1 11`

   The result is:
/ # ./kill_btr 

WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/ubda
        nodesize 4096 leafsize 4096 sectorsize 4096 size 1.91GB
Btrfs v0.19-35-g1b444cd-dirty
[    2.770000] device fsid f2407093ae1f3a78-9e203194e541bfbd devid 1 transid 7 
[    2.770000] btrfS: invalid dir item name len: 12594
[    2.770000] btrfS: invalid dir item name len: 0
[    2.770000] btrfS: invalid dir item name len: 0

Corruption. Only last file is seen. Later, after unmount I get an OOps.

It does not happen in real OS. I've enabled all the corruption
detecting tehniques in the kernel config and it didn't change picture.
I can share .config if you like. kernel builds only 4 minutes on my slow

Is there serious problems in UML block device handling?

I run UML this way:
./vmlinux                                        \
    ubd0=$(pwd)/btr.img                          \
    root=/dev/root                               \
    rootflags="$(pwd)/root" rw rootfstype=hostfs \
    mem=256M init=/init                          \

btr.img is a 2048000000 bytes sized file. rootfs contains statically linked
busybox and latest statically linked btrfs-progs. I can share my root if
you are interested. It's tiny (btrfs-progs tree is mounted from hostfs):
$ find root/ -type f

Thank you!



Attachment: signature.asc
Description: PGP signature

Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
User-mode-linux-devel mailing list

Reply via email to