From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by lists.ozlabs.org (Postfix) with ESMTP id 3xv6h90h9ZzDrZl for ; Sat, 16 Sep 2017 06:39:19 +1000 (AEST) Date: Fri, 15 Sep 2017 21:38:53 +0100 From: Mark Rutland To: Pavel Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net, willy@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org, will.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org, mgorman@techsingularity.net, Steven.Sistare@oracle.com, daniel.m.jordan@oracle.com, bob.picco@oracle.com Subject: Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory Message-ID: <20170915203852.GA10749@remoulade> References: <20170914223517.8242-1-pasha.tatashin@oracle.com> <20170914223517.8242-11-pasha.tatashin@oracle.com> <20170915011035.GA6936@remoulade> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the temporary tables at this point in time. I'm still not keen on duplicating the iteration. Can we split the vmemmap code so that we have a variant that takes a GFP? That way we could explicitly pass __GFP_ZERO for those cases where we want a zeroed page, and are happy to pay the cost of initialization. Thanks Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Date: Fri, 15 Sep 2017 20:38:53 +0000 Subject: Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory Message-Id: <20170915203852.GA10749@remoulade> List-Id: References: <20170914223517.8242-1-pasha.tatashin@oracle.com> <20170914223517.8242-11-pasha.tatashin@oracle.com> <20170915011035.GA6936@remoulade> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the temporary tables at this point in time. I'm still not keen on duplicating the iteration. Can we split the vmemmap code so that we have a variant that takes a GFP? That way we could explicitly pass __GFP_ZERO for those cases where we want a zeroed page, and are happy to pay the cost of initialization. Thanks Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Fri, 15 Sep 2017 21:38:53 +0100 Subject: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory In-Reply-To: References: <20170914223517.8242-1-pasha.tatashin@oracle.com> <20170914223517.8242-11-pasha.tatashin@oracle.com> <20170915011035.GA6936@remoulade> Message-ID: <20170915203852.GA10749@remoulade> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the temporary tables at this point in time. I'm still not keen on duplicating the iteration. Can we split the vmemmap code so that we have a variant that takes a GFP? That way we could explicitly pass __GFP_ZERO for those cases where we want a zeroed page, and are happy to pay the cost of initialization. Thanks Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id D30386B0038 for ; Fri, 15 Sep 2017 16:39:16 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id 85so8159229ith.0 for ; Fri, 15 Sep 2017 13:39:16 -0700 (PDT) Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com. [217.140.101.70]) by mx.google.com with ESMTP id b189si1060930oii.14.2017.09.15.13.39.15 for ; Fri, 15 Sep 2017 13:39:15 -0700 (PDT) Date: Fri, 15 Sep 2017 21:38:53 +0100 From: Mark Rutland Subject: Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory Message-ID: <20170915203852.GA10749@remoulade> References: <20170914223517.8242-1-pasha.tatashin@oracle.com> <20170914223517.8242-11-pasha.tatashin@oracle.com> <20170915011035.GA6936@remoulade> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Pavel Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net, willy@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org, will.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org, mgorman@techsingularity.net, Steven.Sistare@oracle.com, daniel.m.jordan@oracle.com, bob.picco@oracle.com On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote: > Hi Mark, > > Thank you for looking at this. We can't do this because page table is not > set until cpu_replace_ttbr1() is called. So, we can't do memset() on this > memory until then. I see. Sorry, I had missed that we were on the temporary tables at this point in time. I'm still not keen on duplicating the iteration. Can we split the vmemmap code so that we have a variant that takes a GFP? That way we could explicitly pass __GFP_ZERO for those cases where we want a zeroed page, and are happy to pay the cost of initialization. Thanks Mark. -- 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