From: Sergei Trofimovich <slyich@gmail.com>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] btrfs failure and BUG_ON behaviour
Date: Sat, 9 Apr 2011 17:04:54 +0300 [thread overview]
Message-ID: <20110409170454.73aada78@sf> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 4195 bytes --]
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,
2.6.39-rc2):
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 pesky
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>, path=0x70c82000,
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 /home/slyfox/linux-2.6/fs/btrfs/extent-tree.c:1399
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`
ls
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 /dev/ubda
[ 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
11
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
laptop.
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
root/bin/busybox
root/bin/strace
root/kill_btr
root/etc/fstab
root/init
Thank you!
--
Sergei
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 250 bytes --]
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
[-- Attachment #3: Type: text/plain, Size: 194 bytes --]
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next reply other threads:[~2011-04-09 14:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-09 14:04 Sergei Trofimovich [this message]
2011-04-09 21:33 ` [uml-devel] btrfs failure and BUG_ON behaviour richard -rw- weinberger
2011-04-10 6:56 ` Sergei Trofimovich
2011-04-10 19:58 ` Sergei Trofimovich
2011-04-11 23:13 ` richard -rw- weinberger
2011-04-12 10:13 ` Sergei Trofimovich
2011-04-12 11:22 ` richard -rw- weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110409170454.73aada78@sf \
--to=slyich@gmail.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.