From: Dmitry Vyukov <dvyukov@google.com> To: Alexander Potapenko <glider@google.com> Cc: Marco Elver <elver@google.com>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Mark Rutland <mark.rutland@arm.com>, Pekka Enberg <penberg@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, "Paul E. McKenney" <paulmck@kernel.org>, Andrey Konovalov <andreyknvl@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, Eric Dumazet <edumazet@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@redhat.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Peter Zijlstra <peterz@infradead.org>, Qian Cai <cai@lca.pw>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux-MM <linux-mm@kvack.org> Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Thu, 10 Sep 2020 19:11:41 +0200 [thread overview] Message-ID: <CACT4Y+awrz-j8y5Qc8OS9qkov4doMnw1V=obwp3MB_LTvaUFXw@mail.gmail.com> (raw) In-Reply-To: <CAG_fn=W4es7jaTotDORt2SwspE4A804mdwAY1j4gcaSEKtRjiw@mail.gmail.com> On Thu, Sep 10, 2020 at 6:19 PM Alexander Potapenko <glider@google.com> wrote: > > On Thu, Sep 10, 2020 at 5:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > + /* Calculate address for this allocation. */ > > > + if (right) > > > + meta->addr += PAGE_SIZE - size; > > > + meta->addr = ALIGN_DOWN(meta->addr, cache->align); > > > > I would move this ALIGN_DOWN under the (right) if. > > Do I understand it correctly that it will work, but we expect it to do > > nothing for !right? If cache align is >PAGE_SIZE, nothing good will > > happen anyway, right? > > The previous 2 lines look like part of the same calculation -- "figure > > out the addr for the right case". > > Yes, makes sense. > > > > + > > > + schedule_delayed_work(&kfence_timer, 0); > > > + WRITE_ONCE(kfence_enabled, true); > > > > Can toggle_allocation_gate run before we set kfence_enabled? If yes, > > it can break. If not, it's still somewhat confusing. > > Correct, it should go after we enable KFENCE. We'll fix that in v2. > > > > +void __kfence_free(void *addr) > > > +{ > > > + struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr); > > > + > > > + if (unlikely(meta->cache->flags & SLAB_TYPESAFE_BY_RCU)) > > > > This may deserve a comment as to why we apply rcu on object level > > whereas SLAB_TYPESAFE_BY_RCU means slab level only. > > Sorry, what do you mean by "slab level"? > SLAB_TYPESAFE_BY_RCU means we have to wait for possible RCU accesses > in flight before freeing objects from that slab - that's basically > what we are doing here below: Exactly! You see it is confusing :) SLAB_TYPESAFE_BY_RCU does not mean that. rcu-freeing only applies to whole pages, that's what I mean by "slab level" (whole slabs are freed by rcu). > > > + call_rcu(&meta->rcu_head, rcu_guarded_free); > > > + else > > > + kfence_guarded_free(addr, meta); > > > +}
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Vyukov <dvyukov@google.com> To: Alexander Potapenko <glider@google.com> Cc: Mark Rutland <mark.rutland@arm.com>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Dave Hansen <dave.hansen@linux.intel.com>, Linux-MM <linux-mm@kvack.org>, Eric Dumazet <edumazet@google.com>, "H. Peter Anvin" <hpa@zytor.com>, Christoph Lameter <cl@linux.com>, Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>, the arch/x86 maintainers <x86@kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Ingo Molnar <mingo@redhat.com>, David Rientjes <rientjes@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Marco Elver <elver@google.com>, Kees Cook <keescook@chromium.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jann Horn <jannh@google.com>, Andrey Konovalov <andreyknvl@google.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andrew Morton <akpm@linux-foundation.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, Pekka Enberg <penberg@kernel.org>, Qian Cai <cai@lca.pw>, Joonsoo Kim <iamjoonsoo.kim@lge.com> Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Thu, 10 Sep 2020 19:11:41 +0200 [thread overview] Message-ID: <CACT4Y+awrz-j8y5Qc8OS9qkov4doMnw1V=obwp3MB_LTvaUFXw@mail.gmail.com> (raw) In-Reply-To: <CAG_fn=W4es7jaTotDORt2SwspE4A804mdwAY1j4gcaSEKtRjiw@mail.gmail.com> On Thu, Sep 10, 2020 at 6:19 PM Alexander Potapenko <glider@google.com> wrote: > > On Thu, Sep 10, 2020 at 5:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > + /* Calculate address for this allocation. */ > > > + if (right) > > > + meta->addr += PAGE_SIZE - size; > > > + meta->addr = ALIGN_DOWN(meta->addr, cache->align); > > > > I would move this ALIGN_DOWN under the (right) if. > > Do I understand it correctly that it will work, but we expect it to do > > nothing for !right? If cache align is >PAGE_SIZE, nothing good will > > happen anyway, right? > > The previous 2 lines look like part of the same calculation -- "figure > > out the addr for the right case". > > Yes, makes sense. > > > > + > > > + schedule_delayed_work(&kfence_timer, 0); > > > + WRITE_ONCE(kfence_enabled, true); > > > > Can toggle_allocation_gate run before we set kfence_enabled? If yes, > > it can break. If not, it's still somewhat confusing. > > Correct, it should go after we enable KFENCE. We'll fix that in v2. > > > > +void __kfence_free(void *addr) > > > +{ > > > + struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr); > > > + > > > + if (unlikely(meta->cache->flags & SLAB_TYPESAFE_BY_RCU)) > > > > This may deserve a comment as to why we apply rcu on object level > > whereas SLAB_TYPESAFE_BY_RCU means slab level only. > > Sorry, what do you mean by "slab level"? > SLAB_TYPESAFE_BY_RCU means we have to wait for possible RCU accesses > in flight before freeing objects from that slab - that's basically > what we are doing here below: Exactly! You see it is confusing :) SLAB_TYPESAFE_BY_RCU does not mean that. rcu-freeing only applies to whole pages, that's what I mean by "slab level" (whole slabs are freed by rcu). > > > + call_rcu(&meta->rcu_head, rcu_guarded_free); > > > + else > > > + kfence_guarded_free(addr, meta); > > > +} _______________________________________________ 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:[~2020-09-10 17:14 UTC|newest] Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-07 13:40 [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 15:41 ` Jonathan Cameron 2020-09-07 15:41 ` Jonathan Cameron 2020-09-07 16:38 ` Marco Elver 2020-09-07 16:38 ` Marco Elver 2020-09-07 16:38 ` Marco Elver 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 16:22 ` Marco Elver 2020-09-10 16:22 ` Marco Elver 2020-09-10 16:22 ` Marco Elver 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 17:11 ` Dmitry Vyukov [this message] 2020-09-10 17:11 ` Dmitry Vyukov 2020-09-10 17:11 ` Dmitry Vyukov 2020-09-10 17:41 ` Marco Elver 2020-09-10 17:41 ` Marco Elver 2020-09-10 17:41 ` Marco Elver 2020-09-10 20:25 ` Paul E. McKenney 2020-09-10 20:25 ` Paul E. McKenney 2020-09-15 13:57 ` SeongJae Park 2020-09-15 13:57 ` SeongJae Park 2020-09-15 14:14 ` Marco Elver 2020-09-15 14:14 ` Marco Elver 2020-09-15 14:26 ` SeongJae Park 2020-09-15 14:26 ` SeongJae Park 2020-09-07 13:40 ` [PATCH RFC 02/10] x86, kfence: enable KFENCE for x86 Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 17:31 ` kernel test robot 2020-09-07 13:40 ` [PATCH RFC 03/10] arm64, kfence: enable KFENCE for ARM64 Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 04/10] mm, kfence: insert KFENCE hooks for SLAB Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 12:24 ` Marco Elver 2020-09-11 12:24 ` Marco Elver 2020-09-11 12:24 ` Marco Elver 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-07 13:40 ` [PATCH RFC 05/10] mm, kfence: insert KFENCE hooks for SLUB Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 06/10] kfence, kasan: make KFENCE compatible with KASAN Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 16:11 ` kernel test robot 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 13:00 ` Marco Elver 2020-09-11 13:00 ` Marco Elver 2020-09-11 13:00 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 07/10] kfence, kmemleak: make KFENCE compatible with KMEMLEAK Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-08 11:53 ` Catalin Marinas 2020-09-08 11:53 ` Catalin Marinas 2020-09-08 12:29 ` Alexander Potapenko 2020-09-08 12:29 ` Alexander Potapenko 2020-09-08 12:29 ` Alexander Potapenko 2020-09-07 13:40 ` [PATCH RFC 08/10] kfence, lockdep: make KFENCE compatible with lockdep Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 16:33 ` Marco Elver 2020-09-07 16:33 ` Marco Elver 2020-09-07 16:33 ` Marco Elver 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 18:16 ` Marco Elver 2020-09-07 18:16 ` Marco Elver 2020-09-07 18:16 ` Marco Elver 2020-09-08 15:54 ` Dave Hansen 2020-09-08 15:54 ` Dave Hansen 2020-09-08 16:14 ` Marco Elver 2020-09-08 16:14 ` Marco Elver 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:46 ` Marco Elver 2020-09-11 7:46 ` Marco Elver 2020-09-11 7:46 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 10/10] kfence: add test suite Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 18:37 ` kernel test robot 2020-09-08 11:48 ` [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Vlastimil Babka 2020-09-08 11:48 ` Vlastimil Babka 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 14:40 ` Vlastimil Babka 2020-09-08 14:40 ` Vlastimil Babka 2020-09-08 15:21 ` Marco Elver 2020-09-08 15:21 ` Marco Elver 2020-09-08 14:52 ` Dave Hansen 2020-09-08 14:52 ` Dave Hansen 2020-09-08 15:31 ` Marco Elver 2020-09-08 15:31 ` Marco Elver 2020-09-08 15:36 ` Vlastimil Babka 2020-09-08 15:36 ` Vlastimil Babka 2020-09-08 15:56 ` Marco Elver 2020-09-08 15:56 ` Marco Elver 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 12:03 ` Marco Elver 2020-09-11 12:03 ` Marco Elver 2020-09-11 12:03 ` Marco Elver 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:33 ` Marco Elver 2020-09-11 13:33 ` Marco Elver 2020-09-11 13:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-08 15:37 ` Dave Hansen 2020-09-08 15:37 ` Dave Hansen
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='CACT4Y+awrz-j8y5Qc8OS9qkov4doMnw1V=obwp3MB_LTvaUFXw@mail.gmail.com' \ --to=dvyukov@google.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=aryabinin@virtuozzo.com \ --cc=bp@alien8.de \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=cl@linux.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=edumazet@google.com \ --cc=elver@google.com \ --cc=glider@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=jannh@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=paulmck@kernel.org \ --cc=penberg@kernel.org \ --cc=peterz@infradead.org \ --cc=rientjes@google.com \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ --cc=x86@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.