[{"id":1768908,"web_url":"http://patchwork.ozlabs.org/comment/1768908/","msgid":"<20170915011035.GA6936@remoulade>","list_archive_url":null,"date":"2017-09-15T01:10:36","subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Thu, Sep 14, 2017 at 06:35:16PM -0400, Pavel Tatashin wrote:\n> To optimize the performance of struct page initialization,\n> vmemmap_populate() will no longer zero memory.\n> \n> We must explicitly zero the memory that is allocated by vmemmap_populate()\n> for kasan, as this memory does not go through struct page initialization\n> path.\n> \n> Signed-off-by: Pavel Tatashin \n> Reviewed-by: Steven Sistare \n> Reviewed-by: Daniel Jordan \n> Reviewed-by: Bob Picco \n> ---\n> arch/arm64/mm/kasan_init.c | 42 ++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 42 insertions(+)\n> \n> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c\n> index 81f03959a4ab..e78a9ecbb687 100644\n> --- a/arch/arm64/mm/kasan_init.c\n> +++ b/arch/arm64/mm/kasan_init.c\n> @@ -135,6 +135,41 @@ static void __init clear_pgds(unsigned long start,\n> \t\tset_pgd(pgd_offset_k(start), __pgd(0));\n> }\n> \n> +/*\n> + * Memory that was allocated by vmemmap_populate is not zeroed, so we must\n> + * zero it here explicitly.\n> + */\n> +static void\n> +zero_vmemmap_populated_memory(void)\n> +{\n> +\tstruct memblock_region *reg;\n> +\tu64 start, end;\n> +\n> +\tfor_each_memblock(memory, reg) {\n> +\t\tstart = __phys_to_virt(reg->base);\n> +\t\tend = __phys_to_virt(reg->base + reg->size);\n> +\n> +\t\tif (start >= end)\n> +\t\t\tbreak;\n> +\n> +\t\tstart = (u64)kasan_mem_to_shadow((void *)start);\n> +\t\tend = (u64)kasan_mem_to_shadow((void *)end);\n> +\n> +\t\t/* Round to the start end of the mapped pages */\n> +\t\tstart = round_down(start, SWAPPER_BLOCK_SIZE);\n> +\t\tend = round_up(end, SWAPPER_BLOCK_SIZE);\n> +\t\tmemset((void *)start, 0, end - start);\n> +\t}\n> +\n> +\tstart = (u64)kasan_mem_to_shadow(_text);\n> +\tend = (u64)kasan_mem_to_shadow(_end);\n> +\n> +\t/* Round to the start end of the mapped pages */\n> +\tstart = round_down(start, SWAPPER_BLOCK_SIZE);\n> +\tend = round_up(end, SWAPPER_BLOCK_SIZE);\n> +\tmemset((void *)start, 0, end - start);\n> +}\n\nI really don't see the need to duplicate the existing logic to iterate over\nmemblocks, calculate the addresses, etc.\n\nWhy can't we just have a zeroing wrapper? e.g. something like the below.\n\nI really don't see why we couldn't have a generic function in core code to do\nthis, even if vmemmap_populate() doesn't.\n\nThanks,\nMark.\n\n---->8----\ndiff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c\nindex 81f0395..698d065 100644\n--- a/arch/arm64/mm/kasan_init.c\n+++ b/arch/arm64/mm/kasan_init.c\n@@ -135,6 +135,17 @@ static void __init clear_pgds(unsigned long start,\n set_pgd(pgd_offset_k(start), __pgd(0));\n }\n \n+void kasan_populate_shadow(unsigned long shadow_start, unsigned long shadow_end,\n+ nid_t nid)\n+{\n+ shadow_start = round_down(shadow_start, SWAPPER_BLOCK_SIZE);\n+ shadow_end = round_up(shadow_end, SWAPPER_BLOCK_SIZE);\n+\n+ vmemmap_populate(shadow_start, shadow_end, nid);\n+\n+ memset((void *)shadow_start, 0, shadow_end - shadow_start);\n+}\n+\n void __init kasan_init(void)\n {\n u64 kimg_shadow_start, kimg_shadow_end;\n@@ -161,8 +172,8 @@ void __init kasan_init(void)\n \n clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);\n \n- vmemmap_populate(kimg_shadow_start, kimg_shadow_end,\n- pfn_to_nid(virt_to_pfn(lm_alias(_text))));\n+ kasah_populate_shadow(kimg_shadow_start, kimg_shadow_end,\n+ pfn_to_nid(virt_to_pfn(lm_alias(_text))));\n \n /*\n * vmemmap_populate() has populated the shadow region that covers the\n@@ -191,9 +202,9 @@ void __init kasan_init(void)\n if (start >= end)\n break;\n \n- vmemmap_populate((unsigned long)kasan_mem_to_shadow(start),\n- (unsigned long)kasan_mem_to_shadow(end),\n- pfn_to_nid(virt_to_pfn(start)));\n+ kasan_populate_shadow((unsigned long)kasan_mem_to_shadow(start),\n+ (unsigned long)kasan_mem_to_shadow(end),\n+ pfn_to_nid(virt_to_pfn(start)));\n }\n \n /*\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xtcll3pc5z9sPr\n\tfor ;\n\tFri, 15 Sep 2017 11:10:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751678AbdIOBKm (ORCPT );\n\tThu, 14 Sep 2017 21:10:42 -0400","from foss.arm.com ([217.140.101.70]:42528 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751607AbdIOBKm (ORCPT );\n\tThu, 14 Sep 2017 21:10:42 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8FB701435;\n\tThu, 14 Sep 2017 18:10:41 -0700 (PDT)","from remoulade (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t1127A3F483; Thu, 14 Sep 2017 18:10:41 -0700 (PDT)"],"Date":"Fri, 15 Sep 2017 02:10:36 +0100","From":"Mark Rutland ","To":"Pavel Tatashin ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org,\n\twill.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steven.Sistare@oracle.com,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","Message-ID":"<20170915011035.GA6936@remoulade>","References":"<20170914223517.8242-1-pasha.tatashin@oracle.com>\n\t<20170914223517.8242-11-pasha.tatashin@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170914223517.8242-11-pasha.tatashin@oracle.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1768916,"web_url":"http://patchwork.ozlabs.org/comment/1768916/","msgid":"","list_archive_url":null,"date":"2017-09-15T01:30:28","subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Mark,\n\nThank you for looking at this. We can't do this because page table is \nnot set until cpu_replace_ttbr1() is called. So, we can't do memset() on \nthis memory until then.\n\nPasha\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xtdDg3G0xz9t2V\n\tfor ;\n\tFri, 15 Sep 2017 11:32:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751678AbdIOBcQ (ORCPT );\n\tThu, 14 Sep 2017 21:32:16 -0400","from aserp1040.oracle.com ([141.146.126.69]:50422 \"EHLO\n\taserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751599AbdIOBcQ (ORCPT\n\t); Thu, 14 Sep 2017 21:32:16 -0400","from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v8F1UaB6029369\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 15 Sep 2017 01:30:37 GMT","from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])\n\tby userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv8F1UYvw019410\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 15 Sep 2017 01:30:35 GMT","from ubhmp0020.oracle.com (ubhmp0020.oracle.com [156.151.24.73])\n\tby aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8F1UTeY011766; \n\tFri, 15 Sep 2017 01:30:29 GMT","from [172.20.162.102] (/12.145.98.253)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Fri, 15 Sep 2017 01:30:28 +0000"],"Subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","To":"Mark Rutland ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org,\n\twill.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steven.Sistare@oracle.com,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","References":"<20170914223517.8242-1-pasha.tatashin@oracle.com>\n\t<20170914223517.8242-11-pasha.tatashin@oracle.com>\n\t<20170915011035.GA6936@remoulade>","From":"Pavel Tatashin ","Message-ID":"","Date":"Thu, 14 Sep 2017 21:30:28 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170915011035.GA6936@remoulade>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit","Content-Language":"en-US","X-Source-IP":"userv0021.oracle.com [156.151.31.71]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1769437,"web_url":"http://patchwork.ozlabs.org/comment/1769437/","msgid":"<20170915203852.GA10749@remoulade>","list_archive_url":null,"date":"2017-09-15T20:38:53","subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote:\n> Hi Mark,\n> \n> Thank you for looking at this. We can't do this because page table is not\n> set until cpu_replace_ttbr1() is called. So, we can't do memset() on this\n> memory until then.\n\nI see. Sorry, I had missed that we were on the temporary tables at this point\nin time.\n\nI'm still not keen on duplicating the iteration. Can we split the vmemmap code\nso that we have a variant that takes a GFP? \n\nThat way we could explicitly pass __GFP_ZERO for those cases where we want a\nzeroed page, and are happy to pay the cost of initialization.\n\nThanks\nMark.\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xv6hK27P6z9s83\n\tfor ;\n\tSat, 16 Sep 2017 06:39:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751710AbdIOUjP (ORCPT );\n\tFri, 15 Sep 2017 16:39:15 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52196 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751691AbdIOUjP (ORCPT );\n\tFri, 15 Sep 2017 16:39:15 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 44FEB15A2;\n\tFri, 15 Sep 2017 13:39:14 -0700 (PDT)","from remoulade (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tAD80B3F3E1; Fri, 15 Sep 2017 13:39:13 -0700 (PDT)"],"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,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org,\n\twill.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steven.Sistare@oracle.com,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","Message-ID":"<20170915203852.GA10749@remoulade>","References":"<20170914223517.8242-1-pasha.tatashin@oracle.com>\n\t<20170914223517.8242-11-pasha.tatashin@oracle.com>\n\t<20170915011035.GA6936@remoulade>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1769456,"web_url":"http://patchwork.ozlabs.org/comment/1769456/","msgid":"","list_archive_url":null,"date":"2017-09-15T21:20:59","subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Mark,\n\nI had this option  back upto version 3, where zero flag was passed into \nvmemmap_alloc_block(), but I was asked to remove it, because it required \ntoo many changes in other places. So, the current approach is cleaner, \nbut the idea is that kasan should use its own version of \nvmemmap_populate() for both x86 and ARM, but I think it is outside of \nthe scope of this work.\n\nSee this comment from Ard Biesheuvel:\nhttps://lkml.org/lkml/2017/8/3/948\n\n\"\nKASAN uses vmemmap_populate as a convenience: kasan has nothing to do\nwith vmemmap, but the function already existed and happened to do what\nKASAN requires.\n\nGiven that that will no longer be the case, it would be far better to\nstop using vmemmap_populate altogether, and clone it into a KASAN\nspecific version (with an appropriate name) with the zeroing folded\ninto it.\n\"\n\nIf you think I should add these function in this project, than sure I \ncan send a new version with kasanmap_populate() functions.\n\nThank you,\nPasha\n\nOn 09/15/2017 04:38 PM, Mark Rutland wrote:\n> On Thu, Sep 14, 2017 at 09:30:28PM -0400, Pavel Tatashin wrote:\n>> Hi Mark, Thank you for looking at this. We can't do this because page \n>> table is not set until cpu_replace_ttbr1() is called. So, we can't do \n>> memset() on this memory until then. \n> I see. Sorry, I had missed that we were on the temporary tables at \n> this point in time. I'm still not keen on duplicating the iteration. \n> Can we split the vmemmap code so that we have a variant that takes a \n> GFP? That way we could explicitly pass __GFP_ZERO for those cases \n> where we want a zeroed page, and are happy to pay the cost of \n> initialization. Thanks Mark.\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xv7dj6QJVz9sDB\n\tfor ;\n\tSat, 16 Sep 2017 07:22:17 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751790AbdIOVWR (ORCPT );\n\tFri, 15 Sep 2017 17:22:17 -0400","from userp1040.oracle.com ([156.151.31.81]:45747 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751673AbdIOVWQ (ORCPT\n\t); Fri, 15 Sep 2017 17:22:16 -0400","from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v8FLKv5L021779\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 15 Sep 2017 21:20:57 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8FLKvNN011371\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 15 Sep 2017 21:20:57 GMT","from ubhmp0015.oracle.com (ubhmp0015.oracle.com [156.151.24.68])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8FLKtVp021692; \n\tFri, 15 Sep 2017 21:20:56 GMT","from [172.20.162.102] (/12.145.98.253)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Fri, 15 Sep 2017 21:20:55 +0000"],"Subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","To":"Mark Rutland ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org,\n\twill.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steven.Sistare@oracle.com,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","References":"<20170914223517.8242-1-pasha.tatashin@oracle.com>\n\t<20170914223517.8242-11-pasha.tatashin@oracle.com>\n\t<20170915011035.GA6936@remoulade>\n\t\n\t<20170915203852.GA10749@remoulade>","From":"Pavel Tatashin ","Message-ID":"","Date":"Fri, 15 Sep 2017 17:20:59 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170915203852.GA10749@remoulade>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-Source-IP":"userv0022.oracle.com [156.151.31.74]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1769486,"web_url":"http://patchwork.ozlabs.org/comment/1769486/","msgid":"<20170915215147.GA11849@remoulade>","list_archive_url":null,"date":"2017-09-15T21:51:48","subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Fri, Sep 15, 2017 at 05:20:59PM -0400, Pavel Tatashin wrote:\n> Hi Mark,\n> \n> I had this option  back upto version 3, where zero flag was passed into\n> vmemmap_alloc_block(), but I was asked to remove it, because it required too\n> many changes in other places.\n\nOk. Sorry for bringing back a point that had already been covered.\n\n> So, the current approach is cleaner, but the idea is that kasan should use\n> its own version of vmemmap_populate() for both x86 and ARM, but I think it is\n> outside of the scope of this work.\n\nI appreciate that this is unrelated to your ultimate goal, and that this is\nsomewhat frustrating given the KASAN code is arguably abusing the\nvmemmap_populate() interface.\n\nHowever, I do think we need to migrate the KASAN code to a proper interface\nimmediately, rather than making it worse in the interim.\n\n> If you think I should add these function in this project, than sure I can\n> send a new version with kasanmap_populate() functions.\n\nI would very much appreciate if you could send a version with a\nkasan_map_populate() interface. I'm more than happy to review/test that portion\nof the series, or to help if there's some problem which makes that difficult.\n\nThanks,\nMark.\n--\nTo unsubscribe from this list: send the line \"unsubscribe sparclinux\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=sparclinux-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xv8m63g61z9s81\n\tfor ;\n\tSat, 16 Sep 2017 08:12:54 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751347AbdIOWMw (ORCPT );\n\tFri, 15 Sep 2017 18:12:52 -0400","from foss.arm.com ([217.140.101.70]:52924 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750873AbdIOWMv (ORCPT );\n\tFri, 15 Sep 2017 18:12:51 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 45BB480D;\n\tFri, 15 Sep 2017 15:12:51 -0700 (PDT)","from remoulade (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tA03203F483; Fri, 15 Sep 2017 15:12:50 -0700 (PDT)"],"Date":"Fri, 15 Sep 2017 22:51:48 +0100","From":"Mark Rutland ","To":"Pavel Tatashin ","Cc":"linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,\n\tlinux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tx86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com,\n\theiko.carstens@de.ibm.com, davem@davemloft.net,\n\twilly@infradead.org, mhocko@kernel.org, ard.biesheuvel@linaro.org,\n\twill.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steven.Sistare@oracle.com,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow\n\tmemory","Message-ID":"<20170915215147.GA11849@remoulade>","References":"<20170914223517.8242-1-pasha.tatashin@oracle.com>\n\t<20170914223517.8242-11-pasha.tatashin@oracle.com>\n\t<20170915011035.GA6936@remoulade>\n\t\n\t<20170915203852.GA10749@remoulade>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}}]