I adapted the v2 patch to the latest linux-next tree and made the v3
patch without "RFC", since this idea seems to be acceptable in general
based on previous dicussion with mm and hardening folks. Please check
the link specified below for more details of the discussion, and further
suggestions are welcome.
v3:
- Replace SLAB_RANDOMSLAB with the new existing SLAB_NO_MERGE flag.
- Shorten long code lines by wrapping and renaming.
- Update commit message with latest perf benchmark and additional
theorectical explanation.
v2:
- Use hash_64() and a per-boot random seed to select kmalloc() caches.
- Change acceptable # of caches from [4,16] to {2,4,8,16}, which is
more compatible with hashing.
- Supplement results of performance and memory overhead tests.
- Link: https://lore.kernel.org/all/[email protected]/
v1:
- Link: https://lore.kernel.org/all/[email protected]/
GONG, Ruiqi (1):
Randomized slab caches for kmalloc()
include/linux/percpu.h | 12 ++++++---
include/linux/slab.h | 20 ++++++++++++---
mm/Kconfig | 49 ++++++++++++++++++++++++++++++++++++
mm/kfence/kfence_test.c | 6 +++--
mm/slab.c | 2 +-
mm/slab.h | 2 +-
mm/slab_common.c | 55 +++++++++++++++++++++++++++++++++++++----
7 files changed, 130 insertions(+), 16 deletions(-)
--
2.25.1
On 2023/06/23 16:30, Markus Elfring wrote:
>> I adapted the v2 patch to …
>
> I suggest to omit the cover letter for a single patch.
>
> Will any patch series evolve for your proposed changes?
>
Usually I wouldn't made a cover letter for a single patch, while this
case is an exception because I need a place to hold the additional
explanation about its transformation from RFC patch to formal patch.
> Regards,
> Markus