All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way
Date: Mon, 24 May 2021 12:36:34 +0200	[thread overview]
Message-ID: <CANpmjNOVikz=u90-xQKzWGxbH_ov5R_EkuG6ZLqVAkjkgw8Z2Q@mail.gmail.com> (raw)
In-Reply-To: <20210524172529.3d23c3e7@xhacker.debian>

On Mon, 24 May 2021 at 11:26, Jisheng Zhang <Jisheng.Zhang@synaptics.com> 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 <Jisheng.Zhang@synaptics.com>
> ---
>  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
>

WARNING: multiple messages have this Message-ID (diff)
From: Marco Elver <elver@google.com>
To: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	 Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	 kasan-dev <kasan-dev@googlegroups.com>,
	 Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way
Date: Mon, 24 May 2021 12:36:34 +0200	[thread overview]
Message-ID: <CANpmjNOVikz=u90-xQKzWGxbH_ov5R_EkuG6ZLqVAkjkgw8Z2Q@mail.gmail.com> (raw)
In-Reply-To: <20210524172529.3d23c3e7@xhacker.debian>

On Mon, 24 May 2021 at 11:26, Jisheng Zhang <Jisheng.Zhang@synaptics.com> 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 <Jisheng.Zhang@synaptics.com>
> ---
>  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

  reply	other threads:[~2021-05-24 10:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  9:24 [PATCH 0/2] arm64: remove page granularity limitation from KFENCE Jisheng Zhang
2021-05-24  9:24 ` Jisheng Zhang
2021-05-24  9:25 ` [PATCH 1/2] kfence: allow providing __kfence_pool in arch specific way Jisheng Zhang
2021-05-24  9:25   ` Jisheng Zhang
2021-05-24 10:36   ` Marco Elver [this message]
2021-05-24 10:36     ` Marco Elver
2021-05-24 10:36     ` Marco Elver
2021-05-25  1:27     ` Jisheng Zhang
2021-05-25  1:27       ` Jisheng Zhang
2021-05-24  9:26 ` [PATCH 2/2] arm64: remove page granularity limitation from KFENCE Jisheng Zhang
2021-05-24  9:26   ` Jisheng Zhang
2021-05-24 10:04   ` Marco Elver
2021-05-24 10:04     ` Marco Elver
2021-05-24 10:04     ` Marco Elver
2021-05-24 10:06     ` Jisheng Zhang
2021-05-24 10:06       ` Jisheng Zhang
2021-05-24 18:04     ` Ard Biesheuvel
2021-05-24 18:04       ` Ard Biesheuvel
2021-05-24 18:04       ` Ard Biesheuvel
2021-05-25  2:15       ` Jisheng Zhang
2021-05-25  2:15         ` Jisheng Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANpmjNOVikz=u90-xQKzWGxbH_ov5R_EkuG6ZLqVAkjkgw8Z2Q@mail.gmail.com' \
    --to=elver@google.com \
    --cc=Jisheng.Zhang@synaptics.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.