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,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 62186C4727E for ; Tue, 22 Sep 2020 09:56:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DA8F8238A1 for ; Tue, 22 Sep 2020 09:56:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Js+n82cx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA8F8238A1 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 2C0B1900044; Tue, 22 Sep 2020 05:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24867900036; Tue, 22 Sep 2020 05:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11003900044; Tue, 22 Sep 2020 05:56:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id EA4A3900036 for ; Tue, 22 Sep 2020 05:56:40 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9BF00EFBE for ; Tue, 22 Sep 2020 09:56:40 +0000 (UTC) X-FDA: 77290242960.17.earth51_200e2702714c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 51966180D0180 for ; Tue, 22 Sep 2020 09:56:40 +0000 (UTC) X-HE-Tag: earth51_200e2702714c X-Filterd-Recvd-Size: 5691 Received: from mail-oo1-f65.google.com (mail-oo1-f65.google.com [209.85.161.65]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 09:56:39 +0000 (UTC) Received: by mail-oo1-f65.google.com with SMTP id h8so3984833ooc.12 for ; Tue, 22 Sep 2020 02:56:39 -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=eVKPH13bJ8Pw64uEwVW7kgXl7zM95RCC9p4HQ/Nmkxc=; b=Js+n82cxs9o4HmRZr9CSN2h8XlIXga5zCjRQQqMjoMjBNYDb9Zk1jyZ/cWAe9CjE6T wtxq2Eg6Yuo97NcCeFMioAuTWhT5+Vn7v1Iky4fQzsqDx/VwqbybIZT2ofCISFETGzSF ysY/mG8RLF+R81492AgLpvFlPxr5OSr8vPEeR8W7MXuxpJAWHVmYJQzldLfS0R7qo0rS 5cZu+Bun3id+qqZurrj34eezcYweU4EgKGbOwAiAotGHH02K20iOkWoX186rRX+a+p+g cdljiEoHs66HEloUBJQnjppqiT6zv7DKeo07APPIzhwfxtBW+mF1MNo3tWRlcFHka7KJ Lang== 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=eVKPH13bJ8Pw64uEwVW7kgXl7zM95RCC9p4HQ/Nmkxc=; b=M6voNauFBimGdbBKzRz6LzxyaEQrpo21Pv+JfNS7SeOUb9VlBrKZnkdQU7pCMtlyl6 COFKmYYuXMuuFkjPqw+Q5bGCa5gExyjo1wY8F1YDtdn1BvgUinK3j8zsKdR+tRsb9c4v UK838JghSk7mwO1EG2lOP6q2KzE+mSTb0z1z4o8f5wqv8RQxllM7gxLdQOtM6PlM7vKx zmlemqd6PX9k2f5eOaD2sqybSU0Y54MPkNgH3mRt1KiUVWb/RnxX+0L57y5KNykkeEVf tXIqM9qPdOLX3MZhxwMf9bR28vSkwTvJk7IK3+sjvpmN7ODVtdiKWdbnm5tq8Q0PGnEf vmEw== X-Gm-Message-State: AOAM531HWPoXfFQ3XQ3AR6fgkSeP/4Y4jv7zSBQiFMIady+uB4Gbec1k ArAtMSy9jVjwgb8goPwgTV0El/Te/NN2CbrU+P5+Nw== X-Google-Smtp-Source: ABdhPJwyNa5JtDrCrL0QwPn23WFV/NR0ScwfP8QbZgi9Zt8Jb/woYIWrdbvxRI7qVPb4gUafwyyuYw+LMdkuNVRKTIU= X-Received: by 2002:a4a:751a:: with SMTP id j26mr2423028ooc.14.1600768599083; Tue, 22 Sep 2020 02:56:39 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200921174357.GB3141@willie-the-truck> In-Reply-To: <20200921174357.GB3141@willie-the-truck> From: Marco Elver Date: Tue, 22 Sep 2020 11:56:26 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Will Deacon Cc: 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 , Mark Rutland , 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 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? Thanks, -- Marco