Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1078043pxk; Thu, 1 Oct 2020 23:50:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypTxoY+S/EI//7wpITMX8u1HteHrAUmCoA0e/NmFI7NfHCvYjTypYweKO4EHEBrSlcIOG5 X-Received: by 2002:a05:6402:7d2:: with SMTP id u18mr809915edy.69.1601621440126; Thu, 01 Oct 2020 23:50:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601621440; cv=none; d=google.com; s=arc-20160816; b=G7DkxPYKUPFgEWFQ2aFaKa/n0E5m1CzM4yxCgsHbJTX5HtPgczNGKMiWB7G+v2ddKq uncBA/TtRtnc9cwjNDNfRZ/vAu1JLsSzyrclN9f8d8OdLgZjVK9bgE+aIx2K1mjeXGK5 Jf13ZGRHzTP9IDl/V91Z4ScSnGXzrCGIjQVN05v5GPa8YcJEMPE0NzgpiaKJuksoPle0 9puMleJIRAQ30Sr8HR+TkSmSAeGSP5J7+OQepmeoorwC3MUqGN2fjR+ZIkqKXaKROhqz mlDk6zN5Y6x9k09TeLHc9hcd/dCN5ssRN0Fk3MN9jSqz+AapeLUOYJXyCRLw0JTK0pPt reZQ== 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=J8AL8yHl5XUf+oARcqfxDLAGYCbuXqngBj+IQF3uLUQ=; b=b6geutMKVXpej7mGQ2kHz9FzfC6pkIZrQcJA2oIKSJ2dbCEmCe4H3dpGLjH1Sf5izx OgG4Py8zVN3NV0kUdEpky57hgbpsSE9RexFhXZpGnihugtz+54kE9a62BWQbbaoFcpKc OPjOeX7viYRpMAlTi3oyzIhuHvN735GiFSUxCRn2wy5lvDCptTyEhl2Scm2VkJtfchd4 wzuHKfPDysVx6FWF8poqQrQBgQERreDXIl+9iqidaMlhDofTrtElXvHq+zgIlOBucVX6 ObgD15bSv6cXQADs002Nk9vsQoqU3OFNOuP06SCqgbi+cUO5cW5sc5q6MW7RNgsOIs2p Q8TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GFZ4SnEx; 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 a2si362478edm.349.2020.10.01.23.50.16; Thu, 01 Oct 2020 23:50:40 -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=GFZ4SnEx; 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 S1726103AbgJBGs0 (ORCPT + 99 others); Fri, 2 Oct 2020 02:48:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgJBGs0 (ORCPT ); Fri, 2 Oct 2020 02:48:26 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E45F4C0613D0 for ; Thu, 1 Oct 2020 23:48:25 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id q13so420752ejo.9 for ; Thu, 01 Oct 2020 23:48:25 -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=J8AL8yHl5XUf+oARcqfxDLAGYCbuXqngBj+IQF3uLUQ=; b=GFZ4SnExAGpSUQcgEHltpw6VH2jvAIP1cM2337vQDxAVdtfAMn8c2mdZs7tq+274Gz 3FtXj+EBj8JQwf6wy5lgJk0wUL0L0pQC0hHrZT8rDQp7JA7Bban1UWzpQmF0/tDcV71G OLGK2UD/RvehqDFkicq1AwY8jRZtPYDdXs2AQm/+x59ZXZ0m5jCe85J4LFD3CE2oDm1E HL+4eVuK4K76XQre+NGZAWWYGAg1pVHLvL7ZL+QJtpKRxQ52EXgiyp0Ytdt+ekDCLVUn 1+Xf1SeqFAcmchY7wiOOOZT5do/DFkXASv/ezxxDLz8P+sfiTclHqih61mA7dC8y8QBv I8uw== 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=J8AL8yHl5XUf+oARcqfxDLAGYCbuXqngBj+IQF3uLUQ=; b=cV7caQJjngBO3zCmgjngRaSr5PzcRF33brQNesb2n5O64QvCM0C7yXcNfa/1PEdXYm Rc+FOsNhGFckye5SFxFSU3O9WSJIb/HH2bmdmjVsHhWmPIINACVPUWmj3x1QvOYFtxxC aSXc4nPGcaupYferRR3SgBes/chW3jkFiEaCJOj2EYCTL3d7038YdcpPFs96oXxAr/NZ tLNlcl2YN8M09ovHkhXsOMTiGz8cg8etWp/CQyPcgutH0reRiM3gXT2QF30Cf3Zl2RCA TULD343esUhhJYaoDGRwJhZjVaqPGJmZVbziAn8fJ2xalEDtSAwDxFq7RWi2xbVJVceO 3WBA== X-Gm-Message-State: AOAM532cq5lE7x+G0q6UmYSht7Hi1a5PRWYvXvbEjMKz5z8Z095/kl2K pRdPj9uxaLwE/cElfMbg6Tu31HT41/29WJXmITr68Q== X-Received: by 2002:a17:906:394:: with SMTP id b20mr727889eja.513.1601621304442; Thu, 01 Oct 2020 23:48:24 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-4-elver@google.com> In-Reply-To: <20200929133814.2834621-4-elver@google.com> From: Jann Horn Date: Fri, 2 Oct 2020 08:47:57 +0200 Message-ID: Subject: Re: [PATCH v4 03/11] arm64, kfence: enable KFENCE for ARM64 To: Marco Elver 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@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, 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 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... Also, this kinda feels like it should be the "generic" version of arch_kfence_initialize_pool() and live in mm/kfence/core.c ?