On Mon, Jun 08, 2015 at 11:48:54AM -0400, Chris Mason wrote:
> On 06/06/2015 02:07 AM, Tomasz Chmielewski wrote:
> > 4.1-rc6, busy filesystem.
> >
> > I was running mongo import which made quite a lot of IO.
> > During the import, I did "chattr +C /var/lib/mongodb" - shortly after I
> > saw this in dmesg and server died:
> >
> > [57860.149839] BUG: unable to handle kernel NULL pointer dereference at
> > 0000000000000008
> > [57860.149877] IP: [<ffffffffc0158b8e>]
> > btrfs_wait_pending_ordered+0x5e/0x110 [btrfs]
>
> Sorry, it's not obvious where the 0000000000000008 is coming from, can
> you turn btrfs_wait_pending_ordered+0x5e/0x110 into a line number?
>
> Use list *btrfs_wait_pending_ordered+0x5e at the gdb prompt, after you
> gdb btrfs.ko
Guesswork, but doing that on my sources points to __list_del
(gdb) l *(btrfs_wait_pending_ordered+0x5e)
0x333fe is in btrfs_wait_pending_ordered (include/linux/list.h:89).
84 * This is only for internal list manipulation where we know
85 * the prev/next entries already!
86 */
87 static inline void __list_del(struct list_head * prev, struct list_head * next)
88 {
89 next->prev = prev;
90 prev->next = next;
91 }
that is called from btrfs_wait_pending_ordered. The off 8 corresponds to 'prev'
of list_head, so the 'next' poiinter is NULL.
If we go from the list_del_init(ordered->trans_list) we find that it's called as
list_del(entry->prev, entry->next)
(ie entry === ordered->trans_list).
1755 while (!list_empty(&cur_trans->pending_ordered)) {
1756 ordered = list_first_entry(&cur_trans->pending_ordered,
1757 struct btrfs_ordered_extent,
1758 trans_list);
1759 list_del_init(&ordered->trans_list);
1760 spin_unlock(&fs_info->trans_lock);
1761
1762 wait_event(ordered->wait, test_bit(BTRFS_ORDERED_COMPLETE,
1763 &ordered->flags));
1764 btrfs_put_ordered_extent(ordered); 1765 spin_lock(&fs_info->trans_lock);
1766 }
So we probably got bogus data from cur_trans->pending_ordered. I don't know if
ordered is zeroed or if just the list_head got corrupted. The way the list_head
pointer magic works it's possible to get there both ways (I think).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
