Bug 11506 - oops during unmount - ext3? (2.6.27-rc5)
Summary: oops during unmount - ext3? (2.6.27-rc5)
Status: CLOSED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: VFS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_vfs
URL:
Keywords:
Depends on:
Blocks: Regressions-2.6.26
  Show dependency tree
 
Reported: 2008-09-04 15:22 UTC by Rafael J. Wysocki
Modified: 2008-10-02 12:50 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.27-rc5
Tree: Mainline
Regression: Yes


Attachments

Description Rafael J. Wysocki 2008-09-04 15:22:38 UTC
Subject    : oops during unmount - ext3? (2.6.27-rc5)
Submitter  : Marcin Slusarz <marcin.slusarz@gmail.com>
Date       : 2008-09-04 19:14
References : http://marc.info/?l=linux-kernel&m=122055573123449&w=4

This entry is being used for tracking a regression from 2.6.26.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Chuck Ebbert 2008-09-06 21:20:14 UTC
        BUG_ON(!(inode->i_state & I_FREEING));
=>>>    BUG_ON(inode->i_state & I_CLEAR);

I_FREEING and I_CLEAR are both set.
Comment 2 Marcin Slusarz 2008-09-07 04:28:18 UTC
Another one:

* Deactivating swap
* Unmounting filesystems
general protection fault: 0000 [1] PREEMPT
CPU 0
Modules linked in: af_packet usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv ir_common compat_ioctl32 ac97_bus videodev v4l1_compat v4l2_common videobuf_dma_sg videobuf_core btcx_risc tveeprom i2c_viapro soundcode [last unloaded: snd_page_alloc]
Pid: 10420, comm: umount Not tainted 2.6.27-rc5 #362
RIP: 0010:[<ffffffff802f0770>] [<ffffffff802f0770>] journal_invalidatepage+0x4d/0x373
RSP: 0018:ffff88003c923c68  EFLAGS: 00010203
RAX: 0000000005200000 RBX: 1000c20d02020000 RCX: 000000000000003c
RDX: 0000000000000002 RSI: ffff88000000ff30 RDI: ffff880001001340
RBP: ffff88003c923db8 R08: ffff88003c923cd8 R09: 0000000000000001
R10: ffff880035bc37b0 R11: ffff88003a0ca828 R12: 0000000000026358
R13: 0000000000000001 R14: ffff88003cddf4f8 R15: 0000000000000001
FS:  00007f2ce7744750(0000) GS:ffffffff80623200(0000) knlGS:00000000f74d56d0
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000015c70d0 CR3: 000000003cd0e000 CD4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process umount (pid: 10420, threadinfo ffff88003c922000, task ffff88003a8ca140)
Stack:  0000000000000000 ffffe20000294098 1000c20d02020000 0520000000000001
 ffff88000000ff30 ffffe20000294098 0000000000026358 0000000000000001
 0000000000026358 ffff880035bc3798 ffff88003c923cc8 ffffffff802e2da7
Call Trace:
 [<ffffffff802e2da7>] ext3_invalidatepage+0x3c/0x3e
 [<ffffffff80272ad0>] do_invalidatepage+0x28/0x2a
 [<ffffffff80272f7a>] truncate_complete_page+0x2e/0x53
 [<ffffffff8027307d>] truncate_inode_pages_range+0xde/0x36b
 [<ffffffff8027331c>] truncate_inode_pages+0x12/0x16
 [<ffffffff802a4f62>] dispose_list+0x55/0x103
 [<ffffffff802a5301>] invalidate_inodes+0xe9/0x107
 [<ffffffff802932fd>] generic_shutdown_super+0x3f/0xfd
 [<ffffffff802933d5>] kill_block_super+0x1a/0x2f
 [<ffffffff802934a6>] ? deactivate_super+0x49/0x66
 [<ffffffff802934ae>] deactivate_super+0x51/0x66
 [<ffffffff802a7e18>] mntput_no_expire+0xbf/0xf1
 [<ffffffff802a83dc>] sys_umount+0x2ba/0x30b
 [<ffffffff8020b54b>] system_call_fastpath+0x16/0x1b


Code: 8b 06 a8 01 75 04 0f 0b eb fe f6 c4 08 0f 84 2f 03 00 00 48 8b 45 b8 48 8b 40 10 c7 45 c8 01 00 00 00 48 89 45 d0 48 89 c3 31 c0 <8b> 53 20 01 c2 89 c0 48 39 45 b0 89 55 cc 48 9b 53 08 48 89 55
RIP  [<ffffffff802f0770>] journal_invalidatepage+0x4d/0x373
 RSP <ffff88003c923c68>
---[end trace fd08b13862f53eb2 ]---

I had to transcribe it from screenshots.
(They are at: http://www.kadu.net/~joi/kernel/2008.09.07/ if you want to verify it)

Output of decodecode:
/tmp/tmp.bb6hqpz9LT.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   8b 06                   mov    (%rsi),%eax
   2:   a8 01                   test   $0x1,%al
   4:   75 04                   jne    0xa
   6:   0f 0b                   ud2a
   8:   eb fe                   jmp    0x8
   a:   f6 c4 08                test   $0x8,%ah
   d:   0f 84 2f 03 00 00       je     0x342
  13:   48 8b 45 b8             mov    -0x48(%rbp),%rax
  17:   48 8b 40 10             mov    0x10(%rax),%rax
  1b:   c7 45 c8 01 00 00 00    movl   $0x1,-0x38(%rbp)
  22:   48 89 45 d0             mov    %rax,-0x30(%rbp)
  26:   48 89 c3                mov    %rax,%rbx
  29:   31 c0                   xor    %eax,%eax

/tmp/tmp.bb6hqpz9LT.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   8b 53 20                mov    0x20(%rbx),%edx
   3:   01 c2                   add    %eax,%edx
   5:   89 c0                   mov    %eax,%eax
   7:   48 39 45 b0             cmp    %rax,-0x50(%rbp)
   b:   89 55 cc                mov    %edx,-0x34(%rbp)
   e:   48                      rex.W
   f:   9b                      fwait
  10:   53                      push   %rbx
  11:   08 48 89                or     %cl,-0x77(%rax)
  14:   55                      push   %rbp
Comment 3 Marcin Slusarz 2008-09-07 04:47:52 UTC
On Sun, Sep 07, 2008 at 01:27:40PM +0200, Marcin Slusarz wrote:
> Code: 8b 06 a8 01 75 04 0f 0b eb fe f6 c4 08 0f 84 2f 03 00 00 48 8b 45 b8 48
> 8b 40 10 c7 45 c8 01 00 00 00 48 89 45 d0 48 89 c3 31 c0 <8b> 53 20 01 c2 89
> c0 48 39 45 b0 89 55 cc 48 9b 53 08 48 89 55
Little correction (at the end):
  Code: 8b 06 a8 01 75 04 0f 0b eb fe f6 c4 08 0f 84 2f 03 00 00 48 8b 45 b8 48 8b 40 10 c7 45 c8 01 00 00 00 48 89 45 d0 48 89 c3 31 c0 <8b> 53 20 01 c2 89 c0 48 39 45 b0 89 55 cc 48 8b 53 08 48 89 55

> Output of decodecode:
After correction:
/tmp/tmp.W6DvY3Lbtg.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   8b 06                   mov    (%rsi),%eax
   2:   a8 01                   test   $0x1,%al
   4:   75 04                   jne    0xa
   6:   0f 0b                   ud2a
   8:   eb fe                   jmp    0x8
   a:   f6 c4 08                test   $0x8,%ah
   d:   0f 84 2f 03 00 00       je     0x342
  13:   48 8b 45 b8             mov    -0x48(%rbp),%rax
  17:   48 8b 40 10             mov    0x10(%rax),%rax
  1b:   c7 45 c8 01 00 00 00    movl   $0x1,-0x38(%rbp)
  22:   48 89 45 d0             mov    %rax,-0x30(%rbp)
  26:   48 89 c3                mov    %rax,%rbx
  29:   31 c0                   xor    %eax,%eax

/tmp/tmp.W6DvY3Lbtg.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   8b 53 20                mov    0x20(%rbx),%edx
   3:   01 c2                   add    %eax,%edx
   5:   89 c0                   mov    %eax,%eax
   7:   48 39 45 b0             cmp    %rax,-0x50(%rbp)
   b:   89 55 cc                mov    %edx,-0x34(%rbp)
   e:   48 8b 53 08             mov    0x8(%rbx),%rdx
  12:   48                      rex.W
  13:   89                      .byte 0x89
  14:   55                      push   %rbp
Comment 4 Jan Kara 2008-09-08 09:02:39 UTC
> On Sun, Sep 07, 2008 at 01:27:40PM +0200, Marcin Slusarz wrote:
> > Code: 8b 06 a8 01 75 04 0f 0b eb fe f6 c4 08 0f 84 2f 03 00 00 48 8b 45 b8
> 48 8b 40 10 c7 45 c8 01 00 00 00 48 89 45 d0 48 89 c3 31 c0 <8b> 53 20 01 c2
> 89 c0 48 39 45 b0 89 55 cc 48 9b 53 08 48 89 55
> Little correction (at the end):
>   Code: 8b 06 a8 01 75 04 0f 0b eb fe f6 c4 08 0f 84 2f 03 00 00 48 8b 45 b8
>   48 8b 40 10 c7 45 c8 01 00 00 00 48 89 45 d0 48 89 c3 31 c0 <8b> 53 20 01
>   c2 89 c0 48 39 45 b0 89 55 cc 48 8b 53 08 48 89 55
> 
> > Output of decodecode:
> After correction:
> /tmp/tmp.W6DvY3Lbtg.o:     file format elf64-x86-64
> 
> Disassembly of section .text:
> 
> 0000000000000000 <.text>:
>    0:   8b 06                   mov    (%rsi),%eax
>    2:   a8 01                   test   $0x1,%al
>    4:   75 04                   jne    0xa
>    6:   0f 0b                   ud2a
>    8:   eb fe                   jmp    0x8
>    a:   f6 c4 08                test   $0x8,%ah
>    d:   0f 84 2f 03 00 00       je     0x342
>   13:   48 8b 45 b8             mov    -0x48(%rbp),%rax
>   17:   48 8b 40 10             mov    0x10(%rax),%rax
>   1b:   c7 45 c8 01 00 00 00    movl   $0x1,-0x38(%rbp)
>   22:   48 89 45 d0             mov    %rax,-0x30(%rbp)
>   26:   48 89 c3                mov    %rax,%rbx
>   29:   31 c0                   xor    %eax,%eax
> 
> /tmp/tmp.W6DvY3Lbtg.o:     file format elf64-x86-64
> 
> Disassembly of section .text:
> 
> 0000000000000000 <.text>:
>    0:   8b 53 20                mov    0x20(%rbx),%edx
>    3:   01 c2                   add    %eax,%edx
>    5:   89 c0                   mov    %eax,%eax
>    7:   48 39 45 b0             cmp    %rax,-0x50(%rbp)
>    b:   89 55 cc                mov    %edx,-0x34(%rbp)
>    e:   48 8b 53 08             mov    0x8(%rbx),%rdx
>   12:   48                      rex.W
>   13:   89                      .byte 0x89
>   14:   55                      push   %rbp
  Hmm, from this disassembly it seems that somebody has overwritten our
page->private pointer to 1000c20d02020000 and then we obviously failed
to get bh->b_size. But I don't really see how this can happen. What also
puzzles me a bit is that I don't see BUG_ON(!PagePrivate(page)) in the
disassembly but it should be there because of page_buffers()
implementation... Anyone has an idea?

								Honza
Comment 5 Rafael J. Wysocki 2008-09-21 12:33:23 UTC
On Friday, 19 of September 2008, Marcin Slusarz wrote:
> On Fri, Sep 12, 2008 at 09:06:29PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.26.  Please verify if it still should be listed and let me know
> > (either way).
> 
> I didn't see it since I upgraded to -rc6. You can close it for now.
> 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=11506
> > Subject             : oops during unmount - ext3? (2.6.27-rc5)
> > Submitter   : Marcin Slusarz <marcin.slusarz@gmail.com>
> > Date                : 2008-09-04 19:14 (9 days old)
> > References  : http://marc.info/?l=linux-kernel&m=122055573123449&w=4
Comment 6 Marcin Slusarz 2008-10-02 10:44:47 UTC
I still can't reproduce it (-rc7 and -rc8).
Comment 7 Rafael J. Wysocki 2008-10-02 12:50:07 UTC
OK, closing.

Note You need to log in before you can comment on or make changes to this bug.