From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753677AbaGOO0P (ORCPT ); Tue, 15 Jul 2014 10:26:15 -0400 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]:43679 "EHLO qmta03.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751442AbaGOO0N (ORCPT ); Tue, 15 Jul 2014 10:26:13 -0400 Date: Tue, 15 Jul 2014 09:26:08 -0500 (CDT) From: Christoph Lameter To: Joonsoo Kim cc: Andrey Ryabinin , linux-kernel@vger.kernel.org, Dmitry Vyukov , Konstantin Serebryany , Alexey Preobrazhensky , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Michal Marek , Russell King , Thomas Gleixner , Ingo Molnar , Pekka Enberg , David Rientjes , Andrew Morton , linux-kbuild@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org Subject: Re: [RFC/PATCH RESEND -next 14/21] mm: slub: kasan: disable kasan when touching unaccessible memory In-Reply-To: <20140715081852.GL11317@js1304-P5Q-DELUXE> Message-ID: References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <1404905415-9046-15-git-send-email-a.ryabinin@samsung.com> <20140715060405.GI11317@js1304-P5Q-DELUXE> <53C4DA54.3010502@samsung.com> <20140715081852.GL11317@js1304-P5Q-DELUXE> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Jul 2014, Joonsoo Kim wrote: > > I think putting disable/enable only where we strictly need them might be a problem for future maintenance of slub. > > If someone is going to add a new function call somewhere, he must ensure that it this call won't be a problem > > for kasan. > > I don't agree with this. > > If someone is going to add a slab_pad_check() in other places in > slub.c, we should disable/enable kasan there, too. This looks same > maintenance problem to me. Putting disable/enable only where we > strictly need at least ensures that we don't need to care when using > slub internal functions. > > And, if memchr_inv() is problem, I think that you also need to add hook > into validate_slab_cache(). > > validate_slab_cache() -> validate_slab_slab() -> validate_slab() -> > check_object() -> check_bytes_and_report() -> memchr_inv() I think adding disable/enable is good because it separates the payload access from metadata accesses. This may be useful for future checkers. Maybe call it something different so that this is more generic. metadata_access_enable() metadata_access_disable() ? Maybe someone else has a better idea? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by kanga.kvack.org (Postfix) with ESMTP id 0AC0A6B0036 for ; Tue, 15 Jul 2014 10:26:14 -0400 (EDT) Received: by mail-qg0-f44.google.com with SMTP id e89so240479qgf.17 for ; Tue, 15 Jul 2014 07:26:13 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net. [2001:558:fe2d:43:76:96:30:80]) by mx.google.com with ESMTP id j7si20651079qan.36.2014.07.15.07.26.12 for ; Tue, 15 Jul 2014 07:26:13 -0700 (PDT) Date: Tue, 15 Jul 2014 09:26:08 -0500 (CDT) From: Christoph Lameter Subject: Re: [RFC/PATCH RESEND -next 14/21] mm: slub: kasan: disable kasan when touching unaccessible memory In-Reply-To: <20140715081852.GL11317@js1304-P5Q-DELUXE> Message-ID: References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <1404905415-9046-15-git-send-email-a.ryabinin@samsung.com> <20140715060405.GI11317@js1304-P5Q-DELUXE> <53C4DA54.3010502@samsung.com> <20140715081852.GL11317@js1304-P5Q-DELUXE> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Andrey Ryabinin , linux-kernel@vger.kernel.org, Dmitry Vyukov , Konstantin Serebryany , Alexey Preobrazhensky , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Michal Marek , Russell King , Thomas Gleixner , Ingo Molnar , Pekka Enberg , David Rientjes , Andrew Morton , linux-kbuild@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org On Tue, 15 Jul 2014, Joonsoo Kim wrote: > > I think putting disable/enable only where we strictly need them might be a problem for future maintenance of slub. > > If someone is going to add a new function call somewhere, he must ensure that it this call won't be a problem > > for kasan. > > I don't agree with this. > > If someone is going to add a slab_pad_check() in other places in > slub.c, we should disable/enable kasan there, too. This looks same > maintenance problem to me. Putting disable/enable only where we > strictly need at least ensures that we don't need to care when using > slub internal functions. > > And, if memchr_inv() is problem, I think that you also need to add hook > into validate_slab_cache(). > > validate_slab_cache() -> validate_slab_slab() -> validate_slab() -> > check_object() -> check_bytes_and_report() -> memchr_inv() I think adding disable/enable is good because it separates the payload access from metadata accesses. This may be useful for future checkers. Maybe call it something different so that this is more generic. metadata_access_enable() metadata_access_disable() ? Maybe someone else has a better idea? -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: cl@gentwo.org (Christoph Lameter) Date: Tue, 15 Jul 2014 09:26:08 -0500 (CDT) Subject: [RFC/PATCH RESEND -next 14/21] mm: slub: kasan: disable kasan when touching unaccessible memory In-Reply-To: <20140715081852.GL11317@js1304-P5Q-DELUXE> References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <1404905415-9046-15-git-send-email-a.ryabinin@samsung.com> <20140715060405.GI11317@js1304-P5Q-DELUXE> <53C4DA54.3010502@samsung.com> <20140715081852.GL11317@js1304-P5Q-DELUXE> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 15 Jul 2014, Joonsoo Kim wrote: > > I think putting disable/enable only where we strictly need them might be a problem for future maintenance of slub. > > If someone is going to add a new function call somewhere, he must ensure that it this call won't be a problem > > for kasan. > > I don't agree with this. > > If someone is going to add a slab_pad_check() in other places in > slub.c, we should disable/enable kasan there, too. This looks same > maintenance problem to me. Putting disable/enable only where we > strictly need at least ensures that we don't need to care when using > slub internal functions. > > And, if memchr_inv() is problem, I think that you also need to add hook > into validate_slab_cache(). > > validate_slab_cache() -> validate_slab_slab() -> validate_slab() -> > check_object() -> check_bytes_and_report() -> memchr_inv() I think adding disable/enable is good because it separates the payload access from metadata accesses. This may be useful for future checkers. Maybe call it something different so that this is more generic. metadata_access_enable() metadata_access_disable() ? Maybe someone else has a better idea?