On Fri, Apr 24, 2015 at 11:38 PM, David Rientjes <rient...@google.com> wrote: > On Fri, 24 Apr 2015, Anisse Astier wrote: > >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 390214d..cb2df5f 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -635,3 +635,15 @@ config MAX_STACK_SIZE_MB >> changed to a smaller value in which case that is used. >> >> A sane initial value is 80 MB. >> + >> +config SANITIZE_FREED_PAGES >> + bool "Sanitize memory pages after free" >> + default n >> + help >> + This option is used to make sure all pages freed are zeroed. This is >> + quite low-level and doesn't handle your slab buffers. >> + It has various applications, from preventing some info leaks to >> + helping kernel same-page merging in virtualised environments. >> + Depending on your workload, it will reduce performance of about 3%. >> + >> + If unsure, say N. > > Objection to allowing this without first enabling some other DEBUG config > option, it should never be a standalone option, but also to pretending to
I'm not sure I understand the rationale here. Is it to protect the innocent ? The performance warning and "N" recommendation ought to be enough. I'm not sure depending on DEBUG will help anyone; it will just hinder those who want to use this on a hardened system (where you might not want to have DEBUG enabled). > have any insight into what the performance degredation of it will be. On I fully agree I shouldn't have let the 3% ballpark estimate slip, I'll remove it. > my systems, this would be _massive_. I'm interested in what you mean by "massive". Have you conducted experiments on the impact or is just your gut feeling ? Anyway, I'd be curious to see numbers showing what it looks like on big hardware. Anisse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
