linux-kernel - Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Feb 2009 09:16:25 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Alessandro Bono <alessandro.bono@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-xfs <linux-xfs@....sgi.com>
Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4

On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote:
> Hi all
> 
> This time I hit kernel bug without any particular operation, normal
> browsing, mail, news, etc
> tell me if you need info asap because I want to reformat this machine
> and switch back to ext3.
>
> xfs seems really unstable in this particular
> machine and after this crash I lose again configuration file of opened
> program at crash time

That's not XFS's fault - that's a broken application that does not
safely overwrite files and hence you lose data on crash.

> Feb  7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut
> here ]------------
> Feb  7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at
> fs/buffer.c:470!

I can't remember seeing that problem before.

> Call Trace:
>  [<ffffffff8022806f>] ?  need_resched+0x1e/0x28
>  [<ffffffff8030be35>] ?  __up_write+0x12/0x45
>  [<ffffffffa01c2269>] ?  xfs_destroy_ioend+0x23/0x71 [xfs]
>  [<ffffffffa01c23db>] ?  xfs_end_bio_delalloc+0x0/0x19 [xfs]
>  [<ffffffffa01c23db>] ?  xfs_end_bio_delalloc+0x0/0x19 [xfs]
>  [<ffffffff80242d5e>] ?  run_workqueue+0x79/0xfe
>  [<ffffffff80242ed3>] ?  worker_thread+0xf0/0x102
>  [<ffffffff802461cd>] ?  autoremove_wake_function+0x0/0x2e
>  [<ffffffff80242de3>] ?  worker_thread+0x0/0x102
>  [<ffffffff80245ea2>] ?  kthread+0x47/0x73
>  [<ffffffff80231bfa>] ?  schedule_tail+0x27/0x60
>  [<ffffffff8020c3f9>] ?  child_rip+0xa/0x11
>  [<ffffffff80245e5b>] ?  kthread+0x0/0x73
>  [<ffffffff8020c3ef>] ?  child_rip+0x0/0x11

Standard delayed allocation IO completion trace. No idea what
could have caused it. Perhaps a memory error? 

Can you send the output of xfs_info on that filesystem, and
perhaps run an xfs_repair -n  on it to see if there are any
undetected errors on disk?

Also, I note that you are using ext4 on some disks. Does this
problem show up if you don't use ext4 at all? (We have had problems
in the past with one filesystem not leaving bufferheads in the
correct state and the system crashing when a different type of
filesystem got them reallocated).

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/