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]
Message-ID: <20090208221625.GB8830@disturbed>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ