Hi,
The code decodes to:
mov 0x14(%rdx),%eax
mov (%rsi,%rax,8),%rax <--- HERE!
which corresponds to this code in mm/slub.c:
c->freelist = object[c->offset];
So the mov 0x14(%rdx) is the loading of c->offset, which means that
the pointer "c" is held in %rdx (= 0xffff880001016700), and the
variable c->offset is held in %eax (= 0).
It also means that the pointer "object" is held in %rsi (= 0x1a40ca0).
Now, clearly the object pointer is bogus. It was loaded on the line
above:
object = c->freelist;
..and it may look like c->freelist has become corrupted. This one is
again loaded from the line:
c = get_cpu_slab(s, smp_processor_id());
Everything seems normal, except the c->freelist pointer.
The rest of the messages are from the same function, but from
...this seems to suggest that none of the backtraces may actually give
a good clue as to who caused the corruption to begin with. (In other
words, I have no more clue than you on who to Cc this.)
Does the number 0x1a40ca0 look familiar to anybody?
Dieter: If this is reproducible, it would probably help quite a bit to
configure the kernel with CONFIG_SLUB_DEBUG and boot with
slub_debug=FZPUT (unless you already have CONFIG_SLUB_DEBUG_ON set, in
which case you are already running with the SLUB debugging at boot).
It might catch the corruption before it becomes fatal, or give us some
more clues anyway.
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
--
