lkml.org 
[lkml]   [2009]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [slab corruption] BUG key_jar: Poison overwritten
On Sat, Jan 17, 2009 at 9:33 PM, David Howells <dhowells@redhat.com> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
>
>> The problem was not reproducible - i tried the same config once more and
>> it didnt produce the bug. (this system has no known hardware flukes)
>
> Having thought about it some more, we can't necessarily pin the blame on the
> key management code. I think it more likely due to the previous owner of the
> page as it's the guard poisoning that got corrupted, not the allocated key
> struct. The problem is we don't know who that was. I wonder if it's
> practical to store a recent history of page allocs and releases in a circular
> buffer.

This is what I think:

[ 44.482064] INFO: 0xf5f320c0-0xf5f320c0. First byte 0x6a instead of 0x6b
...
[ 44.482064] Object 0xf5f320c0: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk

Only the first byte has been changed. It changed from 0x6b to 0x6a.
Smells like a decrement. And yes, this particular cache allocates
'struct key's, which has an 'atomic_t usage' as its first member. So a
refcounting bug, most likely (key_put() was called too many times). Or
a missing key_get() somewhere?

It also seems noteworthy that no other data has been changed since the
last key_put() (i.e. since the refcount hit zero).

[ 44.482064] Bytes b4 0xf5f320b0: 7c 05 ff ff 5a 5a 5a 5a 5a 5a 5a
5a 5a 5a 5a 5a |.��ZZZZZZZZZZZZ

...I guess "bytes b4" means "bytes before"?


Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
\
 
 \ /
  Last update: 2009-01-17 22:47    [W:0.087 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site