On Fri, 20 Jul 2018, Yang Shi wrote:
For users who run kernels earlier than 4.15 they may choose to mitigateWe disable the huge zero page through this interface, there were issuesThanks for the information. It looks the CVE has been resolved by commit
related to the huge zero page shrinker (probably best to never free a
per-node huge zero page after allocated) and CVE-2017-1000405 for huge
dirty COW.
a8f97366452ed491d13cf1e44241bc0b5740b1f0 ("mm, thp: Do not make page table
dirty unconditionally in touch_p[mu]d()"), which is in 4.15 already.
the CVE by using this tunable. It's not something we permanently need to
have, but it may likely be too early.
What was the shrinker related issue? I'm supposed it has been resolved, right?The huge zero page can be reclaimed under memory pressure and, if it is,
it is attempted to be allocted again with gfp flags that attempt memory
compaction that can become expensive. If we are constantly under memory
pressure, it gets freed and reallocated millions of times always trying to
compact memory both directly and by kicking kcompactd in the background.
It likely should also be per node.