On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
FIX idr_layer_cache: Marking all objects used
Yesterday I couldn't reproduce the issue at all. But today I've hit exactly the same spot again. (CCing the drm list)
Well this is looks like write after free.
============================================================================= BUG idr_layer_cache: Poison overwritten
Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
And its an integer sized write of 0. If you look at the struct definition and lookup the offset you should be able to locate the field that was modified.
It also happens with CONFIG_SLAB. (If someone wants to reproduce the issue, just run a kexec boot loop and the bug will occur after a few (~10) iterations.)
Can you provide the kexec command line you are using and full kernel log (mostly interested in kernel option).
Cheers, Jerome