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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 3EAFAC4363D for ; Wed, 14 Oct 2020 19:12:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B94E32222C for ; Wed, 14 Oct 2020 19:12:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QoXiKIK/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B94E32222C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3E42C6B0070; Wed, 14 Oct 2020 15:12:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BB32900002; Wed, 14 Oct 2020 15:12:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AA616B0072; Wed, 14 Oct 2020 15:12:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id F203A6B0070 for ; Wed, 14 Oct 2020 15:12:51 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 84682181AC9CC for ; Wed, 14 Oct 2020 19:12:51 +0000 (UTC) X-FDA: 77371478142.21.house47_49062282720e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 5CA5E180442C7 for ; Wed, 14 Oct 2020 19:12:51 +0000 (UTC) X-HE-Tag: house47_49062282720e X-Filterd-Recvd-Size: 6927 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Wed, 14 Oct 2020 19:12:50 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id m128so336265oig.7 for ; Wed, 14 Oct 2020 12:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZeIyBZH1DlMazqL3WPQEWDzdrz72p5JAZek4MEGZox0=; b=QoXiKIK/b6kRcW6PeofIscaKrIR52aRKjK4qvKq8aq8FfwkJyBRTC0ZEcPvRccLrhQ u+FpbklPzt4CeRTorbjIFdSCfLOkMOflGkHc8h4q1COYv3UEi+R3nUAjbveX5cXR2V+p wCE7CgcPvaOdVfjawROqxRJ7rqWpmE5mbP3mPrTxWm8PrpDc5KuzQKTsrTsz1O27Csog KFs0ESSPZ2TcgNQ0ZsN3PYi4798fLNTOv9c63rkDZFfqUNSPRyVsOvlzYgs40HlLtSFs kgRH3yS4GXzfnqQaLDPtJF1yLg233FCVeq6yhxM4LWENkAIt6KpBXFiQVKjApYHQqAIV s10A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZeIyBZH1DlMazqL3WPQEWDzdrz72p5JAZek4MEGZox0=; b=DcJLZS6oFGDAL+Btd+NefP6YXG8Y04+hAI9QVIWmuFf2WxpqvlYugpjSYmak/Q2QyM 39gR/Vg08m9NeSqZmNqk7H1MeTjClVgddjNrzjK9/yRz2ewuKqbIgOxuI1C5lyxDnpYe UtZCRkVsVBupylvbqJFsoc90QvW8UAM41CTIKt89MRtStlCDvbuLWf79EED2jrVT9qgx 7zGUS7l7nruAWA8SmiBMvI6PCoWAkeHAsps7tUqhpA1+wlZKv+GzgoYyma9qt9oceXpS /tWilHdLQOksEXT0T6b7Pnwg3RjhcFmw9DLeV6QatifSrti6Aua8Ej2Kur5cq+RRsojb 8HcQ== X-Gm-Message-State: AOAM533ZOKXJtQ1YOKmEoec85KjPOe6Eb11niS0NVQockjrrGpGhDKOA j7A5xJpA3xj4bXnjP6wlpg9epaHy1Qh+VqKsoo0fig== X-Google-Smtp-Source: ABdhPJxI0rp8pxtj3cUByNFiFU6rolm7IayLQiq14hVoYtiHEk/OXGhVI9evgkFYJ4/Vus6tK95a5TvDzRsE+g22i1M= X-Received: by 2002:aca:3d07:: with SMTP id k7mr537643oia.172.1602702769984; Wed, 14 Oct 2020 12:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200929140226.GB53442@C02TD0UTHF1T.local> <20201001175716.GA89689@C02TD0UTHF1T.local> <20201008104501.GB72325@C02TD0UTHF1T.local> In-Reply-To: <20201008104501.GB72325@C02TD0UTHF1T.local> From: Marco Elver Date: Wed, 14 Oct 2020 21:12:37 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Mark Rutland Cc: Alexander Potapenko , Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" 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 Thu, 8 Oct 2020 at 12:45, Mark Rutland wrote: > On Thu, Oct 08, 2020 at 11:40:52AM +0200, Marco Elver wrote: > > On Thu, 1 Oct 2020 at 19:58, Mark Rutland wrote: > > [...] > > > > > If you need virt_to_page() to work, the address has to be part of the > > > > > linear/direct map. > > [...] > > > > > > What's the underlying requirement here? Is this a performance concern, > > > codegen/codesize, or something else? > > > > It used to be performance, since is_kfence_address() is used in the > > fast path. However, with some further tweaks we just did to > > is_kfence_address(), our benchmarks show a pointer load can be > > tolerated. > > Great! > > I reckon that this is something we can optimize in futue if necessary > (e.g. with some form of code-patching for immediate values), but it's > good to have a starting point that works everywhere! > > [...] > > > > I'm not too worried about allocating this dynamically, but: > > > > > > * The arch code needs to set up the translation tables for this, as we > > > cannot safely change the mapping granularity live. > > > > > > * As above I'm fairly certain x86 needs to use a carevout from the > > > linear map to function correctly anyhow, so we should follow the same > > > approach for both arm64 and x86. That might be a static carevout that > > > we figure out the aliasing for, or something entirely dynamic. > > > > We're going with dynamically allocating the pool (for both x86 and > > arm64), since any benefits we used to measure from the static pool are > > no longer measurable (after removing a branch from > > is_kfence_address()). It should hopefully simplify a lot of things, > > given all the caveats that you pointed out. > > > > For arm64, the only thing left then is to fix up the case if the > > linear map is not forced to page granularity. > > The simplest way to do this is to modify arm64's arch_add_memory() to > force the entire linear map to be mapped at page granularity when KFENCE > is enabled, something like: > [...] > > ... and I given that RODATA_FULL_DEFAULT_ENABLED is the default, I > suspect it's not worth trying to only for that for the KFENCE region > unless someone complains. We've got most of this sorted now for v5 -- thank you! The only thing we're wondering now, is if there are any corner cases with using memblock_alloc'd memory for the KFENCE pool? (We'd like to avoid page alloc's MAX_ORDER limit.) We have a version that passes tests on x86 and arm64, but checking just in case. :-) Thanks, -- Marco