Messages in this thread | | | Date | Sat, 31 Jan 2015 03:19:25 +0400 | Subject | Re: [PATCH v10 06/17] mm: slub: introduce metadata_access_enable()/metadata_access_disable() | From | Andrey Ryabinin <> |
| |
2015-01-31 2:16 GMT+03:00 Andrew Morton <akpm@linux-foundation.org>: > On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin <ryabinin.a.a@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? >
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. > */
| |