[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e87490e-3145-da2e-4190-176017d0e099@intel.com>
Date: Tue, 8 Sep 2020 08:54:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Marco Elver <elver@...gle.com>, glider@...gle.com,
akpm@...ux-foundation.org, catalin.marinas@....com, cl@...ux.com,
rientjes@...gle.com, iamjoonsoo.kim@....com, mark.rutland@....com,
penberg@...nel.org
Cc: hpa@...or.com, paulmck@...nel.org, andreyknvl@...gle.com,
aryabinin@...tuozzo.com, luto@...nel.org, bp@...en8.de,
dave.hansen@...ux.intel.com, dvyukov@...gle.com,
edumazet@...gle.com, gregkh@...uxfoundation.org, mingo@...hat.com,
jannh@...gle.com, corbet@....net, keescook@...omium.org,
peterz@...radead.org, cai@....pw, tglx@...utronix.de,
will@...nel.org, x86@...nel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation
On 9/7/20 6:40 AM, Marco Elver wrote:
> +The most important parameter is KFENCE's sample interval, which can be set via
> +the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The
> +sample interval determines the frequency with which heap allocations will be
> +guarded by KFENCE. The default is configurable via the Kconfig option
> +``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0``
> +disables KFENCE.
> +
> +With the Kconfig option ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number
> +of available guarded objects can be controlled. Each object requires 2 pages,
> +one for the object itself and the other one used as a guard page; object pages
> +are interleaved with guard pages, and every object page is therefore surrounded
> +by two guard pages.
Is it hard to make these both tunable at runtime?
It would be nice if I hit a KFENCE error on a system to bump up the
number of objects and turn up the frequency of guarded objects to try to
hit it again. That would be a really nice feature for development
environments.
It would also be nice to have a counter somewhere (/proc/vmstat?) to
explicitly say how many pages are currently being used.
I didn't mention it elsewhere, but this work looks really nice. It has
very little impact on the core kernel and looks like a very nice tool to
have in the toolbox. I don't see any major reasons we wouldn't want to
merge after our typical bikeshedding. :)
Powered by blists - more mailing lists