[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220307074516.6920-1-dtcccc@linux.alibaba.com>
Date: Mon, 7 Mar 2022 15:45:14 +0800
From: Tianchen Ding <dtcccc@...ux.alibaba.com>
To: Alexander Potapenko <glider@...gle.com>,
Marco Elver <elver@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: kasan-dev@...glegroups.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: [PATCH v3 0/2] provide the flexibility to enable KFENCE
This is v3 for (re-)enabling KFENCE.
If CONFIG_CONTIG_ALLOC is not supported, we fallback to try
alloc_pages_exact(). Allocating pages in this way has limits about
MAX_ORDER (default 11). So we will not support allocating kfence pool
after system startup with a large KFENCE_NUM_OBJECTS.
When handling failures in kfence_init_pool_late(), we pair
free_pages_exact() to alloc_pages_exact() for compatibility
consideration, though it actually does the same as free_contig_range().
v3:
Use alloc_pages_exact() instead of alloc_contig_pages()
if CONFIG_CONTIG_ALLOC is not defined.
v2: https://lore.kernel.org/all/20220305144858.17040-1-dtcccc@linux.alibaba.com/
Take KFENCE_WARN_ON() into account. Do not allow re-enabling KFENCE
if it once disabled by warn.
Modify func names and comments.
RFC/v1: https://lore.kernel.org/all/20220303031505.28495-1-dtcccc@linux.alibaba.com/
Tianchen Ding (2):
kfence: Allow re-enabling KFENCE after system startup
kfence: Alloc kfence_pool after system startup
mm/kfence/core.c | 126 +++++++++++++++++++++++++++++++++++++++--------
1 file changed, 105 insertions(+), 21 deletions(-)
--
2.27.0
Powered by blists - more mailing lists