From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752176AbdHHNQK (ORCPT ); Tue, 8 Aug 2017 09:16:10 -0400 Received: from smtp-out4.electric.net ([192.162.216.195]:55022 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752070AbdHHNQJ (ORCPT ); Tue, 8 Aug 2017 09:16:09 -0400 From: David Laight To: "'Pasha Tatashin'" , Will Deacon CC: "linux-s390@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "sam@ravnborg.org" , "borntraeger@de.ibm.com" , "catalin.marinas@arm.com" , "x86@kernel.org" , "heiko.carstens@de.ibm.com" , "linux-kernel@vger.kernel.org" , "kasan-dev@googlegroups.com" , "mhocko@kernel.org" , "linux-mm@kvack.org" , "willy@infradead.org" , "sparclinux@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "davem@davemloft.net" , "linux-arm-kernel@lists.infradead.org" Subject: RE: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory Thread-Topic: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory Thread-Index: AQHTEDyykziJhjIJyE2lrcztU/8Jx6J6cAxg Date: Tue, 8 Aug 2017 13:15:55 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD004DA79@AcuExch.aculab.com> References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-12-git-send-email-pasha.tatashin@oracle.com> <20170808090743.GA12887@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v78DGeBA031260 From: Pasha Tatashin > Sent: 08 August 2017 12:49 > Thank you for looking at this change. What you described was in my > previous iterations of this project. > > See for example here: https://lkml.org/lkml/2017/5/5/369 > > I was asked to remove that flag, and only zero memory in place when > needed. Overall the current approach is better everywhere else in the > kernel, but it adds a little extra code to kasan initialization. Perhaps you could #define the function prototype(s?) so that the flags are not passed unless it is a kasan build? David