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
next prev parent 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: linkBe 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.