On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin [off-list ref] wrote:

quoted

quoted

quoted

kasan_disable_local/kasan_enable_local are also undocumented doesn't
help.

Ok, How about this?

/*
 * This hooks separate payload access from metadata access.
 * Useful for memory checkers that have to know when slub
 * accesses metadata.
 */

"These hooks".

I still don't understand :( Maybe I'm having a more-stupid-than-usual
day.

I think it's me being stupid today ;) I'll try to explain better.

quoted

How can a function "separate access"?  What does this mean?  More
details, please.  I think I've only once seen a comment which had too
much info!

slub could access memory marked by kasan as inaccessible (object's metadata).
Kasan shouldn't print report in that case because this access is valid.
Disabling instrumentation of slub.c code is not enough to achieve this
because slub passes pointer to object's metadata into memchr_inv().

We can't disable instrumentation for memchr_inv() because this is quite
generic function.

So metadata_access_enable/metadata_access_disable wrap some
places in slub.c where access to object's metadata starts/end.
And kasan_disable_local/kasan_enable_local just disable/enable
error reporting in this places.

ooh, I see.  Something like this?

/*
 * slub is about to manipulate internal object metadata.  This memory lies
 * outside the range of the allocated object, so accessing it would normally
 * be reported by kasan as a bounds error.  metadata_access_enable() is used
 * to tell kasan that these accesses are OK.
 */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>