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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 59374C04FF3 for ; Mon, 24 May 2021 10:36:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3BBCE60FE7 for ; Mon, 24 May 2021 10:36:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232628AbhEXKiS (ORCPT ); Mon, 24 May 2021 06:38:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232575AbhEXKiQ (ORCPT ); Mon, 24 May 2021 06:38:16 -0400 Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AC6DC061574 for ; Mon, 24 May 2021 03:36:47 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id x15so26607100oic.13 for ; Mon, 24 May 2021 03:36:47 -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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=vO8TRdchq8qlXFP7kNIZKyborERcCPCFxcRJlmVAg91ZhBc+M/OlVcyjenZaivhTHq SFT99XA7iNxm5biJlXDD6SDFMlUDP4f+KFEVn43PqGQyRm/xeH3pTNwqy2XaJPlQdJMs Wo3I/Ob/uXt+TrLVe1h7dpHeOsUo8sDpK+1yhlTf3UCuW/GzVoABNtORkiLQL98hJWLU ZPUOvhlgokNhXjOlFavc8zrbqCUyohZECH3qe8YwsRgKibc53g4FQOoC5ds1BJznXRJQ P2qvqB+EzJ5NnOH6CRr/FCln8RaGoqcqdM4/E+3de9AN3hMDF+gWMRuNDLir7A04Gk11 ITKA== 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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=Yw8qR7PpzTachkVKcqhSQzKcFWDLb0t3QGo3/a8OIHhoAXZzPNMg9NBoqVTwBctTH/ Uzxc3JMrAfTvkhq4/a6WG0u3I8jDi8dzZiKVjw2oNkt/ndB1vItcV3wbt9uhJ4YJpALK E66oV+5AlwB0RXWetJzKv38ban5qQfTNwyriqDhYhxVfQ42/Rei33oP4it+rE54i4jzT FwXtSmQP3I/d1/+Kd7ArrvHixZZmuPe5ddGDcl/R+AwnNVOSgzVhtRBQp02FKLalcOKj fxlxwvMcFEvlD02cd1ZB69ly3fsBeedb5evYDd1YH70hEUbWhhiqSPE7EmZb7IZDaW/w s8Mg== X-Gm-Message-State: AOAM530rmJr2MtK8JJ2mEXt6tRZep7rtsPzu2mQdqh9HDJ2TOpfmt3YE zV1Gf/4KzQzo0Tw+/7jUjvaS40OHfJmrVkExSSOWAA== X-Google-Smtp-Source: ABdhPJxTHFDXkF0sGbpwKQ/wGAzN9+c/BhxVAg382Xrdc+7foZ+2Jc5h0xV9kkBUR2lsvZI4bw9Advoi1aORJHu1tpk= X-Received: by 2002:a05:6808:10d4:: with SMTP id s20mr10530580ois.70.1621852606335; Mon, 24 May 2021 03:36:46 -0700 (PDT) MIME-Version: 1.0 References: <20210524172433.015b3b6b@xhacker.debian> <20210524172529.3d23c3e7@xhacker.debian> In-Reply-To: <20210524172529.3d23c3e7@xhacker.debian> From: Marco Elver Date: Mon, 24 May 2021 12:36:34 +0200 Message-ID: Subject: Re: [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way To: Jisheng Zhang Cc: Catalin Marinas , Will Deacon , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , Linux ARM , LKML , kasan-dev , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 24 May 2021 at 11:26, Jisheng Zhang wrote: > Some architectures may want to allocate the __kfence_pool differently > for example, allocate the __kfence_pool earlier before paging_init(). > We also delay the memset() to kfence_init_pool(). > > Signed-off-by: Jisheng Zhang > --- > mm/kfence/core.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index e18fbbd5d9b4..65f0210edb65 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -430,6 +430,8 @@ static bool __init kfence_init_pool(void) > if (!__kfence_pool) > return false; > > + memset(__kfence_pool, 0, KFENCE_POOL_SIZE); > + Use memzero_explicit(). Also, for the arm64 case, is delaying the zeroing relevant? You still call kfence_alloc_pool() in patch 2/2, and zeroing it on memblock_alloc() is not wrong, correct? Essentially if there's not going to be any benefit to us doing the zeroing ourselves, I'd simply leave it as-is and keep using memblock_alloc(). And if there's some odd architecture that doesn't even want to use kfence_alloc_pool(), they could just zero the memory themselves. But we really should use kfence_alloc_pool(), because otherwise it'll just become unmaintainable if on changes to kfence_alloc_pool() we have to go and find other special architectures that don't use it and adjust them, too. Thanks, -- Marco > if (!arch_kfence_init_pool()) > goto err; > > @@ -645,10 +647,10 @@ static DECLARE_DELAYED_WORK(kfence_timer, toggle_allocation_gate); > > void __init kfence_alloc_pool(void) > { > - if (!kfence_sample_interval) > + if (!kfence_sample_interval || __kfence_pool) > return; > > - __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > + __kfence_pool = memblock_alloc_raw(KFENCE_POOL_SIZE, PAGE_SIZE); > > if (!__kfence_pool) > pr_err("failed to allocate pool\n"); > -- > 2.31.0 > 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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham 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 3A28DC04FF3 for ; Mon, 24 May 2021 10:36:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9221606A5 for ; Mon, 24 May 2021 10:36:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9221606A5 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 A220C940069; Mon, 24 May 2021 06:36:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A450940055; Mon, 24 May 2021 06:36:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C172940069; Mon, 24 May 2021 06:36:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 093B2940055 for ; Mon, 24 May 2021 06:36:47 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7B2D1181AEF30 for ; Mon, 24 May 2021 10:36:47 +0000 (UTC) X-FDA: 78175771254.10.0E9A092 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by imf12.hostedemail.com (Postfix) with ESMTP id 07191130 for ; Mon, 24 May 2021 10:36:39 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id s19so26645371oic.7 for ; Mon, 24 May 2021 03:36:47 -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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=vO8TRdchq8qlXFP7kNIZKyborERcCPCFxcRJlmVAg91ZhBc+M/OlVcyjenZaivhTHq SFT99XA7iNxm5biJlXDD6SDFMlUDP4f+KFEVn43PqGQyRm/xeH3pTNwqy2XaJPlQdJMs Wo3I/Ob/uXt+TrLVe1h7dpHeOsUo8sDpK+1yhlTf3UCuW/GzVoABNtORkiLQL98hJWLU ZPUOvhlgokNhXjOlFavc8zrbqCUyohZECH3qe8YwsRgKibc53g4FQOoC5ds1BJznXRJQ P2qvqB+EzJ5NnOH6CRr/FCln8RaGoqcqdM4/E+3de9AN3hMDF+gWMRuNDLir7A04Gk11 ITKA== 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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=ZoqBKPny//oJV48wdkTIcfTwohFu+/jz6rYGappiP2FAAovRjjWlnuKPwbiOb8g4MF Q+Vxr7gvVN0brnotbDAk/uucOVAfudJe7Cbt5ILtK/ziCbpmkvvrONtfHqf7aTYx2ipq 0VPfHcDe9ozEm4s4iGK1oZ2nqY7r+UwkWDnThAyg4ZbbRgpGkAqK+/PWQFyjvSblCxI6 YnCh0b9FR62mWPwbs65aFsmS8xtIyfZh3fPX8uu0JsScLnz4LNDLJu8Z171DxwInx7sV fGoq85I27JLHMGGwoPZbbBtWG8k+uiyC3QKsVcpkBFVdDHY8pHmFfnhjnWWXEGpgfrYW HXMg== X-Gm-Message-State: AOAM530JtMEW4F+sFQFP/0ESJXcF78Z+hkasIo4nBoBdbDAEbNw8Lhgi rhXxfB4xY/k1j8Hnj8C444DQlUo3lIFUhdD5RKXsRA== X-Google-Smtp-Source: ABdhPJxTHFDXkF0sGbpwKQ/wGAzN9+c/BhxVAg382Xrdc+7foZ+2Jc5h0xV9kkBUR2lsvZI4bw9Advoi1aORJHu1tpk= X-Received: by 2002:a05:6808:10d4:: with SMTP id s20mr10530580ois.70.1621852606335; Mon, 24 May 2021 03:36:46 -0700 (PDT) MIME-Version: 1.0 References: <20210524172433.015b3b6b@xhacker.debian> <20210524172529.3d23c3e7@xhacker.debian> In-Reply-To: <20210524172529.3d23c3e7@xhacker.debian> From: Marco Elver Date: Mon, 24 May 2021 12:36:34 +0200 Message-ID: Subject: Re: [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way To: Jisheng Zhang Cc: Catalin Marinas , Will Deacon , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , Linux ARM , LKML , kasan-dev , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=vO8TRdch; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of elver@google.com designates 209.85.167.180 as permitted sender) smtp.mailfrom=elver@google.com X-Stat-Signature: 97k91gnnpjnjuxbgi1woreqausyn47co X-Rspamd-Queue-Id: 07191130 X-Rspamd-Server: rspam02 X-HE-Tag: 1621852599-672381 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, 24 May 2021 at 11:26, Jisheng Zhang wrote: > Some architectures may want to allocate the __kfence_pool differently > for example, allocate the __kfence_pool earlier before paging_init(). > We also delay the memset() to kfence_init_pool(). > > Signed-off-by: Jisheng Zhang > --- > mm/kfence/core.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index e18fbbd5d9b4..65f0210edb65 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -430,6 +430,8 @@ static bool __init kfence_init_pool(void) > if (!__kfence_pool) > return false; > > + memset(__kfence_pool, 0, KFENCE_POOL_SIZE); > + Use memzero_explicit(). Also, for the arm64 case, is delaying the zeroing relevant? You still call kfence_alloc_pool() in patch 2/2, and zeroing it on memblock_alloc() is not wrong, correct? Essentially if there's not going to be any benefit to us doing the zeroing ourselves, I'd simply leave it as-is and keep using memblock_alloc(). And if there's some odd architecture that doesn't even want to use kfence_alloc_pool(), they could just zero the memory themselves. But we really should use kfence_alloc_pool(), because otherwise it'll just become unmaintainable if on changes to kfence_alloc_pool() we have to go and find other special architectures that don't use it and adjust them, too. Thanks, -- Marco > if (!arch_kfence_init_pool()) > goto err; > > @@ -645,10 +647,10 @@ static DECLARE_DELAYED_WORK(kfence_timer, toggle_allocation_gate); > > void __init kfence_alloc_pool(void) > { > - if (!kfence_sample_interval) > + if (!kfence_sample_interval || __kfence_pool) > return; > > - __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > + __kfence_pool = memblock_alloc_raw(KFENCE_POOL_SIZE, PAGE_SIZE); > > if (!__kfence_pool) > pr_err("failed to allocate pool\n"); > -- > 2.31.0 > 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=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 76B8DC2B9F7 for ; Mon, 24 May 2021 23:44:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3A19B6140F for ; Mon, 24 May 2021 23:44:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A19B6140F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gesGVDj/YP4PUbMVjaEYJFYyDZUNPVBYUyYiHkVKWcM=; b=msqUYiY+Mocwnl rpeu+roo2QiPS2FeZBxMRfq6JXZ7LNGyzCXUN6L2Djw0c8fkYj1gpOfvUuAgs2GqIR1cMScGgsmoi 84U6Bgrc+SFxGM1JL1yE0y6lwtu2wbuEIhpeWAQGeeXK5mBfPPCa4C8Mi+93J9EhcZOgUUkQYPB20 8GIV4dgsdMZI94bBjGdX+ODg8nsyFAr362MJbPTA8DVkd64MMh7BJivh1/XgH0mXTm+2hcFs7mi4G sMJD5aA3I7la1mz582gTISB7Oc216aclavNmjUiazfTrOzrfrn3jYIWEyfVNbK6ygRvxn5JGeOQ8q 7tKbSIauYBU6oRlhw6tg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1llKDC-002O6T-VM; Mon, 24 May 2021 23:42:20 +0000 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ll7x1-000ptD-Lp for linux-arm-kernel@lists.infradead.org; Mon, 24 May 2021 10:36:49 +0000 Received: by mail-oi1-x22f.google.com with SMTP id u11so26651207oiv.1 for ; Mon, 24 May 2021 03:36:47 -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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=vO8TRdchq8qlXFP7kNIZKyborERcCPCFxcRJlmVAg91ZhBc+M/OlVcyjenZaivhTHq SFT99XA7iNxm5biJlXDD6SDFMlUDP4f+KFEVn43PqGQyRm/xeH3pTNwqy2XaJPlQdJMs Wo3I/Ob/uXt+TrLVe1h7dpHeOsUo8sDpK+1yhlTf3UCuW/GzVoABNtORkiLQL98hJWLU ZPUOvhlgokNhXjOlFavc8zrbqCUyohZECH3qe8YwsRgKibc53g4FQOoC5ds1BJznXRJQ P2qvqB+EzJ5NnOH6CRr/FCln8RaGoqcqdM4/E+3de9AN3hMDF+gWMRuNDLir7A04Gk11 ITKA== 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=OyogGDxMaGSBrj2rkEP+jK8JOL+4OXbDVcsd7RbbjgQ=; b=WlygAUpabhj5compX9FN3hh/b8rc6j09XgcKdDhUYnG56davo+3FLegLp5RIkwrvgm 4mRzVu35NxA5YuLKl494Mx3GkzfBPB95esd9vNaiG2lbtusvwIAYPVb+3gsptxD2nM8u wo3pV8D6ENnkJ33gzCWrvfNiRbExZ5kgsTwf6W+IxyKlLK695xCNW2XXue7vgUuTkA8E 0pmvsNeMjVsSaZTlGmK+yKrlL96+RkxZthrX+sL8pU3a08P3ZIQ+rV4Es3CF2lxN+65p 6ZQVUD/0wNg3K6A0lEW2m0A7RIIEYK0ycuCxnz383+qv7wklsGG4+pibwIlDDmIFU1BX 2hCg== X-Gm-Message-State: AOAM530nwLpDRxfOR/CWJHUc1cpEw21klnet3bVAW1ziH1CqP2nR0/Xv czMpsQD47kgIxCPJzDUTlWNDmdPMqAvH58wA9pCyrw== X-Google-Smtp-Source: ABdhPJxTHFDXkF0sGbpwKQ/wGAzN9+c/BhxVAg382Xrdc+7foZ+2Jc5h0xV9kkBUR2lsvZI4bw9Advoi1aORJHu1tpk= X-Received: by 2002:a05:6808:10d4:: with SMTP id s20mr10530580ois.70.1621852606335; Mon, 24 May 2021 03:36:46 -0700 (PDT) MIME-Version: 1.0 References: <20210524172433.015b3b6b@xhacker.debian> <20210524172529.3d23c3e7@xhacker.debian> In-Reply-To: <20210524172529.3d23c3e7@xhacker.debian> From: Marco Elver Date: Mon, 24 May 2021 12:36:34 +0200 Message-ID: Subject: Re: [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way To: Jisheng Zhang Cc: Catalin Marinas , Will Deacon , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , Linux ARM , LKML , kasan-dev , Linux Memory Management List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210524_033647_757463_CEF2D284 X-CRM114-Status: GOOD ( 22.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 24 May 2021 at 11:26, Jisheng Zhang wrote: > Some architectures may want to allocate the __kfence_pool differently > for example, allocate the __kfence_pool earlier before paging_init(). > We also delay the memset() to kfence_init_pool(). > > Signed-off-by: Jisheng Zhang > --- > mm/kfence/core.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index e18fbbd5d9b4..65f0210edb65 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -430,6 +430,8 @@ static bool __init kfence_init_pool(void) > if (!__kfence_pool) > return false; > > + memset(__kfence_pool, 0, KFENCE_POOL_SIZE); > + Use memzero_explicit(). Also, for the arm64 case, is delaying the zeroing relevant? You still call kfence_alloc_pool() in patch 2/2, and zeroing it on memblock_alloc() is not wrong, correct? Essentially if there's not going to be any benefit to us doing the zeroing ourselves, I'd simply leave it as-is and keep using memblock_alloc(). And if there's some odd architecture that doesn't even want to use kfence_alloc_pool(), they could just zero the memory themselves. But we really should use kfence_alloc_pool(), because otherwise it'll just become unmaintainable if on changes to kfence_alloc_pool() we have to go and find other special architectures that don't use it and adjust them, too. Thanks, -- Marco > if (!arch_kfence_init_pool()) > goto err; > > @@ -645,10 +647,10 @@ static DECLARE_DELAYED_WORK(kfence_timer, toggle_allocation_gate); > > void __init kfence_alloc_pool(void) > { > - if (!kfence_sample_interval) > + if (!kfence_sample_interval || __kfence_pool) > return; > > - __kfence_pool = memblock_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > + __kfence_pool = memblock_alloc_raw(KFENCE_POOL_SIZE, PAGE_SIZE); > > if (!__kfence_pool) > pr_err("failed to allocate pool\n"); > -- > 2.31.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel