2015-01-31 2:16 GMT+03:00 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>: > On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote: > >> >> > 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. >> >> > 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? > Yes! Thank you, this looks much better. > /* > * 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>