Bug#502383: linux-image-2.6.26-1-amd64: BUG at fs/jfs/jfs_metapage.c:742 assert(mp->count)
On Wed, 2008-10-15 at 22:49 -0700, Tom Epperly wrote:
> I followed up in /var/log/syslog and found:
>
> Oct 15 21:09:12 faerun kernel: [11052.080364] BUG at fs/jfs/jfs_metapage.c:742 assert(mp->count)
> Oct 15 21:09:13 faerun kernel: [11052.080424] ------------[ cut here ]------------
> Oct 15 21:09:13 faerun kernel: [11052.080427] kernel BUG at fs/jfs/jfs_metapage.c:742!
> Oct 15 22:35:02 faerun kernel: [16209.686185] ERROR: (device sda6): __get_metapage: mp->logical_size != size
> Oct 15 22:35:02 faerun kernel: [16209.705572] Pid: 11298, comm: gtk-gnash Tainted: P D 2.6.26-1-amd64 #1
> Oct 15 22:35:02 faerun kernel: [16209.705579]
> Oct 15 22:35:02 faerun kernel: [16209.705580] Call Trace:
> Oct 15 22:35:02 faerun kernel: [16209.705619] [<ffffffffa013a35b>] :jfs:__get_metapage+0x13e/0x39f
I suspect that these traps may be the result of memory corruption.
jfs's metapage structure is allocated from a dedicated mempool. The
second is almost certainly a result of some kind of memory corruption,
as the logical_size is never set to anything but 4096, and the caller
always passes in the same value. The first can also be explained by a
corrupted struct metapage.
The source of the memory corruption may be hard to determine. It could
be a use-after-free of a memory structure, or some wild pointer in any
kernel code.
Have you seen any other traps? I can't rule out a bug in jfs, but there
haven't been any recent changes in this part of the code.
--
David Kleikamp
IBM Linux Technology Center
Reply to: