btrfs failure and BUG_ON behaviour

uml-devel Sergei Trofimovich 2 participants 7 messages Apr 9, 2011 – Apr 12, 2011 User-mode Linux (UML)

lore

Share & tools

lore

Sergei Trofimovich

author

2011-04-09 14:02 UTC #0 lore raw

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

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!

Signature · 1 line

  Sergei

------------------------------------------------------------------------------
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

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

richard -rw- weinberger

2011-04-09 21:33 UTC #1 lore raw

Quoted 31 lines · Sergei Trofimovich

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+

Quoted 2 lines

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?

It's expected behavior.

Quoted 9 lines

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:

It's on my maybe-TODO list. :-)

Quoted 7 lines

[ 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.

UML can distinct the source of ud2. Otherwise any process within UML could kill the kernel.

Quoted 27 lines

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

Quoted 8 lines

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 hope not!
We have had some problems with the block layer in ~2.6.32 to 2.6.35. Commit 4752690 fixed the issues.

Can you please re-test it with 2.6.38?
Does you script work with other file systems?

Quoted 35 lines

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
------------------------------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Signature · 13 lines

Thanks,
//richard

------------------------------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Sergei Trofimovich

author

2011-04-10 06:54 UTC #2 lore raw

Quoted 4 lines · On Sat, 9 Apr 2011 23:33:14 +0200 richard -rw- weinberger…

We have had some problems with the block layer in ~2.6.32 to 2.6.35. Commit 4752690 fixed the issues.
Can you please re-test it with 2.6.38?

Same crash with 2.6.38, so it's either very sneaky btrfs bug or some discrepancy in ubd.

Quoted 1 line

Does you script work with other file systems?

Tested on ext4, xfs, jfs and reiserfs3. All survive the load of creating and deleting 1000 files.

By on-disk load reiserfs3 should be quite similar to btrfs, so I expected it to show problems, but it didn't.

[n00bish speculation] btrfs also plays games with mm. Maybe the problem sits somewhere there where block layer/page cache and on-disk layout gets out-of-sync.

[sf] ~/linux-2.6/fs/btrfs:fgrep -R PageDirty .
./extent_io.c: if (!PageDirty(pages[i]) ||
./extent_io.c: if (!PageDirty(page))
./extent_io.c: if (!PageDirty(page)) {
./disk-io.c: if (PageDirty(page))
./disk-io.c: if (PageWriteback(page) || PageDirty(page))
./disk-io.c: if (PageDirty(page)) {
./transaction.c: if (PageDirty(page))
./transaction.c: if (PageDirty(page)) {
./ioctl.c: if (PageDirty(page)) {
./inode.c: if (!page->mapping || !PageDirty(page) || !PageChecked(page)) {
./inode.c: if (PageWriteback(page) || PageDirty(page))

I'll try to send bug report to linux-btrfs mailing list first and return if I'll have more details.

Signature · 1 line

  Sergei

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Sergei Trofimovich

author

2011-04-10 19:56 UTC #3 lore raw

Quoted 2 lines

I'll try to send bug report to linux-btrfs mailing list first and return if I'll have more details.

I've bisected it down to memcpy changes 59daa706fbec745684702741b9f5373142dd9fdc and found out btrfs piece of code passing overlapping areas to memcpy.

Sorry for the noise.

Signature · 1 line

  Sergei

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

richard -rw- weinberger

2011-04-11 23:13 UTC #4 lore raw

In reply to Sergei Trofimovich

Quoted 31 lines · Sergei Trofimovich

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+

Quoted 2 lines

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?

Can you please test the attached patch?
The trace was broken long before I started working on UML.

Quoted 88 lines

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
------------------------------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Signature · 2 lines

Thanks,
//richard

From d3808c146d987e0add9e793f56f1d58883eb5c7a Mon Sep 17 00:00:00 2001
From: Richard Weinberger <[email protected]>
Date: Tue, 12 Apr 2011 00:53:32 +0200
Subject: [PATCH] um: Fix call tracer and bug handler

Commit 1de1502c (x86, um: now we can get rid of trivial uml headers) removed accidentally bug.h which broke UML's call tracer and bug handler.
Since v2.6.28-rc1 the call trace was incomplete and nobody noticed. >:)

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/um/include/asm/bug.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 arch/um/include/asm/bug.h

arch/um/include/asm/bug.h new file +6 -0

new file mode 100644
index 0000000..9e33b86
@@ -0,0 +1,6 @@
+#ifndef __UM_BUG_H
+#define __UM_BUG_H
+
+#include <asm-generic/bug.h>
+
+#endif

Signature · 1 line

1.6.6.1

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Sergei Trofimovich

author

2011-04-12 10:11 UTC #5 lore raw

Quoted 5 lines · On Tue, 12 Apr 2011 01:13:30 +0200 richard -rw- weinberger…

Quoted 2 lines
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?
Can you please test the attached patch?
The trace was broken long before I started working on UML.

Attached the BUG backtrace for a crash without and with patch. Patched one looks great!

The minor nit is Kbuild does not detect headers change, so I had to 'make clean' build dir first.

Thanks!

Signature · 1 line

  Sergei

/ # rm -rf /mnt/btr/var_tmp/paludis/dev-lang-jhc-9999/

[   50.680000] Kernel panic - not syncing: Kernel mode signal 4
[   50.680000] Call Trace: 
[   50.680000] 6023d918:  [<601a2342>] panic+0xea/0x1dc
[   50.680000] 6023d938:  [<6001c4a1>] ubd_intr+0x6d/0xc9
[   50.680000] 6023d978:  [<6004d5a9>] handle_irq_event_percpu+0x10a/0x126
[   50.680000] 6023d9c8:  [<6004d5e8>] handle_irq_event+0x23/0x2f
[   50.680000] 6023d9e8:  [<60018092>] free_irqs+0x72/0xdc
[   50.680000] 6023da18:  [<60016aa3>] relay_signal+0x38/0x79
[   50.680000] 6023da28:  [<600140d1>] sigio_handler+0x5a/0x5f
[   50.680000] 6023da48:  [<6001fc2d>] sig_handler_common+0x87/0x9b
[   50.680000] 6023da68:  [<6001fc7d>] real_alarm_handler+0x3c/0x3e
[   50.680000] 6023daf0:  [<6006cdab>] kernel_map_pages+0x73/0x18c
[   50.680000] 6023db78:  [<6001fd22>] sig_handler+0x30/0x3e
[   50.680000] 6023db98:  [<6001f93e>] handle_signal+0x72/0xa8
[   50.680000] 6023dbe8:  [<60020b3c>] hard_handler+0x10/0x14
[   50.680000] 6023dca8:  [<600d4985>] btrfs_unlink+0x75/0xbc
[   50.680000] 
[   50.680000] 
[   50.680000] Pid: 1, comm: busybox Not tainted 2.6.39-rc3
[   50.680000] RIP: 0033:[<00000000005443a7>]
[   50.680000] RSP: 0000007fbfe894f8  EFLAGS: 00000246
[   50.680000] RAX: ffffffffffffffda RBX: 00000000008536a0 RCX: ffffffffffffffff
[   50.680000] RDX: 0000007fbfe89500 RSI: 0000007fbfe89500 RDI: 00000000008536a0
[   50.680000] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[   50.680000] R10: 7263616d2d63612f R11: 0000000000000246 R12: 0000000000000000
[   50.680000] R13: 0000000040001010 R14: 00000000008536a0 R15: 00000000ffffffff
[   50.680000] Call Trace: 
[   50.680000] 6023d898:  [<60016c99>] panic_exit+0x2f/0x45
[   50.680000] 6023d8b8:  [<600429ad>] notifier_call_chain+0x5f/0x96
[   50.680000] 6023d908:  [<60042a83>] atomic_notifier_call_chain+0xf/0x11
[   50.680000] 6023d918:  [<601a235d>] panic+0x105/0x1dc
[   50.680000] 6023d938:  [<6001c4a1>] ubd_intr+0x6d/0xc9
[   50.680000] 6023d978:  [<6004d5a9>] handle_irq_event_percpu+0x10a/0x126
[   50.680000] 6023d9c8:  [<6004d5e8>] handle_irq_event+0x23/0x2f
[   50.680000] 6023d9e8:  [<60018092>] free_irqs+0x72/0xdc
[   50.680000] 6023da18:  [<60016aa3>] relay_signal+0x38/0x79
[   50.680000] 6023da28:  [<600140d1>] sigio_handler+0x5a/0x5f
[   50.680000] 6023da48:  [<6001fc2d>] sig_handler_common+0x87/0x9b
[   50.680000] 6023da68:  [<6001fc7d>] real_alarm_handler+0x3c/0x3e
[   50.680000] 6023daf0:  [<6006cdab>] kernel_map_pages+0x73/0x18c
[   50.680000] 6023db78:  [<6001fd22>] sig_handler+0x30/0x3e
[   50.680000] 6023db98:  [<6001f93e>] handle_signal+0x72/0xa8
[   50.680000] 6023dbe8:  [<60020b3c>] hard_handler+0x10/0x14
[   50.680000] 6023dca8:  [<600d4985>] btrfs_unlink+0x75/0xbc
[   50.680000] 
/ # rm -rf /mnt/btr/var_tmp/paludis/dev-lang-jhc-9999/
[   53.270000] BUG: failure at /mnt/archive/src/linux-2.6/fs/btrfs/inode.c:2962/btrfs_unlink()!
[   53.270000] Kernel panic - not syncing: BUG!
[   53.270000] Call Trace: 
[   53.270000] 7fc9bc78:  [<601acc8e>] panic+0xea/0x1dc
[   53.270000] 7fc9bc98:  [<601ace20>] printk+0xa0/0xa8
[   53.270000] 7fc9bcf8:  [<600b80f2>] btrfs_free_path+0x2a/0x2f
[   53.270000] 7fc9bd48:  [<600daac7>] btrfs_unlink_inode+0x1b/0x3b
[   53.270000] 7fc9bd78:  [<600dabab>] btrfs_unlink+0xc4/0xee
[   53.270000] 7fc9bdb8:  [<6007ef54>] vfs_unlink+0x55/0x8e
[   53.270000] 7fc9bde8:  [<6007f055>] do_unlinkat+0xc8/0x156
[   53.270000] 7fc9be48:  [<6007746a>] sys_newlstat+0x29/0x34
[   53.270000] 7fc9bec8:  [<6007f11a>] sys_unlink+0x11/0x13
[   53.270000] 7fc9bed8:  [<600171dc>] handle_syscall+0x50/0x70
[   53.270000] 7fc9bef8:  [<60021aa9>] userspace+0x30f/0x3c9
[   53.270000] 7fc9bf58:  [<60001721>] kernel_init+0x0/0x103
[   53.270000] 7fc9bfc8:  [<60014955>] new_thread_handler+0x8d/0x9b
[   53.270000] 
[   53.270000] 
[   53.270000] Pid: 1, comm: busybox Not tainted 2.6.39-rc2+
[   53.270000] RIP: 0033:[<00000000005443a7>]
[   53.270000] RSP: 0000007fbfec0238  EFLAGS: 00000246
[   53.270000] RAX: ffffffffffffffda RBX: 00000000008536c0 RCX: ffffffffffffffff
[   53.270000] RDX: 0000007fbfec0240 RSI: 0000007fbfec0240 RDI: 00000000008536c0
[   53.270000] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[   53.270000] R10: 7263616d2d63612f R11: 0000000000000246 R12: 0000000000000000
[   53.270000] R13: 0000000040001010 R14: 00000000008536c0 R15: 00000000ffffffff
[   53.270000] Call Trace: 
[   53.270000] 7fc9bbf8:  [<60016ce9>] panic_exit+0x2f/0x45
[   53.270000] 7fc9bc18:  [<60043571>] notifier_call_chain+0x5f/0x96
[   53.270000] 7fc9bc68:  [<60043647>] atomic_notifier_call_chain+0xf/0x11
[   53.270000] 7fc9bc78:  [<601acca9>] panic+0x105/0x1dc
[   53.270000] 7fc9bc98:  [<601ace20>] printk+0xa0/0xa8
[   53.270000] 7fc9bcf8:  [<600b80f2>] btrfs_free_path+0x2a/0x2f
[   53.270000] 7fc9bd48:  [<600daac7>] btrfs_unlink_inode+0x1b/0x3b
[   53.270000] 7fc9bd78:  [<600dabab>] btrfs_unlink+0xc4/0xee
[   53.270000] 7fc9bdb8:  [<6007ef54>] vfs_unlink+0x55/0x8e
[   53.270000] 7fc9bde8:  [<6007f055>] do_unlinkat+0xc8/0x156
[   53.270000] 7fc9be48:  [<6007746a>] sys_newlstat+0x29/0x34
[   53.270000] 7fc9bec8:  [<6007f11a>] sys_unlink+0x11/0x13
[   53.270000] 7fc9bed8:  [<600171dc>] handle_syscall+0x50/0x70
[   53.270000] 7fc9bef8:  [<60021aa9>] userspace+0x30f/0x3c9
[   53.270000] 7fc9bf58:  [<60001721>] kernel_init+0x0/0x103
[   53.270000] 7fc9bfc8:  [<60014955>] new_thread_handler+0x8d/0x9b

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

richard -rw- weinberger

2011-04-12 11:22 UTC #6 lore raw

Quoted 11 lines · Sergei Trofimovich

Quoted 5 lines · On Tue, 12 Apr 2011 01:13:30 +0200 richard -rw- weinberger…
Quoted 2 lines
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?
Can you please test the attached patch?
The trace was broken long before I started working on UML.
Attached the BUG backtrace for a crash without and with patch. Patched one looks great!

Good.

Quoted 2 lines

The minor nit is Kbuild does not detect headers change, so I had to 'make clean' build dir first.

The patch adds only one file and does not touch anything else. So Kbuild can't detect this.

Quoted 6 lines

Thanks!
--
Sergei

Signature · 13 lines

Thanks,
//richard

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel