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.
