[uml-devel] btrfs failure and BUG_ON behaviour

[uml-devel] btrfs failure and BUG_ON behaviour

[Sergei Trofimovich]

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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[richard -rw- weinberger]

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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[Sergei Trofimovich]

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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[Sergei Trofimovich]

[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]

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

-- 

  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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[richard -rw- weinberger]

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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[Sergei Trofimovich]

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

Re: [uml-devel] btrfs failure and BUG_ON behaviour

[richard -rw- weinberger]

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