From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD328C4727C for ; Tue, 29 Sep 2020 13:54:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 17B1220848 for ; Tue, 29 Sep 2020 13:54:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 17B1220848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 78A71900003; Tue, 29 Sep 2020 09:54:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73A9B8E0001; Tue, 29 Sep 2020 09:54:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62924900003; Tue, 29 Sep 2020 09:54:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 4E3CD8E0001 for ; Tue, 29 Sep 2020 09:54:13 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0A639181AE866 for ; Tue, 29 Sep 2020 13:54:13 +0000 (UTC) X-FDA: 77316243186.13.seat71_36082322718a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id DF16618140B67 for ; Tue, 29 Sep 2020 13:54:12 +0000 (UTC) X-HE-Tag: seat71_36082322718a X-Filterd-Recvd-Size: 4861 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Sep 2020 13:54:12 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4BCA931B; Tue, 29 Sep 2020 06:54:11 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.51.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 055C73F6CF; Tue, 29 Sep 2020 06:54:03 -0700 (PDT) Date: Tue, 29 Sep 2020 14:53:55 +0100 From: Mark Rutland To: Marco Elver Cc: Will Deacon , Alexander Potapenko , Andrew Morton , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitriy Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , the arch/x86 maintainers , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 Message-ID: <20200929135355.GA53442@C02TD0UTHF1T.local> References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200921174357.GB3141@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 22, 2020 at 11:56:26AM +0200, Marco Elver wrote: > On Mon, 21 Sep 2020 at 19:44, Will Deacon wrote: > [...] > > > > > > For ARM64, we would like to solicit feedback on what the best option is > > > > > > to obtain a constant address for __kfence_pool. One option is to declare > > > > > > a memory range in the memory layout to be dedicated to KFENCE (like is > > > > > > done for KASAN), however, it is unclear if this is the best available > > > > > > option. We would like to avoid touching the memory layout. > > > > > > > > > > Sorry for the delay on this. > > > > > > > > NP, thanks for looking! > > > > > > > > > Given that the pool is relatively small (i.e. when compared with our virtual > > > > > address space), dedicating an area of virtual space sounds like it makes > > > > > the most sense here. How early do you need it to be available? > > > > > > > > Yes, having a dedicated address sounds good. > > > > We're inserting kfence_init() into start_kernel() after timekeeping_init(). > > > > So way after mm_init(), if that matters. > > > > > > The question is though, how big should that dedicated area be? > > > Right now KFENCE_NUM_OBJECTS can be up to 16383 (which makes the pool > > > size 64MB), but this number actually comes from the limitation on > > > static objects, so we might want to increase that number on arm64. > > > > What happens on x86 and why would we do something different? > > On x86 we just do `char __kfence_pool[KFENCE_POOL_SIZE] ...;` to > statically allocate the pool. On arm64 this doesn't seem to work > because static memory doesn't have struct pages? Are you using virt_to_page() directly on that statically-allocated __kfence_pool? If so you'll need to use lm_alias() if so, as is done in mm/kasan/init.c. Anything statically allocated is part of the kernel image address range rather than the linear/direct map, and doesn't have a valid virt addr, but its linear map alias does. If you enable CONFIG_DEBUG_VIRTUAL you should get warnings if missing lm_alias() calls. Thanks, Mark.