Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1343652pxk; Fri, 2 Oct 2020 07:20:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxedRO9US55JBN/4fk27EEcZSMj1rhSppS1zYq6a+KRaGV6q+5H5agZc7/8sCs0655YSgW X-Received: by 2002:a17:906:7cc6:: with SMTP id h6mr2519244ejp.266.1601648436627; Fri, 02 Oct 2020 07:20:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601648436; cv=none; d=google.com; s=arc-20160816; b=fSsTGZJeQ9DMUOukpSLYSpflrC/nvBuNMeoNokCSY5gCk5lHEXqqi6raZcIjR5Jjxu CwjDYenizANTSCI2F94SWAmYFZBsFsPp3iZT2uJ+AgWXsCuJofPsrTUr5q1fJHPgFELo Ta5i/UjC3PhTqdnvEw7nZiOi3cCnMy3PmRWNjdfr5w9dS+lkuC6PB+/zP0doCqC9M3Rf 0xcGs9l/GKGa2lhwpkuPV2WKBVkv+TcXR0Kxv4Q8wQII5pyrijIGhsbbvCCjg1ASuEvb VDdORBrRSQO1MuFZW9PPyNpYxDpDoWG+xDY/WRhhcx5/LO+pIE2GNhRv4h04D3vB19xc OUPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=tYH/6hO5lgQzTOW7dEpfFVSSkr8P55YhoTlw55xP13w=; b=yzyJe8IuHVS5Yl80n+M/zWHxMTnaB/9EKNaMJFBJtzRIh+NRJtYfX45iR5piESIYyS 3YuJZqO/7AVCAalQf3+71DcPzgq2gvz8lWm2nIDSHu3+2Irt6pI7+PTZmbGcZCpGxDzr t7P3g6UJVrmmT5xWp4Kz/zNXGVnmnfsJJo0Nh8pfbiM0OU3MvC2JZFxkcnuaR/k76Y53 Rc9XBPfSWqErZzgYm3KMu386L9SGqiZ8xRCHvv03V1z8d6MzZCP46FttThGFZSldBVsP fgAhWKURML0bJnVziKcqLqV4h4G1EBu123NBMtTyAXbPGHJzJMkGMmzv6bi7RVMqvJAP xs0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="WbL9t9/X"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z3si1313323ejw.415.2020.10.02.07.20.14; Fri, 02 Oct 2020 07:20:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="WbL9t9/X"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388029AbgJBOTC (ORCPT + 99 others); Fri, 2 Oct 2020 10:19:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726017AbgJBOTB (ORCPT ); Fri, 2 Oct 2020 10:19:01 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 563C8C0613E2 for ; Fri, 2 Oct 2020 07:19:00 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id x14so1345636oic.9 for ; Fri, 02 Oct 2020 07:19:00 -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=tYH/6hO5lgQzTOW7dEpfFVSSkr8P55YhoTlw55xP13w=; b=WbL9t9/X+2+U5VeNgqJ2mzYEVs8LZ8q8hjggo7N19g1Jfbf7P1wkvnp8roJdVEw2lS c3i+9tyC5AUycxhnZX3RIt4oznfraSi/7+MhXAFF62q39I2RYcbTn5QT7+m9u2tkqg6l t8CPQiS4CwE3/je84zeBM5/j7j3lEb16Ugt2aIYvU40jH0TI0PR5J1CBlhaYuqhraQ9S VNH44ZU9nil0inzWBzSBsDd31QGBA5Yoy3hYBsIdwpYvq+FTYKKD014ZVWSBoeXqJDuA xB8WY3nYSYtoHgpNv87LMV6Wm9qhKizfdSBX5z2jHJgzn6f3UzGseSKEQmzLzzorHWIt HJog== 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=tYH/6hO5lgQzTOW7dEpfFVSSkr8P55YhoTlw55xP13w=; b=Xkny51sytj+qv8bIQsilTBdHPaNxqShq7CHeAb86DbnuUUbARyyVSu+l11de+5Sga4 MoWlglWtD6+ca2MFkzrMGzAAnt4sOm7/RicN6hWH5MIdGhBfx0A0w2YUUajkQvqdOQtm dt64fvIX8YKnZpkdWDplVfrwkPFjh2WRic64BT8dy9Ad3uZgM54DWdFP05XnEEiswZV6 UXS3f+0nIsf4AtEjzpuRN05XItBTCr+RZAytnzaqtvoL3d04iizfN7zl6cXlAZjVnhV7 A94rVSX9QzZcTVME7f4LjbafwDurQYEFzxbR1hxsJ0mrrBrJG80Y2epDUsLvM9oebFAB 91Gg== X-Gm-Message-State: AOAM531BEvCmQ/84bjncpQx/prSpOLa1GeqLYNk20j2itjDdWCPJmCJL NAC4WsNfjvdre0pXr1DslQjZXpqDPUZH/EPdqXqcWw== X-Received: by 2002:aca:3d07:: with SMTP id k7mr1392880oia.172.1601648339445; Fri, 02 Oct 2020 07:18:59 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-4-elver@google.com> In-Reply-To: From: Marco Elver Date: Fri, 2 Oct 2020 16:18:48 +0200 Message-ID: Subject: Re: [PATCH v4 03/11] arm64, kfence: enable KFENCE for ARM64 To: Jann Horn Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2 Oct 2020 at 08:48, Jann Horn wrote: > > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote: > > Add architecture specific implementation details for KFENCE and enable > > KFENCE for the arm64 architecture. In particular, this implements the > > required interface in . Currently, the arm64 version does > > not yet use a statically allocated memory pool, at the cost of a pointer > > load for each is_kfence_address(). > [...] > > diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h > [...] > > +static inline bool arch_kfence_initialize_pool(void) > > +{ > > + const unsigned int num_pages = ilog2(roundup_pow_of_two(KFENCE_POOL_SIZE / PAGE_SIZE)); > > + struct page *pages = alloc_pages(GFP_KERNEL, num_pages); > > + > > + if (!pages) > > + return false; > > + > > + __kfence_pool = page_address(pages); > > + return true; > > +} > > If you're going to do "virt_to_page(meta->addr)->slab_cache = cache;" > on these pages in kfence_guarded_alloc(), and pass them into kfree(), > you'd better mark these pages as non-compound - something like > alloc_pages_exact() or split_page() may help. Otherwise, I think when > SLUB's kfree() does virt_to_head_page() right at the start, that will > return a pointer to the first page of the entire __kfence_pool, and > then when it loads page->slab_cache, it gets some random cache and > stuff blows up. Kinda surprising that you haven't run into that during > your testing, maybe I'm missing something... I added a WARN_ON() check in kfence_initialize_pool() to check if our pages are compound or not; they are not. In slub.c, __GFP_COMP is passed to alloc_pages(), which causes them to have a compound head I believe. > Also, this kinda feels like it should be the "generic" version of > arch_kfence_initialize_pool() and live in mm/kfence/core.c ? Done for v5. Thanks, -- Marco