* [uml-devel] btrfs failure and BUG_ON behaviour
@ 2011-04-09 14:04 Sergei Trofimovich
2011-04-09 21:33 ` richard -rw- weinberger
2011-04-11 23:13 ` richard -rw- weinberger
0 siblings, 2 replies; 7+ messages in thread
From: Sergei Trofimovich @ 2011-04-09 14:04 UTC (permalink / raw)
To: user-mode-linux-devel
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [uml-devel] btrfs failure and BUG_ON behaviour
2011-04-09 14:04 [uml-devel] btrfs failure and BUG_ON behaviour Sergei Trofimovich
@ 2011-04-09 21:33 ` richard -rw- weinberger
2011-04-10 6:56 ` Sergei Trofimovich
2011-04-11 23:13 ` richard -rw- weinberger
1 sibling, 1 reply; 7+ messages in thread
From: richard -rw- weinberger @ 2011-04-09 21:33 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: user-mode-linux-devel
On Sat, Apr 9, 2011 at 4:04 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
> 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?
It's expected behavior.
> 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. :-)
>
> [ 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.
> 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 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?
> 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
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>
>
--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] btrfs failure and BUG_ON behaviour
2011-04-09 21:33 ` richard -rw- weinberger
@ 2011-04-10 6:56 ` Sergei Trofimovich
2011-04-10 19:58 ` Sergei Trofimovich
0 siblings, 1 reply; 7+ messages in thread
From: Sergei Trofimovich @ 2011-04-10 6:56 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: user-mode-linux-devel
[-- Attachment #1.1: Type: text/plain, Size: 1595 bytes --]
On Sat, 9 Apr 2011 23:33:14 +0200
richard -rw- weinberger <richard.weinberger@gmail.com> wrote:
> 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.
> 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.
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] btrfs failure and BUG_ON behaviour
2011-04-09 14:04 [uml-devel] btrfs failure and BUG_ON behaviour Sergei Trofimovich
2011-04-09 21:33 ` richard -rw- weinberger
@ 2011-04-11 23:13 ` richard -rw- weinberger
2011-04-12 10:13 ` Sergei Trofimovich
1 sibling, 1 reply; 7+ messages in thread
From: richard -rw- weinberger @ 2011-04-11 23:13 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: user-mode-linux-devel
[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]
On Sat, Apr 9, 2011 at 4:04 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
> 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?
Can you please test the attached patch?
The trace was broken long before I started working on UML.
> 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
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>
>
--
Thanks,
//richard
[-- Attachment #2: 0001-um-Fix-call-tracer-and-bug-handler.patch --]
[-- Type: text/x-patch, Size: 882 bytes --]
From d3808c146d987e0add9e793f56f1d58883eb5c7a Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard@nod.at>
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 <richard@nod.at>
---
arch/um/include/asm/bug.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 arch/um/include/asm/bug.h
diff --git a/arch/um/include/asm/bug.h b/arch/um/include/asm/bug.h
new file mode 100644
index 0000000..9e33b86
--- /dev/null
+++ b/arch/um/include/asm/bug.h
@@ -0,0 +1,6 @@
+#ifndef __UM_BUG_H
+#define __UM_BUG_H
+
+#include <asm-generic/bug.h>
+
+#endif
--
1.6.6.1
[-- Attachment #3: Type: text/plain, Size: 434 bytes --]
------------------------------------------------------------------------------
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
[-- Attachment #4: 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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [uml-devel] btrfs failure and BUG_ON behaviour
2011-04-11 23:13 ` richard -rw- weinberger
@ 2011-04-12 10:13 ` Sergei Trofimovich
2011-04-12 11:22 ` richard -rw- weinberger
0 siblings, 1 reply; 7+ messages in thread
From: Sergei Trofimovich @ 2011-04-12 10:13 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: user-mode-linux-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 597 bytes --]
On Tue, 12 Apr 2011 01:13:30 +0200
richard -rw- weinberger <richard.weinberger@gmail.com> wrote:
> > 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!
--
Sergei
[-- Attachment #1.1.2: without-patch.txt --]
[-- Type: text/plain, Size: 2820 bytes --]
/ # 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]
[-- Attachment #1.1.3: with-patch.txt --]
[-- Type: text/plain, Size: 2713 bytes --]
/ # 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
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 434 bytes --]
------------------------------------------------------------------------------
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
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] btrfs failure and BUG_ON behaviour
2011-04-12 10:13 ` Sergei Trofimovich
@ 2011-04-12 11:22 ` richard -rw- weinberger
0 siblings, 0 replies; 7+ messages in thread
From: richard -rw- weinberger @ 2011-04-12 11:22 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: user-mode-linux-devel
On Tue, Apr 12, 2011 at 12:13 PM, Sergei Trofimovich <slyich@gmail.com> wrote:
> On Tue, 12 Apr 2011 01:13:30 +0200
> richard -rw- weinberger <richard.weinberger@gmail.com> wrote:
>
>> > 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.
> 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.
> Thanks!
>
> --
>
> Sergei
>
--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-04-12 11:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-09 14:04 [uml-devel] btrfs failure and BUG_ON behaviour Sergei Trofimovich
2011-04-09 21:33 ` 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
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.