From: SeongJae Park <sjpark@amazon.com> To: Marco Elver <elver@google.com> Cc: SeongJae Park <sjpark@amazon.com>, <mark.rutland@arm.com>, <linux-doc@vger.kernel.org>, <peterz@infradead.org>, <catalin.marinas@arm.com>, <dave.hansen@linux.intel.com>, <linux-mm@kvack.org>, <edumazet@google.com>, <glider@google.com>, <hpa@zytor.com>, <cl@linux.com>, <will@kernel.org>, <corbet@lwn.net>, <x86@kernel.org>, <kasan-dev@googlegroups.com>, <mingo@redhat.com>, <dvyukov@google.com>, <rientjes@google.com>, <aryabinin@virtuozzo.com>, <keescook@chromium.org>, <paulmck@kernel.org>, <jannh@google.com>, <andreyknvl@google.com>, <cai@lca.pw>, <luto@kernel.org>, <tglx@linutronix.de>, <akpm@linux-foundation.org>, <linux-arm-kernel@lists.infradead.org>, <gregkh@linuxfoundation.org>, <linux-kernel@vger.kernel.org>, <penberg@kernel.org>, <bp@alien8.de>, <iamjoonsoo.kim@lge.com> Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Tue, 15 Sep 2020 16:26:31 +0200 [thread overview] Message-ID: <20200915142631.31234-1-sjpark@amazon.com> (raw) In-Reply-To: <20200915141449.GA3367763@elver.google.com> On Tue, 15 Sep 2020 16:14:49 +0200 Marco Elver <elver@google.com> wrote: > On Tue, Sep 15, 2020 at 03:57PM +0200, SeongJae Park wrote: > [...] > > > > So interesting feature! I left some tirvial comments below. > > Thank you! [...] > > > + > > > + /* Only call with a pointer into kfence_metadata. */ > > > + if (KFENCE_WARN_ON(meta < kfence_metadata || > > > + meta >= kfence_metadata + ARRAY_SIZE(kfence_metadata))) > > > > Is there a reason to use ARRAY_SIZE(kfence_metadata) instead of > > CONFIG_KFENCE_NUM_OBJECTS? > > They're equivalent. We can switch it. (Although I don't see one being > superior to the other.. maybe we save on compile-time?) I prefer CONFIG_KFENCE_NUM_OBJECTS here just because it's more widely used in the code. Also, I personally think it's more easy to read. [...] > > > + pr_info("initialized - using %zu bytes for %d objects", KFENCE_POOL_SIZE, > > > + CONFIG_KFENCE_NUM_OBJECTS); > > > + if (IS_ENABLED(CONFIG_DEBUG_KERNEL)) > > > + pr_cont(" at 0x%px-0x%px\n", (void *)__kfence_pool, > > > + (void *)(__kfence_pool + KFENCE_POOL_SIZE)); > > > > Why don't you use PTR_FMT that defined in 'kfence.h'? > > It's unnecessary, since all this is conditional on > IS_ENABLED(CONFIG_DEBUG_KERNEL)) and we can just avoid the indirection > through PTR_FMT. Ok, agreed. [...] > > > + for (skipnr = 0; skipnr < num_entries; skipnr++) { > > > + int len = scnprintf(buf, sizeof(buf), "%ps", (void *)stack_entries[skipnr]); > > > + > > > + /* Depending on error type, find different stack entries. */ > > > + switch (type) { > > > + case KFENCE_ERROR_UAF: > > > + case KFENCE_ERROR_OOB: > > > + case KFENCE_ERROR_INVALID: > > > + if (!strncmp(buf, KFENCE_SKIP_ARCH_FAULT_HANDLER, len)) > > > > Seems KFENCE_SKIP_ARCH_FAULT_HANDLER not defined yet? > > Correct, it'll be defined in <asm/kfence.h> in the x86 and arm64 > patches. Leaving this is fine, since no architecture has selected > HAVE_ARCH_KFENCE in this patch yet; as a result, we also can't break the > build even if this is undefined. Ah, got it. Thank you for the kind explanation. Thanks, SeongJae Park > > Thanks, > -- Marco
WARNING: multiple messages have this Message-ID (diff)
From: SeongJae Park <sjpark@amazon.com> To: Marco Elver <elver@google.com> Cc: mark.rutland@arm.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, will@kernel.org, keescook@chromium.org, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, aryabinin@virtuozzo.com, SeongJae Park <sjpark@amazon.com>, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, cai@lca.pw, luto@kernel.org, tglx@linutronix.de, iamjoonsoo.kim@lge.com, dvyukov@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, bp@alien8.de, akpm@linux-foundation.org Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Tue, 15 Sep 2020 16:26:31 +0200 [thread overview] Message-ID: <20200915142631.31234-1-sjpark@amazon.com> (raw) In-Reply-To: <20200915141449.GA3367763@elver.google.com> On Tue, 15 Sep 2020 16:14:49 +0200 Marco Elver <elver@google.com> wrote: > On Tue, Sep 15, 2020 at 03:57PM +0200, SeongJae Park wrote: > [...] > > > > So interesting feature! I left some tirvial comments below. > > Thank you! [...] > > > + > > > + /* Only call with a pointer into kfence_metadata. */ > > > + if (KFENCE_WARN_ON(meta < kfence_metadata || > > > + meta >= kfence_metadata + ARRAY_SIZE(kfence_metadata))) > > > > Is there a reason to use ARRAY_SIZE(kfence_metadata) instead of > > CONFIG_KFENCE_NUM_OBJECTS? > > They're equivalent. We can switch it. (Although I don't see one being > superior to the other.. maybe we save on compile-time?) I prefer CONFIG_KFENCE_NUM_OBJECTS here just because it's more widely used in the code. Also, I personally think it's more easy to read. [...] > > > + pr_info("initialized - using %zu bytes for %d objects", KFENCE_POOL_SIZE, > > > + CONFIG_KFENCE_NUM_OBJECTS); > > > + if (IS_ENABLED(CONFIG_DEBUG_KERNEL)) > > > + pr_cont(" at 0x%px-0x%px\n", (void *)__kfence_pool, > > > + (void *)(__kfence_pool + KFENCE_POOL_SIZE)); > > > > Why don't you use PTR_FMT that defined in 'kfence.h'? > > It's unnecessary, since all this is conditional on > IS_ENABLED(CONFIG_DEBUG_KERNEL)) and we can just avoid the indirection > through PTR_FMT. Ok, agreed. [...] > > > + for (skipnr = 0; skipnr < num_entries; skipnr++) { > > > + int len = scnprintf(buf, sizeof(buf), "%ps", (void *)stack_entries[skipnr]); > > > + > > > + /* Depending on error type, find different stack entries. */ > > > + switch (type) { > > > + case KFENCE_ERROR_UAF: > > > + case KFENCE_ERROR_OOB: > > > + case KFENCE_ERROR_INVALID: > > > + if (!strncmp(buf, KFENCE_SKIP_ARCH_FAULT_HANDLER, len)) > > > > Seems KFENCE_SKIP_ARCH_FAULT_HANDLER not defined yet? > > Correct, it'll be defined in <asm/kfence.h> in the x86 and arm64 > patches. Leaving this is fine, since no architecture has selected > HAVE_ARCH_KFENCE in this patch yet; as a result, we also can't break the > build even if this is undefined. Ah, got it. Thank you for the kind explanation. Thanks, SeongJae Park > > Thanks, > -- Marco _______________________________________________ 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-16 0:06 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 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 [this message] 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=20200915142631.31234-1-sjpark@amazon.com \ --to=sjpark@amazon.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=dvyukov@google.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.