From: Dave Hansen <dave.hansen@intel.com> To: Marco Elver <elver@google.com> Cc: glider@google.com, akpm@linux-foundation.org, catalin.marinas@arm.com, cl@linux.com, rientjes@google.com, iamjoonsoo.kim@lge.com, mark.rutland@arm.com, penberg@kernel.org, hpa@zytor.com, paulmck@kernel.org, andreyknvl@google.com, aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, dvyukov@google.com, edumazet@google.com, gregkh@linuxfoundation.org, mingo@redhat.com, jannh@google.com, corbet@lwn.net, keescook@chromium.org, peterz@infradead.org, cai@lca.pw, tglx@linutronix.de, will@kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Date: Tue, 8 Sep 2020 08:37:06 -0700 [thread overview] Message-ID: <64b65b4b-639c-ea99-182c-5091c5fa1938@intel.com> (raw) In-Reply-To: <20200908153102.GB61807@elver.google.com> On 9/8/20 8:31 AM, Marco Elver wrote: ... > If you can afford to use KASAN, continue using KASAN. Usually this only > applies to test environments. If you have kernels for production use, > and cannot enable KASAN for the obvious cost reasons, you could consider > KFENCE. That's a really nice, succinct way to put it. You might even want to consider putting this in the Kconfig help text. >>> KFENCE objects each reside on a dedicated page, at either the left or >>> right page boundaries. The pages to the left and right of the object >>> page are "guard pages", whose attributes are changed to a protected >>> state, and cause page faults on any attempted access to them. Such page >>> faults are then intercepted by KFENCE, which handles the fault >>> gracefully by reporting a memory access error. >> >> How much memory overhead does this end up having? I know it depends on >> the object size and so forth. But, could you give some real-world >> examples of memory consumption? Also, what's the worst case? Say I >> have a ton of worst-case-sized (32b) slab objects. Will I notice? > > KFENCE objects are limited (default 255). If we exhaust KFENCE's memory > pool, no more KFENCE allocations will occur. > Documentation/dev-tools/kfence.rst gives a formula to calculate the > KFENCE pool size: > > The total memory dedicated to the KFENCE memory pool can be computed as:: > > ( #objects + 1 ) * 2 * PAGE_SIZE > > Using the default config, and assuming a page size of 4 KiB, results in > dedicating 2 MiB to the KFENCE memory pool. > > Does that clarify this point? Or anything else that could help clarify > this? That clears it up, thanks! I would suggest adding a tiny nugget about this in the cover letter, just saying that the worst-case memory consumption on x86 is ~2M.
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.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, 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, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, cai@lca.pw, iamjoonsoo.kim@lge.com Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Date: Tue, 8 Sep 2020 08:37:06 -0700 [thread overview] Message-ID: <64b65b4b-639c-ea99-182c-5091c5fa1938@intel.com> (raw) In-Reply-To: <20200908153102.GB61807@elver.google.com> On 9/8/20 8:31 AM, Marco Elver wrote: ... > If you can afford to use KASAN, continue using KASAN. Usually this only > applies to test environments. If you have kernels for production use, > and cannot enable KASAN for the obvious cost reasons, you could consider > KFENCE. That's a really nice, succinct way to put it. You might even want to consider putting this in the Kconfig help text. >>> KFENCE objects each reside on a dedicated page, at either the left or >>> right page boundaries. The pages to the left and right of the object >>> page are "guard pages", whose attributes are changed to a protected >>> state, and cause page faults on any attempted access to them. Such page >>> faults are then intercepted by KFENCE, which handles the fault >>> gracefully by reporting a memory access error. >> >> How much memory overhead does this end up having? I know it depends on >> the object size and so forth. But, could you give some real-world >> examples of memory consumption? Also, what's the worst case? Say I >> have a ton of worst-case-sized (32b) slab objects. Will I notice? > > KFENCE objects are limited (default 255). If we exhaust KFENCE's memory > pool, no more KFENCE allocations will occur. > Documentation/dev-tools/kfence.rst gives a formula to calculate the > KFENCE pool size: > > The total memory dedicated to the KFENCE memory pool can be computed as:: > > ( #objects + 1 ) * 2 * PAGE_SIZE > > Using the default config, and assuming a page size of 4 KiB, results in > dedicating 2 MiB to the KFENCE memory pool. > > Does that clarify this point? Or anything else that could help clarify > this? That clears it up, thanks! I would suggest adding a tiny nugget about this in the cover letter, just saying that the worst-case memory consumption on x86 is ~2M. _______________________________________________ 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-08 15:41 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 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 [this message] 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=64b65b4b-639c-ea99-182c-5091c5fa1938@intel.com \ --to=dave.hansen@intel.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.