[{"id":1779032,"web_url":"http://patchwork.ozlabs.org/comment/1779032/","msgid":"<20171003144845.GD4931@leverpostej>","list_archive_url":null,"date":"2017-10-03T14:48:46","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Pavel,\n\nOn Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote:\n> During early boot, kasan uses vmemmap_populate() to establish its shadow\n> memory. But, that interface is intended for struct pages use.\n> \n> Because of the current project, vmemmap won't be zeroed during allocation,\n> but kasan expects that memory to be zeroed. We are adding a new\n> kasan_map_populate() function to resolve this difference.\n\nThanks for putting this together.\n\nI've given this a spin on arm64, and can confirm that it works.\n\nGiven that this involes redundant walking of page tables, I still think\nit'd be preferable to have some common *_populate() helper that took a\ngfp argument, but I guess it's not the end of the world.\n\nI'll leave it to Will and Catalin to say whether they're happy with the\npage table walking and the new p{u,m}d_large() helpers added to arm64.\n\nThanks,\nMark.\n\n> \n> Signed-off-by: Pavel Tatashin \n> ---\n> arch/arm64/include/asm/pgtable.h | 3 ++\n> include/linux/kasan.h | 2 ++\n> mm/kasan/kasan_init.c | 67 ++++++++++++++++++++++++++++++++++++++++\n> 3 files changed, 72 insertions(+)\n> \n> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h\n> index bc4e92337d16..d89713f04354 100644\n> --- a/arch/arm64/include/asm/pgtable.h\n> +++ b/arch/arm64/include/asm/pgtable.h\n> @@ -381,6 +381,9 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,\n> \t\t\t\t PUD_TYPE_TABLE)\n> #endif\n> \n> +#define pmd_large(pmd)\t\tpmd_sect(pmd)\n> +#define pud_large(pud)\t\tpud_sect(pud)\n> +\n> static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)\n> {\n> \t*pmdp = pmd;\n> diff --git a/include/linux/kasan.h b/include/linux/kasan.h\n> index a5c7046f26b4..7e13df1722c2 100644\n> --- a/include/linux/kasan.h\n> +++ b/include/linux/kasan.h\n> @@ -78,6 +78,8 @@ size_t kasan_metadata_size(struct kmem_cache *cache);\n> \n> bool kasan_save_enable_multi_shot(void);\n> void kasan_restore_multi_shot(bool enabled);\n> +int __meminit kasan_map_populate(unsigned long start, unsigned long end,\n> +\t\t\t\t int node);\n> \n> #else /* CONFIG_KASAN */\n> \n> diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c\n> index 554e4c0f23a2..57a973f05f63 100644\n> --- a/mm/kasan/kasan_init.c\n> +++ b/mm/kasan/kasan_init.c\n> @@ -197,3 +197,70 @@ void __init kasan_populate_zero_shadow(const void *shadow_start,\n> \t\tzero_p4d_populate(pgd, addr, next);\n> \t} while (pgd++, addr = next, addr != end);\n> }\n> +\n> +/* Creates mappings for kasan during early boot. The mapped memory is zeroed */\n> +int __meminit kasan_map_populate(unsigned long start, unsigned long end,\n> +\t\t\t\t int node)\n> +{\n> +\tunsigned long addr, pfn, next;\n> +\tunsigned long long size;\n> +\tpgd_t *pgd;\n> +\tp4d_t *p4d;\n> +\tpud_t *pud;\n> +\tpmd_t *pmd;\n> +\tpte_t *pte;\n> +\tint ret;\n> +\n> +\tret = vmemmap_populate(start, end, node);\n> +\t/*\n> +\t * We might have partially populated memory, so check for no entries,\n> +\t * and zero only those that actually exist.\n> +\t */\n> +\tfor (addr = start; addr < end; addr = next) {\n> +\t\tpgd = pgd_offset_k(addr);\n> +\t\tif (pgd_none(*pgd)) {\n> +\t\t\tnext = pgd_addr_end(addr, end);\n> +\t\t\tcontinue;\n> +\t\t}\n> +\n> +\t\tp4d = p4d_offset(pgd, addr);\n> +\t\tif (p4d_none(*p4d)) {\n> +\t\t\tnext = p4d_addr_end(addr, end);\n> +\t\t\tcontinue;\n> +\t\t}\n> +\n> +\t\tpud = pud_offset(p4d, addr);\n> +\t\tif (pud_none(*pud)) {\n> +\t\t\tnext = pud_addr_end(addr, end);\n> +\t\t\tcontinue;\n> +\t\t}\n> +\t\tif (pud_large(*pud)) {\n> +\t\t\t/* This is PUD size page */\n> +\t\t\tnext = pud_addr_end(addr, end);\n> +\t\t\tsize = PUD_SIZE;\n> +\t\t\tpfn = pud_pfn(*pud);\n> +\t\t} else {\n> +\t\t\tpmd = pmd_offset(pud, addr);\n> +\t\t\tif (pmd_none(*pmd)) {\n> +\t\t\t\tnext = pmd_addr_end(addr, end);\n> +\t\t\t\tcontinue;\n> +\t\t\t}\n> +\t\t\tif (pmd_large(*pmd)) {\n> +\t\t\t\t/* This is PMD size page */\n> +\t\t\t\tnext = pmd_addr_end(addr, end);\n> +\t\t\t\tsize = PMD_SIZE;\n> +\t\t\t\tpfn = pmd_pfn(*pmd);\n> +\t\t\t} else {\n> +\t\t\t\tpte = pte_offset_kernel(pmd, addr);\n> +\t\t\t\tnext = addr + PAGE_SIZE;\n> +\t\t\t\tif (pte_none(*pte))\n> +\t\t\t\t\tcontinue;\n> +\t\t\t\t/* This is base size page */\n> +\t\t\t\tsize = PAGE_SIZE;\n> +\t\t\t\tpfn = pte_pfn(*pte);\n> +\t\t\t}\n> +\t\t}\n> +\t\tmemset(phys_to_virt(PFN_PHYS(pfn)), 0, size);\n> +\t}\n> +\treturn ret;\n> +}\n> -- \n> 2.14.1\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 3y62584GCsz9t2M\n\tfor ;\n\tWed, 4 Oct 2017 01:50:20 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751975AbdJCOuT (ORCPT );\n\tTue, 3 Oct 2017 10:50:19 -0400","from foss.arm.com ([217.140.101.70]:49896 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751963AbdJCOuT (ORCPT );\n\tTue, 3 Oct 2017 10:50:19 -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 996971529;\n\tTue, 3 Oct 2017 07:50:18 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t162C03F53D; Tue, 3 Oct 2017 07:50:14 -0700 (PDT)"],"Date":"Tue, 3 Oct 2017 15:48:46 +0100","From":"Mark Rutland ","To":"Pavel Tatashin , will.deacon@arm.com,\n\tcatalin.marinas@arm.com","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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171003144845.GD4931@leverpostej>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170920201714.19817-10-pasha.tatashin@oracle.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1779051,"web_url":"http://patchwork.ozlabs.org/comment/1779051/","msgid":"<1e2dc0da-5eb8-3160-803a-262a3c506baf@oracle.com>","list_archive_url":null,"date":"2017-10-03T15:04:26","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Mark,\n\nI considered using a new *populate() function for shadow without using \nvmemmap_populate(), but that makes things unnecessary complicated: \nvmemmap_populate() has builtin:\n\n1. large page support\n2. device memory support\n3. node locality support\n4. several config based variants on different platforms\n\nAll of that will cause the code simply be duplicated on each platform \nif we want to support that in kasan.\n\nWe could limit ourselves to only supporting base pages in memory by \nusing something like vmemmap_populate_basepages(), but that is a step \nbackward. Kasan benefits from using large pages now, why remove it?\n\nSo, the solution I provide is walking page table right after memory is \nmapped. Since, we are using the actual page table, it is guaranteed that \nwe are not going to miss any mapped memory, and also it is in common \ncode, which makes things smaller and nicer.\n\nThank you,\nPasha\n\nOn 10/03/2017 10:48 AM, Mark Rutland wrote:\n> \n> I've given this a spin on arm64, and can confirm that it works.\n> \n> Given that this involes redundant walking of page tables, I still think\n> it'd be preferable to have some common *_populate() helper that took a\n> gfp argument, but I guess it's not the end of the world.\n> \n> I'll leave it to Will and Catalin to say whether they're happy with the\n> page table walking and the new p{u,m}d_large() helpers added to arm64.\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 3y62RV4BXZz9sRV\n\tfor ;\n\tWed, 4 Oct 2017 02:06:14 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751910AbdJCPGN (ORCPT );\n\tTue, 3 Oct 2017 11:06:13 -0400","from aserp1040.oracle.com ([141.146.126.69]:21238 \"EHLO\n\taserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751979AbdJCPGM (ORCPT\n\t); Tue, 3 Oct 2017 11:06:12 -0400","from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v93F4WJq005901\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:04:32 GMT","from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])\n\tby aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v93F4VMB014381\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Tue, 3 Oct 2017 15:04:31 GMT","from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])\n\tby userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v93F4TPY019989; \n\tTue, 3 Oct 2017 15:04:29 GMT","from [192.168.1.10] (/98.216.35.41)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Tue, 03 Oct 2017 08:04:29 -0700"],"Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Mark Rutland , will.deacon@arm.com,\n\tcatalin.marinas@arm.com","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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>","From":"Pasha Tatashin ","Message-ID":"<1e2dc0da-5eb8-3160-803a-262a3c506baf@oracle.com>","Date":"Tue, 3 Oct 2017 11:04:26 -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":"<20171003144845.GD4931@leverpostej>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Source-IP":"aserv0022.oracle.com [141.146.126.234]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783039,"web_url":"http://patchwork.ozlabs.org/comment/1783039/","msgid":"<20171009171337.GE30085@arm.com>","list_archive_url":null,"date":"2017-10-09T17:13:37","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote:\n> On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote:\n> > During early boot, kasan uses vmemmap_populate() to establish its shadow\n> > memory. But, that interface is intended for struct pages use.\n> > \n> > Because of the current project, vmemmap won't be zeroed during allocation,\n> > but kasan expects that memory to be zeroed. We are adding a new\n> > kasan_map_populate() function to resolve this difference.\n> \n> Thanks for putting this together.\n> \n> I've given this a spin on arm64, and can confirm that it works.\n> \n> Given that this involes redundant walking of page tables, I still think\n> it'd be preferable to have some common *_populate() helper that took a\n> gfp argument, but I guess it's not the end of the world.\n> \n> I'll leave it to Will and Catalin to say whether they're happy with the\n> page table walking and the new p{u,m}d_large() helpers added to arm64.\n\nTo be honest, it just looks completely backwards to me; we're walking the\npage tables we created earlier on so that we can figure out what needs to\nbe zeroed for KASAN. We already had that information before, hence my\npreference to allow propagation of GFP_FLAGs to vmemmap_alloc_block when\nit's needed. I know that's not popular for some reason, but is walking the\npage tables really better?\n\nWill\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 3y9mzj1CZKz9sPt\n\tfor ;\n\tTue, 10 Oct 2017 04:13:37 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754221AbdJIRNg (ORCPT );\n\tMon, 9 Oct 2017 13:13:36 -0400","from foss.arm.com ([217.140.101.70]:60918 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751636AbdJIRNf (ORCPT );\n\tMon, 9 Oct 2017 13:13:35 -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 3B9311529;\n\tMon, 9 Oct 2017 10:13:35 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t0BAB33F483; Mon, 9 Oct 2017 10:13:35 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid C5ED81AE1189; Mon, 9 Oct 2017 18:13:37 +0100 (BST)"],"Date":"Mon, 9 Oct 2017 18:13:37 +0100","From":"Will Deacon ","To":"Mark Rutland ","Cc":"Pavel Tatashin ,\n\tcatalin.marinas@arm.com, linux-kernel@vger.kernel.org,\n\tsparclinux@vger.kernel.org, linux-mm@kvack.org,\n\tlinuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, x86@kernel.org,\n\tkasan-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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tsteven.sistare@oracle.com, daniel.m.jordan@oracle.com,\n\tbob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009171337.GE30085@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171003144845.GD4931@leverpostej>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783099,"web_url":"http://patchwork.ozlabs.org/comment/1783099/","msgid":"","list_archive_url":null,"date":"2017-10-09T17:51:47","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Will,\n\nI can go back to that approach, if Michal OK with it. But, that would\nmean that I would need to touch every single architecture that\nimplements vmemmap_populate(), and also pass flags at least through\nthese functions on every architectures (some have more than one\ndecided by configs).:\n\nvmemmap_populate()\nvmemmap_populate_basepages()\nvmemmap_populate_hugepages()\nvmemmap_pte_populate()\n__vmemmap_alloc_block_buf()\nalloc_block_buf()\nvmemmap_alloc_block()\n\nIMO, while I understand that it looks strange that we must walk page\ntable after creating it, it is a better approach: more enclosed as it\neffects kasan only, and more universal as it is in common code. We are\nalso somewhat late in the review process, means we will need again to\nget ACKs from the maintainers of other arches.\n\nPavel\n\nOn Mon, Oct 9, 2017 at 1:13 PM, Will Deacon wrote:\n> On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote:\n>> On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote:\n>> > During early boot, kasan uses vmemmap_populate() to establish its shadow\n>> > memory. But, that interface is intended for struct pages use.\n>> >\n>> > Because of the current project, vmemmap won't be zeroed during allocation,\n>> > but kasan expects that memory to be zeroed. We are adding a new\n>> > kasan_map_populate() function to resolve this difference.\n>>\n>> Thanks for putting this together.\n>>\n>> I've given this a spin on arm64, and can confirm that it works.\n>>\n>> Given that this involes redundant walking of page tables, I still think\n>> it'd be preferable to have some common *_populate() helper that took a\n>> gfp argument, but I guess it's not the end of the world.\n>>\n>> I'll leave it to Will and Catalin to say whether they're happy with the\n>> page table walking and the new p{u,m}d_large() helpers added to arm64.\n>\n> To be honest, it just looks completely backwards to me; we're walking the\n> page tables we created earlier on so that we can figure out what needs to\n> be zeroed for KASAN. We already had that information before, hence my\n> preference to allow propagation of GFP_FLAGs to vmemmap_alloc_block when\n> it's needed. I know that's not popular for some reason, but is walking the\n> page tables really better?\n>\n> Will\n>\n> --\n> To unsubscribe, send a message with 'unsubscribe linux-mm' in\n> the body to majordomo@kvack.org. For more info on Linux MM,\n> see: http://www.linux-mm.org/ .\n> Don't email: email@kvack.org \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 3y9nr55G87z9tXs\n\tfor ;\n\tTue, 10 Oct 2017 04:52:05 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755071AbdJIRvw (ORCPT );\n\tMon, 9 Oct 2017 13:51:52 -0400","from aserp1040.oracle.com ([141.146.126.69]:38088 \"EHLO\n\taserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754770AbdJIRvu (ORCPT\n\t); Mon, 9 Oct 2017 13:51:50 -0400","from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v99Hpn3T024859\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 17:51:49 GMT","from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])\n\tby aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv99HpmV1029938\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 17:51:48 GMT","from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])\n\tby aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv99HpmwS023191; Mon, 9 Oct 2017 17:51:48 GMT","from mail-oi0-f51.google.com (/209.85.218.51)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Mon, 09 Oct 2017 10:51:47 -0700","by mail-oi0-f51.google.com with SMTP id m198so28697902oig.5;\n\tMon, 09 Oct 2017 10:51:47 -0700 (PDT)","by 10.74.174.131 with HTTP; Mon, 9 Oct 2017 10:51:47 -0700 (PDT)"],"X-Gm-Message-State":"AMCzsaVPLVJFWcNq+bG1y0Hjlqsyqif7nvjuW3GgXnql0K9BUZ1uBrnM\n\trra2oNlvR9XTWYmffT2tPBvMV9ogvvjGd0a2gg==","X-Google-Smtp-Source":"AOwi7QCZW+v6qunni2yqKR2Y6ILKJbMLF4Y3cEcswUL0X9HUH1DsscVupbc3TZtyoMBOne7s89/AnOFCGtAYCaUHBUg=","X-Received":"by 10.157.68.38 with SMTP id u35mr153948ote.415.1507571507502;\n\tMon, 09 Oct 2017 10:51:47 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171009171337.GE30085@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>","From":"Pavel Tatashin ","Date":"Mon, 9 Oct 2017 13:51:47 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Will Deacon ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tSteve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Content-Type":"text/plain; charset=\"UTF-8\"","X-Source-IP":"aserv0021.oracle.com [141.146.126.233]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783122,"web_url":"http://patchwork.ozlabs.org/comment/1783122/","msgid":"<20171009181433.wevxa447d4g6kdsj@dhcp22.suse.cz>","list_archive_url":null,"date":"2017-10-09T18:14:33","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":66979,"url":"http://patchwork.ozlabs.org/api/people/66979/","name":"Michal Hocko","email":"mhocko@kernel.org"},"content":"On Mon 09-10-17 13:51:47, Pavel Tatashin wrote:\n> Hi Will,\n> \n> I can go back to that approach, if Michal OK with it. But, that would\n> mean that I would need to touch every single architecture that\n> implements vmemmap_populate(), and also pass flags at least through\n> these functions on every architectures (some have more than one\n> decided by configs).:\n> \n> vmemmap_populate()\n> vmemmap_populate_basepages()\n> vmemmap_populate_hugepages()\n> vmemmap_pte_populate()\n> __vmemmap_alloc_block_buf()\n> alloc_block_buf()\n> vmemmap_alloc_block()\n> \n> IMO, while I understand that it looks strange that we must walk page\n> table after creating it, it is a better approach: more enclosed as it\n> effects kasan only, and more universal as it is in common code.\n\nWhile I understand that gfp mask approach might look better at first\nsight this is by no means a general purpose API so I would rather be\npragmatic and have a smaller code footprint than a more general\ninterface. Kasan is pretty much a special case and doing a one time\ninitialization 2 pass thing is imho acceptable. If this turns out to be\nimpractical in future then let's fix it up but right now I would rather\ngo a simpler path.","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 3y9pL66qsLz9t4b\n\tfor ;\n\tTue, 10 Oct 2017 05:14:38 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751834AbdJISOi (ORCPT );\n\tMon, 9 Oct 2017 14:14:38 -0400","from mx2.suse.de ([195.135.220.15]:50240 \"EHLO mx2.suse.de\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751170AbdJISOh (ORCPT );\n\tMon, 9 Oct 2017 14:14:37 -0400","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx2.suse.de (Postfix) with ESMTP id 11D30ABB3;\n\tMon, 9 Oct 2017 18:14:35 +0000 (UTC)"],"X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Mon, 9 Oct 2017 20:14:33 +0200","From":"Michal Hocko ","To":"Pavel Tatashin ","Cc":"Will Deacon ,\n\tMark Rutland , catalin.marinas@arm.com,\n\tlinux-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, ard.biesheuvel@linaro.org, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009181433.wevxa447d4g6kdsj@dhcp22.suse.cz>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170609 (1.8.3)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783128,"web_url":"http://patchwork.ozlabs.org/comment/1783128/","msgid":"<20171009182217.GC30828@arm.com>","list_archive_url":null,"date":"2017-10-09T18:22:17","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"Hi Pavel,\n\nOn Mon, Oct 09, 2017 at 01:51:47PM -0400, Pavel Tatashin wrote:\n> I can go back to that approach, if Michal OK with it. But, that would\n> mean that I would need to touch every single architecture that\n> implements vmemmap_populate(), and also pass flags at least through\n> these functions on every architectures (some have more than one\n> decided by configs).:\n> \n> vmemmap_populate()\n> vmemmap_populate_basepages()\n> vmemmap_populate_hugepages()\n> vmemmap_pte_populate()\n> __vmemmap_alloc_block_buf()\n> alloc_block_buf()\n> vmemmap_alloc_block()\n\nAs an interim step, why not introduce something like\nvmemmap_alloc_block_flags and make the page-table walking opt-out for\narchitectures that don't want it? Then we can just pass __GFP_ZERO from\nour vmemmap_populate where necessary and other architectures can do the\npage-table walking dance if they prefer.\n\n> IMO, while I understand that it looks strange that we must walk page\n> table after creating it, it is a better approach: more enclosed as it\n> effects kasan only, and more universal as it is in common code.\n\nI don't buy the more universal aspect, but I appreciate it's subjective.\nFrankly, I'd just sooner not have core code walking early page tables if\nit can be avoided, and it doesn't look hard to avoid it in this case.\nThe fact that you're having to add pmd_large and pud_large, which are\notherwise unused in mm/, is an indication that this isn't quite right imo.\n\nWill\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 3y9pW06jgfz9sRm\n\tfor ;\n\tTue, 10 Oct 2017 05:22:17 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754772AbdJISWQ (ORCPT );\n\tMon, 9 Oct 2017 14:22:16 -0400","from foss.arm.com ([217.140.101.70]:33584 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754474AbdJISWP (ORCPT );\n\tMon, 9 Oct 2017 14:22: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 6C1C61596;\n\tMon, 9 Oct 2017 11:22:15 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t3BB6C3F483; Mon, 9 Oct 2017 11:22:15 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid 017141AE1189; Mon, 9 Oct 2017 19:22:17 +0100 (BST)"],"Date":"Mon, 9 Oct 2017 19:22:17 +0100","From":"Will Deacon ","To":"Pavel Tatashin ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tSteve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009182217.GC30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783143,"web_url":"http://patchwork.ozlabs.org/comment/1783143/","msgid":"","list_archive_url":null,"date":"2017-10-09T18:42:32","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Will,\n\nIn addition to what Michal wrote:\n\n> As an interim step, why not introduce something like\n> vmemmap_alloc_block_flags and make the page-table walking opt-out for\n> architectures that don't want it? Then we can just pass __GFP_ZERO from\n> our vmemmap_populate where necessary and other architectures can do the\n> page-table walking dance if they prefer.\n\nI do not see the benefit, implementing this approach means that we\nwould need to implement two table walks instead of one: one for x86,\nanother for ARM, as these two architectures support kasan. Also, this\nwould become a requirement for any future architecture that want to\nadd kasan support to add this page table walk implementation.\n\n>> IMO, while I understand that it looks strange that we must walk page\n>> table after creating it, it is a better approach: more enclosed as it\n>> effects kasan only, and more universal as it is in common code.\n>\n> I don't buy the more universal aspect, but I appreciate it's subjective.\n> Frankly, I'd just sooner not have core code walking early page tables if\n> it can be avoided, and it doesn't look hard to avoid it in this case.\n> The fact that you're having to add pmd_large and pud_large, which are\n> otherwise unused in mm/, is an indication that this isn't quite right imo.\n\n 28 +#define pmd_large(pmd) pmd_sect(pmd)\n 29 +#define pud_large(pud) pud_sect(pud)\n\nit is just naming difference, ARM64 calls them pmd_sect, common mm and\nother arches call them\npmd_large/pud_large. Even the ARM has these defines in\n\narm/include/asm/pgtable-3level.h\narm/include/asm/pgtable-2level.h\n\nPavel\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 3y9pyR6yYBz9sRq\n\tfor ;\n\tTue, 10 Oct 2017 05:42:39 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754269AbdJISmj (ORCPT );\n\tMon, 9 Oct 2017 14:42:39 -0400","from userp1040.oracle.com ([156.151.31.81]:35478 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751072AbdJISmi (ORCPT\n\t); Mon, 9 Oct 2017 14:42:38 -0400","from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v99IgZRZ026777\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 18:42:35 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v99IgYME015845\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 18:42:35 GMT","from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v99IgYmt018195; \n\tMon, 9 Oct 2017 18:42:34 GMT","from mail-oi0-f53.google.com (/209.85.218.53)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Mon, 09 Oct 2017 11:42:34 -0700","by mail-oi0-f53.google.com with SMTP id v132so21952031oie.1;\n\tMon, 09 Oct 2017 11:42:34 -0700 (PDT)","by 10.74.134.202 with HTTP; Mon, 9 Oct 2017 11:42:32 -0700 (PDT)"],"X-Gm-Message-State":"AMCzsaVY0mtziVfpa9Gud/BjndaRUkoVfvKRdhss+aPbjX7ec1T7Yy2A\n\t4Ds6hICy2N+wnt7oCBvT2PFpOicJTriHMKmipQ==","X-Google-Smtp-Source":"AOwi7QAmvts5INpF5QqWfaPYd7gD06+8pgGhJbb/deSRUzY8rq3tDxSeb5nGbuyOwzhLlLylqM9AuIQsyBZeOZCnl3w=","X-Received":"by 10.202.75.66 with SMTP id y63mr5359639oia.62.1507574553803;\n\tMon, 09 Oct 2017 11:42:33 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171009182217.GC30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>","From":"Pavel Tatashin ","Date":"Mon, 9 Oct 2017 14:42:32 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Will Deacon ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tSteve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Content-Type":"text/plain; charset=\"UTF-8\"","X-Source-IP":"aserv0021.oracle.com [141.146.126.233]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783148,"web_url":"http://patchwork.ozlabs.org/comment/1783148/","msgid":"<20171009184828.GD30828@arm.com>","list_archive_url":null,"date":"2017-10-09T18:48:29","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"On Mon, Oct 09, 2017 at 08:14:33PM +0200, Michal Hocko wrote:\n> On Mon 09-10-17 13:51:47, Pavel Tatashin wrote:\n> > I can go back to that approach, if Michal OK with it. But, that would\n> > mean that I would need to touch every single architecture that\n> > implements vmemmap_populate(), and also pass flags at least through\n> > these functions on every architectures (some have more than one\n> > decided by configs).:\n> > \n> > vmemmap_populate()\n> > vmemmap_populate_basepages()\n> > vmemmap_populate_hugepages()\n> > vmemmap_pte_populate()\n> > __vmemmap_alloc_block_buf()\n> > alloc_block_buf()\n> > vmemmap_alloc_block()\n> > \n> > IMO, while I understand that it looks strange that we must walk page\n> > table after creating it, it is a better approach: more enclosed as it\n> > effects kasan only, and more universal as it is in common code.\n> \n> While I understand that gfp mask approach might look better at first\n> sight this is by no means a general purpose API so I would rather be\n> pragmatic and have a smaller code footprint than a more general\n> interface. Kasan is pretty much a special case and doing a one time\n> initialization 2 pass thing is imho acceptable. If this turns out to be\n> impractical in future then let's fix it up but right now I would rather\n> go a simpler path.\n\nI think the simpler path for arm64 is really to say when we want the memory\nzeroing as opposed to exposing pmd_large/pud_large macros. Those are likely\nto grow more users too, but are difficult to use correctly as we have things\nlike contiguous ptes that map to a granule smaller than a pmd.\n\nI proposed an alternative solution to Pavel already, but it could be made\nless general purpose by marking the function __meminit and only having it\ndo anything if KASAN is compiled in.\n\nWill\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 3y9q593WkDz9sRq\n\tfor ;\n\tTue, 10 Oct 2017 05:48:29 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755153AbdJISs2 (ORCPT );\n\tMon, 9 Oct 2017 14:48:28 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:34084 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754085AbdJISs1 (ORCPT );\n\tMon, 9 Oct 2017 14:48:27 -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 AC8761529;\n\tMon, 9 Oct 2017 11:48:26 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t7C3183F483; Mon, 9 Oct 2017 11:48:26 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid 474751AE034E; Mon, 9 Oct 2017 19:48:29 +0100 (BST)"],"Date":"Mon, 9 Oct 2017 19:48:29 +0100","From":"Will Deacon ","To":"Michal Hocko ","Cc":"Pavel Tatashin ,\n\tMark Rutland , catalin.marinas@arm.com,\n\tlinux-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, ard.biesheuvel@linaro.org, sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009184828.GD30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009181433.wevxa447d4g6kdsj@dhcp22.suse.cz>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171009181433.wevxa447d4g6kdsj@dhcp22.suse.cz>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783149,"web_url":"http://patchwork.ozlabs.org/comment/1783149/","msgid":"<20171009184834.GE30828@arm.com>","list_archive_url":null,"date":"2017-10-09T18:48:34","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"On Mon, Oct 09, 2017 at 02:42:32PM -0400, Pavel Tatashin wrote:\n> Hi Will,\n> \n> In addition to what Michal wrote:\n> \n> > As an interim step, why not introduce something like\n> > vmemmap_alloc_block_flags and make the page-table walking opt-out for\n> > architectures that don't want it? Then we can just pass __GFP_ZERO from\n> > our vmemmap_populate where necessary and other architectures can do the\n> > page-table walking dance if they prefer.\n> \n> I do not see the benefit, implementing this approach means that we\n> would need to implement two table walks instead of one: one for x86,\n> another for ARM, as these two architectures support kasan. Also, this\n> would become a requirement for any future architecture that want to\n> add kasan support to add this page table walk implementation.\n\nWe have two table walks even with your patch series applied afaict: one in\nour definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one\nin the core code.\n\n> >> IMO, while I understand that it looks strange that we must walk page\n> >> table after creating it, it is a better approach: more enclosed as it\n> >> effects kasan only, and more universal as it is in common code.\n> >\n> > I don't buy the more universal aspect, but I appreciate it's subjective.\n> > Frankly, I'd just sooner not have core code walking early page tables if\n> > it can be avoided, and it doesn't look hard to avoid it in this case.\n> > The fact that you're having to add pmd_large and pud_large, which are\n> > otherwise unused in mm/, is an indication that this isn't quite right imo.\n> \n> 28 +#define pmd_large(pmd) pmd_sect(pmd)\n> 29 +#define pud_large(pud) pud_sect(pud)\n> \n> it is just naming difference, ARM64 calls them pmd_sect, common mm and\n> other arches call them\n> pmd_large/pud_large. Even the ARM has these defines in\n> \n> arm/include/asm/pgtable-3level.h\n> arm/include/asm/pgtable-2level.h\n\nMy worry is that these are actually highly arch-specific, but will likely\ngrow more users in mm/ that assume things for all architectures that aren't\nnecessarily valid.\n\nWill\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 3y9q5T4wHkz9sRq\n\tfor ;\n\tTue, 10 Oct 2017 05:48:45 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755310AbdJISse (ORCPT );\n\tMon, 9 Oct 2017 14:48:34 -0400","from foss.arm.com ([217.140.101.70]:34136 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755290AbdJISsc (ORCPT );\n\tMon, 9 Oct 2017 14:48:32 -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 27ECB1596;\n\tMon, 9 Oct 2017 11:48:32 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\tED79F3F483; Mon, 9 Oct 2017 11:48:31 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid BB4151AE034E; Mon, 9 Oct 2017 19:48:34 +0100 (BST)"],"Date":"Mon, 9 Oct 2017 19:48:34 +0100","From":"Will Deacon ","To":"Pavel Tatashin ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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\tsam@ravnborg.org, mgorman@techsingularity.net,\n\tSteve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009184834.GE30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783158,"web_url":"http://patchwork.ozlabs.org/comment/1783158/","msgid":"","list_archive_url":null,"date":"2017-10-09T18:59:09","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":"Hi Will,\n\n> We have two table walks even with your patch series applied afaict: one in\n> our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one\n> in the core code.\n\nI meant to say implementing two new page table walkers, not at runtime.\n\n> My worry is that these are actually highly arch-specific, but will likely\n> grow more users in mm/ that assume things for all architectures that aren't\n> necessarily valid.\n\nI see, how about moving new kasan_map_populate() implementation into\narch dependent code:\n\narch/x86/mm/kasan_init_64.c\narch/arm64/mm/kasan_init.c\n\nThis way we won't need to add pmd_large()/pud_large() macros for arm64?\n\nPavel\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 3y9qKc6MXqz9t3Z\n\tfor ;\n\tTue, 10 Oct 2017 05:59:16 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754865AbdJIS7P (ORCPT );\n\tMon, 9 Oct 2017 14:59:15 -0400","from userp1040.oracle.com ([156.151.31.81]:44808 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754861AbdJIS7O (ORCPT\n\t); Mon, 9 Oct 2017 14:59:14 -0400","from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v99IxB0U014356\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 18:59:11 GMT","from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])\n\tby aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv99IxAjH028372\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 18:59:10 GMT","from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17])\n\tby aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv99IxApV000745; Mon, 9 Oct 2017 18:59:10 GMT","from mail-oi0-f51.google.com (/209.85.218.51)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Mon, 09 Oct 2017 11:59:10 -0700","by mail-oi0-f51.google.com with SMTP id v9so29212783oif.13;\n\tMon, 09 Oct 2017 11:59:09 -0700 (PDT)","by 10.74.134.202 with HTTP; Mon, 9 Oct 2017 11:59:09 -0700 (PDT)"],"X-Gm-Message-State":"AMCzsaWoVuJGPywmxtu73c3E3F0aLSvsny1a5MX7J7WMLoapXJq1sv0t\n\t2tMTCBwKnriIwBcInr/3s6KkS5iFBOSdvODZ+A==","X-Google-Smtp-Source":"AOwi7QBbv3UbrGp+zu8SCa9ZMwV6fB0pqEKVPg3lVmIttKszSFJOV1KglWS5+T/lxybbvtyS0Zi8ipCWdv8kMLP6D6c=","X-Received":"by 10.202.75.66 with SMTP id y63mr5373448oia.62.1507575549474;\n\tMon, 09 Oct 2017 11:59:09 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171009184834.GE30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>\n\t\n\t<20171009184834.GE30828@arm.com>","From":"Pavel Tatashin ","Date":"Mon, 9 Oct 2017 14:59:09 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Will Deacon ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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,\n\tArd Biesheuvel , sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Content-Type":"text/plain; charset=\"UTF-8\"","X-Source-IP":"aserv0022.oracle.com [141.146.126.234]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783165,"web_url":"http://patchwork.ozlabs.org/comment/1783165/","msgid":"<20171009190213.GF30828@arm.com>","list_archive_url":null,"date":"2017-10-09T19:02:13","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":7916,"url":"http://patchwork.ozlabs.org/api/people/7916/","name":"Will Deacon","email":"will.deacon@arm.com"},"content":"Hi Pavel,\n\nOn Mon, Oct 09, 2017 at 02:59:09PM -0400, Pavel Tatashin wrote:\n> > We have two table walks even with your patch series applied afaict: one in\n> > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one\n> > in the core code.\n> \n> I meant to say implementing two new page table walkers, not at runtime.\n\nOk, but I'm still missing why you think that is needed. What would be the\nsecond page table walker that needs implementing?\n\n> > My worry is that these are actually highly arch-specific, but will likely\n> > grow more users in mm/ that assume things for all architectures that aren't\n> > necessarily valid.\n> \n> I see, how about moving new kasan_map_populate() implementation into\n> arch dependent code:\n> \n> arch/x86/mm/kasan_init_64.c\n> arch/arm64/mm/kasan_init.c\n> \n> This way we won't need to add pmd_large()/pud_large() macros for arm64?\n\nI guess we could implement that on arm64 using our current vmemmap_populate\nlogic and an explicit memset.\n\nWill\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 3y9qP13NR7z9t3Z\n\tfor ;\n\tTue, 10 Oct 2017 06:02:13 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755189AbdJITCM (ORCPT );\n\tMon, 9 Oct 2017 15:02:12 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:34338 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755070AbdJITCL (ORCPT );\n\tMon, 9 Oct 2017 15:02:11 -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 17EDB1529;\n\tMon, 9 Oct 2017 12:02:11 -0700 (PDT)","from edgewater-inn.cambridge.arm.com\n\t(usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\tDBED93F59C; Mon, 9 Oct 2017 12:02:10 -0700 (PDT)","by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000)\n\tid A79031AE034E; Mon, 9 Oct 2017 20:02:13 +0100 (BST)"],"Date":"Mon, 9 Oct 2017 20:02:13 +0100","From":"Will Deacon ","To":"Pavel Tatashin ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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,\n\tArd Biesheuvel , sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","Message-ID":"<20171009190213.GF30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>\n\t\n\t<20171009184834.GE30828@arm.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}},{"id":1783170,"web_url":"http://patchwork.ozlabs.org/comment/1783170/","msgid":"","list_archive_url":null,"date":"2017-10-09T19:07:01","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":">\n> Ok, but I'm still missing why you think that is needed. What would be the\n> second page table walker that needs implementing?\n>\n> I guess we could implement that on arm64 using our current vmemmap_populate\n> logic and an explicit memset.\n>\n\nHi Will,\n\nWhat do you mean by explicit memset()? We can't simply memset() from\nstart to end without doing the page table walk, because at the time\nkasan is calling vmemmap_populate() we have a tmp_pg_dir instead of\nswapper_pg_dir.\n\nWe could do the explicit memset() after\ncpu_replace_ttbr1(lm_alias(swapper_pg_dir)); but again, this was in\none of my previous implementations, and I was asked to replace that.\n\nPavel\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 3y9qVw4fBxz9t3Z\n\tfor ;\n\tTue, 10 Oct 2017 06:07:20 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754509AbdJITHG (ORCPT );\n\tMon, 9 Oct 2017 15:07:06 -0400","from userp1040.oracle.com ([156.151.31.81]:49932 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754262AbdJITHF (ORCPT\n\t); Mon, 9 Oct 2017 15:07:05 -0400","from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v99J73Xf024215\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 19:07:04 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v99J730r023381\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 19:07:03 GMT","from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv99J73lP001338; Mon, 9 Oct 2017 19:07:03 GMT","from mail-oi0-f50.google.com (/209.85.218.50)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Mon, 09 Oct 2017 12:07:03 -0700","by mail-oi0-f50.google.com with SMTP id w197so36847168oif.6;\n\tMon, 09 Oct 2017 12:07:03 -0700 (PDT)","by 10.74.134.202 with HTTP; Mon, 9 Oct 2017 12:07:01 -0700 (PDT)"],"X-Gm-Message-State":"AMCzsaXCS/AJ4WE+n++PuDeOCNzfrD2vguxHZPJLi3dc2FZT4N/sC4Tw\n\tdo1YXWOkpDGzLx6LdA9IYE5vwbqzAEvtWNEkow==","X-Google-Smtp-Source":"AOwi7QCOyeh2OIGt4fEQC1R6hszHm6XzHLN+NdvqkBx8najejoVkUwQ8cxjMOzgQXTns7hIiWjLRN1HtHoYOwgEOqzE=","X-Received":"by 10.157.66.167 with SMTP id r36mr216866ote.335.1507576022510; \n\tMon, 09 Oct 2017 12:07:02 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171009190213.GF30828@arm.com>","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>\n\t\n\t<20171009184834.GE30828@arm.com>\n\t\n\t<20171009190213.GF30828@arm.com>","From":"Pavel Tatashin ","Date":"Mon, 9 Oct 2017 15:07:01 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Will Deacon ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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,\n\tArd Biesheuvel , sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Content-Type":"text/plain; charset=\"UTF-8\"","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":1783202,"web_url":"http://patchwork.ozlabs.org/comment/1783202/","msgid":"","list_archive_url":null,"date":"2017-10-09T19:57:38","subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","submitter":{"id":71010,"url":"http://patchwork.ozlabs.org/api/people/71010/","name":"Pavel Tatashin","email":"pasha.tatashin@oracle.com"},"content":">> I guess we could implement that on arm64 using our current vmemmap_populate\n>> logic and an explicit memset.\n\nHi Will,\n\nI will send out a new patch series with x86/arm64 versions of\nkasan_map_populate(), so you could take a look if this is something\nthat is acceptable.\n\nThank you,\nPavel\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 3y9rd4204qz9s7c\n\tfor ;\n\tTue, 10 Oct 2017 06:57:44 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754203AbdJIT5n (ORCPT );\n\tMon, 9 Oct 2017 15:57:43 -0400","from aserp1040.oracle.com ([141.146.126.69]:42040 \"EHLO\n\taserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752001AbdJIT5m (ORCPT\n\t); Mon, 9 Oct 2017 15:57:42 -0400","from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])\n\tby aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v99JveRE021181\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 19:57:40 GMT","from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])\n\tby aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id\n\tv99JvdpG007031\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Mon, 9 Oct 2017 19:57:39 GMT","from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25])\n\tby aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv99JvdB3010450; Mon, 9 Oct 2017 19:57:39 GMT","from mail-oi0-f45.google.com (/209.85.218.45)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Mon, 09 Oct 2017 12:57:39 -0700","by mail-oi0-f45.google.com with SMTP id n82so34408611oig.3;\n\tMon, 09 Oct 2017 12:57:39 -0700 (PDT)","by 10.74.134.202 with HTTP; Mon, 9 Oct 2017 12:57:38 -0700 (PDT)"],"X-Gm-Message-State":"AMCzsaUjxOwXxxa5GHrn7VKejuNADVjjszOnpYGxD7kfHRw1htx+zPkD\n\tBF6FGbodRxiI3nIkUmvzehYxjE8eF43ImCFCxQ==","X-Google-Smtp-Source":"AOwi7QASBBYjUBtnhxINqZdUSZxUFApfbnAaJ9LOINp0L1IzWE+Jlsso2HDk6mKj0YYL28gfDkae4YMMFccedmmJcG0=","X-Received":"by 10.202.213.129 with SMTP id m123mr5484383oig.79.1507579058676;\n\tMon, 09 Oct 2017 12:57:38 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170920201714.19817-1-pasha.tatashin@oracle.com>\n\t<20170920201714.19817-10-pasha.tatashin@oracle.com>\n\t<20171003144845.GD4931@leverpostej>\n\t<20171009171337.GE30085@arm.com>\n\t\n\t<20171009182217.GC30828@arm.com>\n\t\n\t<20171009184834.GE30828@arm.com>\n\t\n\t<20171009190213.GF30828@arm.com>\n\t","From":"Pavel Tatashin ","Date":"Mon, 9 Oct 2017 15:57:38 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function","To":"Will Deacon ","Cc":"Mark Rutland , catalin.marinas@arm.com,\n\tlinux-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,\n\tArd Biesheuvel , sam@ravnborg.org,\n\tmgorman@techsingularity.net, Steve Sistare ,\n\tdaniel.m.jordan@oracle.com, bob.picco@oracle.com","Content-Type":"text/plain; charset=\"UTF-8\"","X-Source-IP":"aserv0022.oracle.com [141.146.126.234]","Sender":"sparclinux-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"sparclinux@vger.kernel.org"}}]