On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin <ryabinin....@gmail.com> 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? /* * 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 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/
