On Thu, Feb 06, 2014 at 05:04:49PM +0100, Bernd Schubert wrote: > I'm frequently getting > > UG: unable to handle kernel paging request at ffff880f87550dc0 > IP: [<ffffffff813016d0>] crc32_le+0x30/0x110 > > called from kmemleak, see bottom of the message. ... > With the "Cannot allocate a kmemleak_object structure" messages,
Just curious, is the free memory low when this happens? > somehow looks like object is not proper initialized, but update_checksum() > checks for that. Hmm, I'm not sure about kmemcheck_shadow_lookup(), > especially about > > > if (!virt_addr_valid(address)) > > return NULL; > > So is the test > > > shadow = kmemcheck_shadow_lookup(addr); > > if (!shadow) > > return true; > > right here? Shouldn't that be 'return false'? Are you using kmemcheck and kmemleak together? I don't think update_checksum() is called on the object being allocated but possibly on an object being freed when kmemleak_scan() is running. This is generally a safe operation because of the object locks in kmemleak_scan() but when an error condition just occurred (like kmemleak not being able to allocate memory), kmemleak gets disabled and kmemleak_free() no longer passes the information down to update the object's flags. At this point, the running kmemleak_scan() potentially reads unmmapped objects. I need to think a bit more about this. Thanks for reporting. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
