Re: kernel BUG at fs/buffer.c:2790!

[Andrew Morton <akpm@osdl.org>]

Ralf Hildebrandt <Ralf.Hildebrandt@charite.de> wrote:
>
> This happens when umount'ing an intact softraid-5 with vanila 2.6.16.
> 
>  ------------[ cut here ]------------
>  kernel BUG at fs/buffer.c:2790!
>  invalid opcode: 0000 [#1]
>  PREEMPT
>  Modules linked in: sata_sil vmnet vmmon snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_via82xx snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore sk98lin
>  CPU:    0
>  EIP:    0060:[<b015fda9>]    Tainted: P      VLI

Can you confirm that an untainted kernel does the same thing?

>  EFLAGS: 00010246   (2.6.16 #1)
>  EIP is at submit_bh+0x109/0x130
>  eax: 00000005   ebx: d5e0ed54   ecx: 00000001   edx: 0000002b
>  esi: c9a0e000   edi: 00000001   ebp: 000040cd   esp: be715cb8
>  ds: 007b   es: 007b   ss: 0068
>  Process umount (pid: 7011, threadinfo=be714000 task=e0be3ab0)
>  Stack: <0>b13341c0 eeacc160 d5e0ed54 c9a0e000 ed772960 b015fe12 00000001 d5e0ed54
>         ed772960 c9a0e000 ed772960 c9a0e000 b01b3da1 d5e0ed54 be714000 ef2d8ae0
>         d5e0ed54 be714000 00000a61 b01b25f0 ed772960 00000001 b03b8bf6 0000032a
>  Call Trace:
>   [<b015fe12>] sync_dirty_buffer+0x42/0xe0
>   [<b01b3da1>] journal_update_superblock+0xc1/0xe0
>   [<b01b25f0>] cleanup_journal_tail+0xc0/0x190
>   [<b03b8bf6>] preempt_schedule_irq+0x46/0x70
>   [<b01b2914>] log_do_checkpoint+0x24/0x490
>   [<b0142ac2>] __pagevec_free+0x32/0x50
>   [<b0144963>] release_pages+0x33/0x220
>   [<b03b87c5>] schedule+0x315/0x640
>   [<b03b8c6d>] preempt_schedule+0x4d/0x60
>   [<b012e22f>] autoremove_wake_function+0x2f/0x60
>   [<b01b4e5b>] journal_destroy+0x12b/0x2c0
>   [<b0178cc2>] dispose_list+0x82/0x120
>   [<b01a767a>] ext3_put_super+0x2a/0x1f0
>   [<b01790b3>] invalidate_inodes+0xd3/0x110

We've lost BH_mapped on journal->j_sb_buffer.  it's a buffer_head against
the backing blockdev's pagecache.  JBD holds a ref on the buffer_head,
which should protect it from, say, invalidate_inode_pages().

If raid5 is doing something to kill the mapped bit in this bh, it must have
been very clever about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/