From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by kanga.kvack.org (Postfix) with ESMTP id 15A266B0032 for ; Fri, 30 Jan 2015 18:16:46 -0500 (EST) Received: by mail-pa0-f51.google.com with SMTP id fb1so57952473pad.10 for ; Fri, 30 Jan 2015 15:16:45 -0800 (PST) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTPS id nt3si15275398pdb.180.2015.01.30.15.16.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jan 2015 15:16:45 -0800 (PST) Date: Fri, 30 Jan 2015 15:16:43 -0800 From: Andrew Morton Subject: Re: [PATCH v10 06/17] mm: slub: introduce metadata_access_enable()/metadata_access_disable() Message-Id: <20150130151643.400b369ba4fc3c50a1353ddf@linux-foundation.org> In-Reply-To: References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <1422544321-24232-1-git-send-email-a.ryabinin@samsung.com> <1422544321-24232-7-git-send-email-a.ryabinin@samsung.com> <20150129151243.fd76aca21757b1ca5b62163e@linux-foundation.org> <54CBB9C9.3060500@samsung.com> <20150130134217.73d6f43f8257936275351834@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Ryabinin Cc: Andrey Ryabinin , LKML , Dmitry Vyukov , Konstantin Serebryany , Dmitry Chernenkov , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Christoph Lameter , Joonsoo Kim , Dave Hansen , Andi Kleen , "x86@kernel.org" , "linux-mm@kvack.org" , Pekka Enberg , David Rientjes On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin 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, 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: email@kvack.org