From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199]) by kanga.kvack.org (Postfix) with ESMTP id 62DE96B0268 for ; Mon, 9 Oct 2017 14:14:39 -0400 (EDT) Received: by mail-pf0-f199.google.com with SMTP id e26so49020482pfd.4 for ; Mon, 09 Oct 2017 11:14:39 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id z73si6826286pgz.60.2017.10.09.11.14.38 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 09 Oct 2017 11:14:38 -0700 (PDT) Date: Mon, 9 Oct 2017 20:14:33 +0200 From: Michal Hocko 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> <20170920201714.19817-10-pasha.tatashin@oracle.com> <20171003144845.GD4931@leverpostej> <20171009171337.GE30085@arm.com> 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: Will Deacon , Mark Rutland , catalin.marinas@arm.com, 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, ard.biesheuvel@linaro.org, sam@ravnborg.org, mgorman@techsingularity.net, Steve Sistare , daniel.m.jordan@oracle.com, bob.picco@oracle.com On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > Hi Will, > > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these functions on every architectures (some have more than one > decided by configs).: > > vmemmap_populate() > vmemmap_populate_basepages() > vmemmap_populate_hugepages() > vmemmap_pte_populate() > __vmemmap_alloc_block_buf() > alloc_block_buf() > vmemmap_alloc_block() > > IMO, while I understand that it looks strange that we must walk page > table after creating it, it is a better approach: more enclosed as it > effects kasan only, and more universal as it is in common code. While I understand that gfp mask approach might look better at first sight this is by no means a general purpose API so I would rather be pragmatic and have a smaller code footprint than a more general interface. Kasan is pretty much a special case and doing a one time initialization 2 pass thing is imho acceptable. If this turns out to be impractical in future then let's fix it up but right now I would rather go a simpler path. -- Michal Hocko SUSE Labs -- 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