From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758247AbbA3XQq (ORCPT <rfc822;w@1wt.eu>);
	Fri, 30 Jan 2015 18:16:46 -0500
Received: from mail.linuxfoundation.org ([140.211.169.12]:48322 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752720AbbA3XQp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 30 Jan 2015 18:16:45 -0500
Date: Fri, 30 Jan 2015 15:16:43 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Andrey Ryabinin <a.ryabinin@samsung.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Dmitry Vyukov <dvyukov@google.com>,
        Konstantin Serebryany <kcc@google.com>,
        Dmitry Chernenkov <dmitryc@google.com>,
        Andrey Konovalov <adech.fo@gmail.com>,
        Yuri Gribov <tetra2005@gmail.com>,
        Konstantin Khlebnikov <koct9i@gmail.com>,
        Sasha Levin <sasha.levin@oracle.com>, Christoph Lameter <cl@linux.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Dave Hansen <dave.hansen@intel.com>, Andi Kleen <andi@firstfloor.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>
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: <CAPAsAGxPOC7j9Z=xjtobcdMEgGJB0L+drO1m4TWBgkNNfZWmSw@mail.gmail.com>
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>
	<CAPAsAGxPOC7j9Z=xjtobcdMEgGJB0L+drO1m4TWBgkNNfZWmSw@mail.gmail.com>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.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?

/*
 * 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.
 */