License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2012-07-06 20:25:11 +00:00
|
|
|
#ifndef MM_SLAB_H
|
|
|
|
#define MM_SLAB_H
|
|
|
|
/*
|
|
|
|
* Internal slab definitions
|
|
|
|
*/
|
2023-03-21 17:05:11 +00:00
|
|
|
void __init kmem_cache_init(void);
|
2012-07-06 20:25:11 +00:00
|
|
|
|
2023-05-31 13:08:43 +00:00
|
|
|
#ifdef CONFIG_64BIT
|
|
|
|
# ifdef system_has_cmpxchg128
|
|
|
|
# define system_has_freelist_aba() system_has_cmpxchg128()
|
|
|
|
# define try_cmpxchg_freelist try_cmpxchg128
|
|
|
|
# endif
|
|
|
|
#define this_cpu_try_cmpxchg_freelist this_cpu_try_cmpxchg128
|
|
|
|
typedef u128 freelist_full_t;
|
|
|
|
#else /* CONFIG_64BIT */
|
|
|
|
# ifdef system_has_cmpxchg64
|
|
|
|
# define system_has_freelist_aba() system_has_cmpxchg64()
|
|
|
|
# define try_cmpxchg_freelist try_cmpxchg64
|
|
|
|
# endif
|
|
|
|
#define this_cpu_try_cmpxchg_freelist this_cpu_try_cmpxchg64
|
|
|
|
typedef u64 freelist_full_t;
|
|
|
|
#endif /* CONFIG_64BIT */
|
|
|
|
|
|
|
|
#if defined(system_has_freelist_aba) && !defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
|
|
|
|
#undef system_has_freelist_aba
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Freelist pointer and counter to cmpxchg together, avoids the typical ABA
|
|
|
|
* problems with cmpxchg of just a pointer.
|
|
|
|
*/
|
|
|
|
typedef union {
|
|
|
|
struct {
|
|
|
|
void *freelist;
|
|
|
|
unsigned long counter;
|
|
|
|
};
|
|
|
|
freelist_full_t full;
|
|
|
|
} freelist_aba_t;
|
|
|
|
|
2021-10-04 13:45:51 +00:00
|
|
|
/* Reuses the bits in struct page */
|
|
|
|
struct slab {
|
|
|
|
unsigned long __page_flags;
|
2021-11-04 10:30:58 +00:00
|
|
|
|
|
|
|
#if defined(CONFIG_SLAB)
|
|
|
|
|
2022-08-26 09:09:12 +00:00
|
|
|
struct kmem_cache *slab_cache;
|
2021-10-04 13:45:51 +00:00
|
|
|
union {
|
2022-08-26 09:09:12 +00:00
|
|
|
struct {
|
|
|
|
struct list_head slab_list;
|
|
|
|
void *freelist; /* array of free object indexes */
|
|
|
|
void *s_mem; /* first object */
|
|
|
|
};
|
2021-11-04 10:30:58 +00:00
|
|
|
struct rcu_head rcu_head;
|
|
|
|
};
|
|
|
|
unsigned int active;
|
|
|
|
|
|
|
|
#elif defined(CONFIG_SLUB)
|
|
|
|
|
|
|
|
struct kmem_cache *slab_cache;
|
2021-10-04 13:45:51 +00:00
|
|
|
union {
|
2021-11-04 10:30:58 +00:00
|
|
|
struct {
|
2022-08-26 09:09:12 +00:00
|
|
|
union {
|
|
|
|
struct list_head slab_list;
|
|
|
|
#ifdef CONFIG_SLUB_CPU_PARTIAL
|
|
|
|
struct {
|
|
|
|
struct slab *next;
|
|
|
|
int slabs; /* Nr of slabs left */
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
/* Double-word boundary */
|
|
|
|
union {
|
|
|
|
struct {
|
2023-05-31 13:08:43 +00:00
|
|
|
void *freelist; /* first free object */
|
|
|
|
union {
|
|
|
|
unsigned long counters;
|
|
|
|
struct {
|
|
|
|
unsigned inuse:16;
|
|
|
|
unsigned objects:15;
|
|
|
|
unsigned frozen:1;
|
|
|
|
};
|
|
|
|
};
|
2022-08-26 09:09:12 +00:00
|
|
|
};
|
2023-05-31 13:08:43 +00:00
|
|
|
#ifdef system_has_freelist_aba
|
|
|
|
freelist_aba_t freelist_counter;
|
|
|
|
#endif
|
2022-08-26 09:09:12 +00:00
|
|
|
};
|
2021-10-04 13:45:51 +00:00
|
|
|
};
|
2022-08-26 09:09:12 +00:00
|
|
|
struct rcu_head rcu_head;
|
2021-10-04 13:45:51 +00:00
|
|
|
};
|
2021-11-04 10:30:58 +00:00
|
|
|
unsigned int __unused;
|
|
|
|
|
|
|
|
#else
|
|
|
|
#error "Unexpected slab allocator configured"
|
|
|
|
#endif
|
2021-10-04 13:45:51 +00:00
|
|
|
|
|
|
|
atomic_t __page_refcount;
|
|
|
|
#ifdef CONFIG_MEMCG
|
|
|
|
unsigned long memcg_data;
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
#define SLAB_MATCH(pg, sl) \
|
|
|
|
static_assert(offsetof(struct page, pg) == offsetof(struct slab, sl))
|
|
|
|
SLAB_MATCH(flags, __page_flags);
|
2022-08-26 09:09:12 +00:00
|
|
|
SLAB_MATCH(compound_head, slab_cache); /* Ensure bit 0 is clear */
|
2021-10-04 13:45:51 +00:00
|
|
|
SLAB_MATCH(_refcount, __page_refcount);
|
|
|
|
#ifdef CONFIG_MEMCG
|
|
|
|
SLAB_MATCH(memcg_data, memcg_data);
|
|
|
|
#endif
|
|
|
|
#undef SLAB_MATCH
|
|
|
|
static_assert(sizeof(struct slab) <= sizeof(struct page));
|
2023-05-31 13:08:43 +00:00
|
|
|
#if defined(system_has_freelist_aba) && defined(CONFIG_SLUB)
|
|
|
|
static_assert(IS_ALIGNED(offsetof(struct slab, freelist), sizeof(freelist_aba_t)));
|
2022-08-26 09:09:12 +00:00
|
|
|
#endif
|
2021-10-04 13:45:51 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* folio_slab - Converts from folio to slab.
|
|
|
|
* @folio: The folio.
|
|
|
|
*
|
|
|
|
* Currently struct slab is a different representation of a folio where
|
|
|
|
* folio_test_slab() is true.
|
|
|
|
*
|
|
|
|
* Return: The slab which contains this folio.
|
|
|
|
*/
|
|
|
|
#define folio_slab(folio) (_Generic((folio), \
|
|
|
|
const struct folio *: (const struct slab *)(folio), \
|
|
|
|
struct folio *: (struct slab *)(folio)))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* slab_folio - The folio allocated for a slab
|
|
|
|
* @slab: The slab.
|
|
|
|
*
|
|
|
|
* Slabs are allocated as folios that contain the individual objects and are
|
|
|
|
* using some fields in the first struct page of the folio - those fields are
|
|
|
|
* now accessed by struct slab. It is occasionally necessary to convert back to
|
|
|
|
* a folio in order to communicate with the rest of the mm. Please use this
|
|
|
|
* helper function instead of casting yourself, as the implementation may change
|
|
|
|
* in the future.
|
|
|
|
*/
|
|
|
|
#define slab_folio(s) (_Generic((s), \
|
|
|
|
const struct slab *: (const struct folio *)s, \
|
|
|
|
struct slab *: (struct folio *)s))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* page_slab - Converts from first struct page to slab.
|
|
|
|
* @p: The first (either head of compound or single) page of slab.
|
|
|
|
*
|
|
|
|
* A temporary wrapper to convert struct page to struct slab in situations where
|
|
|
|
* we know the page is the compound head, or single order-0 page.
|
|
|
|
*
|
|
|
|
* Long-term ideally everything would work with struct slab directly or go
|
|
|
|
* through folio to struct slab.
|
|
|
|
*
|
|
|
|
* Return: The slab which contains this page
|
|
|
|
*/
|
|
|
|
#define page_slab(p) (_Generic((p), \
|
|
|
|
const struct page *: (const struct slab *)(p), \
|
|
|
|
struct page *: (struct slab *)(p)))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* slab_page - The first struct page allocated for a slab
|
|
|
|
* @slab: The slab.
|
|
|
|
*
|
|
|
|
* A convenience wrapper for converting slab to the first struct page of the
|
|
|
|
* underlying folio, to communicate with code not yet converted to folio or
|
|
|
|
* struct slab.
|
|
|
|
*/
|
|
|
|
#define slab_page(s) folio_page(slab_folio(s), 0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If network-based swap is enabled, sl*b must keep track of whether pages
|
|
|
|
* were allocated from pfmemalloc reserves.
|
|
|
|
*/
|
|
|
|
static inline bool slab_test_pfmemalloc(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return folio_test_active((struct folio *)slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void slab_set_pfmemalloc(struct slab *slab)
|
|
|
|
{
|
|
|
|
folio_set_active(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void slab_clear_pfmemalloc(struct slab *slab)
|
|
|
|
{
|
|
|
|
folio_clear_active(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __slab_clear_pfmemalloc(struct slab *slab)
|
|
|
|
{
|
|
|
|
__folio_clear_active(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *slab_address(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return folio_address(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int slab_nid(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return folio_nid(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline pg_data_t *slab_pgdat(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return folio_pgdat(slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct slab *virt_to_slab(const void *addr)
|
|
|
|
{
|
|
|
|
struct folio *folio = virt_to_folio(addr);
|
|
|
|
|
|
|
|
if (!folio_test_slab(folio))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return folio_slab(folio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int slab_order(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return folio_order((struct folio *)slab_folio(slab));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline size_t slab_size(const struct slab *slab)
|
|
|
|
{
|
|
|
|
return PAGE_SIZE << slab_order(slab);
|
|
|
|
}
|
|
|
|
|
2014-10-09 22:26:00 +00:00
|
|
|
#ifdef CONFIG_SLAB
|
|
|
|
#include <linux/slab_def.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SLUB
|
|
|
|
#include <linux/slub_def.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <linux/memcontrol.h>
|
2016-03-15 21:53:35 +00:00
|
|
|
#include <linux/fault-inject.h>
|
|
|
|
#include <linux/kasan.h>
|
|
|
|
#include <linux/kmemleak.h>
|
2016-07-26 22:21:56 +00:00
|
|
|
#include <linux/random.h>
|
2017-03-03 09:13:38 +00:00
|
|
|
#include <linux/sched/mm.h>
|
2022-03-22 21:40:56 +00:00
|
|
|
#include <linux/list_lru.h>
|
2014-10-09 22:26:00 +00:00
|
|
|
|
2012-07-06 20:25:11 +00:00
|
|
|
/*
|
|
|
|
* State of the slab allocator.
|
|
|
|
*
|
|
|
|
* This is used to describe the states of the allocator during bootup.
|
|
|
|
* Allocators use this to gradually bootstrap themselves. Most allocators
|
|
|
|
* have the problem that the structures used for managing slab caches are
|
|
|
|
* allocated from slab caches themselves.
|
|
|
|
*/
|
|
|
|
enum slab_state {
|
|
|
|
DOWN, /* No slab functionality yet */
|
|
|
|
PARTIAL, /* SLUB: kmem_cache_node available */
|
2013-01-10 19:14:19 +00:00
|
|
|
PARTIAL_NODE, /* SLAB: kmalloc size for node struct available */
|
2012-07-06 20:25:11 +00:00
|
|
|
UP, /* Slab caches usable but not all extras yet */
|
|
|
|
FULL /* Everything is working */
|
|
|
|
};
|
|
|
|
|
|
|
|
extern enum slab_state slab_state;
|
|
|
|
|
2012-07-06 20:25:12 +00:00
|
|
|
/* The slab cache mutex protects the management structures during changes */
|
|
|
|
extern struct mutex slab_mutex;
|
2012-09-05 00:20:33 +00:00
|
|
|
|
|
|
|
/* The list of all slab caches on the system */
|
2012-07-06 20:25:12 +00:00
|
|
|
extern struct list_head slab_caches;
|
|
|
|
|
2012-09-05 00:20:33 +00:00
|
|
|
/* The slab cache that manages slab cache information */
|
|
|
|
extern struct kmem_cache *kmem_cache;
|
|
|
|
|
2017-02-22 23:41:05 +00:00
|
|
|
/* A table of kmalloc cache names and sizes */
|
|
|
|
extern const struct kmalloc_info_struct {
|
mm, slab: make kmalloc_info[] contain all types of names
Patch series "mm, slab: Make kmalloc_info[] contain all types of names", v6.
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
Patch1 predefines the names of all types of kmalloc to save
the time spent dynamically generating names.
These changes make sense, and the time spent by new_kmalloc_cache()
has been reduced by approximately 36.3%.
Time spent by new_kmalloc_cache()
(CPU cycles)
5.3-rc7 66264
5.3-rc7+patch 42188
This patch (of 3):
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM and
KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name, but the
names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically generated by
kmalloc_cache_name().
This patch predefines the names of all types of kmalloc to save the time
spent dynamically generating names.
Besides, remove the kmalloc_cache_name() that is no longer used.
Link: http://lkml.kernel.org/r/1569241648-26908-2-git-send-email-lpf.vector@gmail.com
Signed-off-by: Pengfei Li <lpf.vector@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Roman Gushchin <guro@fb.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-01 01:49:21 +00:00
|
|
|
const char *name[NR_KMALLOC_TYPES];
|
2018-04-05 23:20:29 +00:00
|
|
|
unsigned int size;
|
2017-02-22 23:41:05 +00:00
|
|
|
} kmalloc_info[];
|
|
|
|
|
2013-01-10 19:12:17 +00:00
|
|
|
/* Kmalloc array related functions */
|
2015-06-24 23:55:57 +00:00
|
|
|
void setup_kmalloc_cache_index_table(void);
|
2017-11-16 01:32:18 +00:00
|
|
|
void create_kmalloc_caches(slab_flags_t);
|
2013-01-10 19:14:19 +00:00
|
|
|
|
|
|
|
/* Find the kmalloc slab corresponding for a certain size */
|
Randomized slab caches for kmalloc()
When exploiting memory vulnerabilities, "heap spraying" is a common
technique targeting those related to dynamic memory allocation (i.e. the
"heap"), and it plays an important role in a successful exploitation.
Basically, it is to overwrite the memory area of vulnerable object by
triggering allocation in other subsystems or modules and therefore
getting a reference to the targeted memory location. It's usable on
various types of vulnerablity including use after free (UAF), heap out-
of-bound write and etc.
There are (at least) two reasons why the heap can be sprayed: 1) generic
slab caches are shared among different subsystems and modules, and
2) dedicated slab caches could be merged with the generic ones.
Currently these two factors cannot be prevented at a low cost: the first
one is a widely used memory allocation mechanism, and shutting down slab
merging completely via `slub_nomerge` would be overkill.
To efficiently prevent heap spraying, we propose the following approach:
to create multiple copies of generic slab caches that will never be
merged, and random one of them will be used at allocation. The random
selection is based on the address of code that calls `kmalloc()`, which
means it is static at runtime (rather than dynamically determined at
each time of allocation, which could be bypassed by repeatedly spraying
in brute force). In other words, the randomness of cache selection will
be with respect to the code address rather than time, i.e. allocations
in different code paths would most likely pick different caches,
although kmalloc() at each place would use the same cache copy whenever
it is executed. In this way, the vulnerable object and memory allocated
in other subsystems and modules will (most probably) be on different
slab caches, which prevents the object from being sprayed.
Meanwhile, the static random selection is further enhanced with a
per-boot random seed, which prevents the attacker from finding a usable
kmalloc that happens to pick the same cache with the vulnerable
subsystem/module by analyzing the open source code. In other words, with
the per-boot seed, the random selection is static during each time the
system starts and runs, but not across different system startups.
The overhead of performance has been tested on a 40-core x86 server by
comparing the results of `perf bench all` between the kernels with and
without this patch based on the latest linux-next kernel, which shows
minor difference. A subset of benchmarks are listed below:
sched/ sched/ syscall/ mem/ mem/
messaging pipe basic memcpy memset
(sec) (sec) (sec) (GB/sec) (GB/sec)
control1 0.019 5.459 0.733 15.258789 51.398026
control2 0.019 5.439 0.730 16.009221 48.828125
control3 0.019 5.282 0.735 16.009221 48.828125
control_avg 0.019 5.393 0.733 15.759077 49.684759
experiment1 0.019 5.374 0.741 15.500992 46.502976
experiment2 0.019 5.440 0.746 16.276042 51.398026
experiment3 0.019 5.242 0.752 15.258789 51.398026
experiment_avg 0.019 5.352 0.746 15.678608 49.766343
The overhead of memory usage was measured by executing `free` after boot
on a QEMU VM with 1GB total memory, and as expected, it's positively
correlated with # of cache copies:
control 4 copies 8 copies 16 copies
total 969.8M 968.2M 968.2M 968.2M
used 20.0M 21.9M 24.1M 26.7M
free 936.9M 933.6M 931.4M 928.6M
available 932.2M 928.8M 926.6M 923.9M
Co-developed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: GONG, Ruiqi <gongruiqi@huaweicloud.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Acked-by: Dennis Zhou <dennis@kernel.org> # percpu
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2023-07-14 06:44:22 +00:00
|
|
|
struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags, unsigned long caller);
|
2022-08-17 10:18:20 +00:00
|
|
|
|
|
|
|
void *__kmem_cache_alloc_node(struct kmem_cache *s, gfp_t gfpflags,
|
|
|
|
int node, size_t orig_size,
|
|
|
|
unsigned long caller);
|
|
|
|
void __kmem_cache_free(struct kmem_cache *s, void *x, unsigned long caller);
|
2013-01-10 19:12:17 +00:00
|
|
|
|
2020-08-07 06:18:28 +00:00
|
|
|
gfp_t kmalloc_fix_flags(gfp_t flags);
|
2013-01-10 19:12:17 +00:00
|
|
|
|
2012-09-05 00:20:33 +00:00
|
|
|
/* Functions provided by the slab allocators */
|
2017-11-16 01:32:18 +00:00
|
|
|
int __kmem_cache_create(struct kmem_cache *, slab_flags_t flags);
|
2012-07-06 20:25:11 +00:00
|
|
|
|
2023-06-12 15:31:47 +00:00
|
|
|
void __init new_kmalloc_cache(int idx, enum kmalloc_cache_type type,
|
|
|
|
slab_flags_t flags);
|
2012-11-28 16:23:07 +00:00
|
|
|
extern void create_boot_cache(struct kmem_cache *, const char *name,
|
2018-04-05 23:20:33 +00:00
|
|
|
unsigned int size, slab_flags_t flags,
|
|
|
|
unsigned int useroffset, unsigned int usersize);
|
2012-11-28 16:23:07 +00:00
|
|
|
|
2014-10-09 22:26:22 +00:00
|
|
|
int slab_unmergeable(struct kmem_cache *s);
|
2018-04-05 23:20:37 +00:00
|
|
|
struct kmem_cache *find_mergeable(unsigned size, unsigned align,
|
2017-11-16 01:32:18 +00:00
|
|
|
slab_flags_t flags, const char *name, void (*ctor)(void *));
|
2012-12-18 22:22:34 +00:00
|
|
|
struct kmem_cache *
|
2018-04-05 23:20:37 +00:00
|
|
|
__kmem_cache_alias(const char *name, unsigned int size, unsigned int align,
|
2017-11-16 01:32:18 +00:00
|
|
|
slab_flags_t flags, void (*ctor)(void *));
|
2014-10-09 22:26:22 +00:00
|
|
|
|
2018-04-05 23:21:24 +00:00
|
|
|
slab_flags_t kmem_cache_flags(unsigned int object_size,
|
2021-02-24 20:00:58 +00:00
|
|
|
slab_flags_t flags, const char *name);
|
2012-09-05 00:18:32 +00:00
|
|
|
|
2023-01-04 06:06:04 +00:00
|
|
|
static inline bool is_kmalloc_cache(struct kmem_cache *s)
|
|
|
|
{
|
|
|
|
return (s->flags & SLAB_KMALLOC);
|
|
|
|
}
|
2012-09-05 00:18:32 +00:00
|
|
|
|
2012-10-17 11:36:51 +00:00
|
|
|
/* Legal flag mask for kmem_cache_create(), for various configurations */
|
mm: add support for kmem caches in DMA32 zone
Patch series "iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables",
v6.
This is a followup to the discussion in [1], [2].
IOMMUs using ARMv7 short-descriptor format require page tables (level 1
and 2) to be allocated within the first 4GB of RAM, even on 64-bit
systems.
For L1 tables that are bigger than a page, we can just use
__get_free_pages with GFP_DMA32 (on arm64 systems only, arm would still
use GFP_DMA).
For L2 tables that only take 1KB, it would be a waste to allocate a full
page, so we considered 3 approaches:
1. This series, adding support for GFP_DMA32 slab caches.
2. genalloc, which requires pre-allocating the maximum number of L2 page
tables (4096, so 4MB of memory).
3. page_frag, which is not very memory-efficient as it is unable to reuse
freed fragments until the whole page is freed. [3]
This series is the most memory-efficient approach.
stable@ note:
We confirmed that this is a regression, and IOMMU errors happen on 4.19
and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
most likely starts from commit ad67f5a6545f ("arm64: replace ZONE_DMA
with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
platforms (and maybe others?).
[1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
[2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
[3] https://patchwork.codeaurora.org/patch/671639/
This patch (of 3):
IOMMUs using ARMv7 short-descriptor format require page tables to be
allocated within the first 4GB of RAM, even on 64-bit systems. On arm64,
this is done by passing GFP_DMA32 flag to memory allocation functions.
For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
a full page using get_free_pages, so we considered 3 approaches:
1. This patch, adding support for GFP_DMA32 slab caches.
2. genalloc, which requires pre-allocating the maximum number of L2
page tables (4096, so 4MB of memory).
3. page_frag, which is not very memory-efficient as it is unable
to reuse freed fragments until the whole page is freed.
This change makes it possible to create a custom cache in DMA32 zone using
kmem_cache_create, then allocate memory using kmem_cache_alloc.
We do not create a DMA32 kmalloc cache array, as there are currently no
users of kmalloc(..., GFP_DMA32). These calls will continue to trigger a
warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
unnecessary).
Link: http://lkml.kernel.org/r/20181210011504.122604-2-drinkcat@chromium.org
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Sasha Levin <Alexander.Levin@microsoft.com>
Cc: Huaisheng Ye <yehs1@lenovo.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Tomasz Figa <tfiga@google.com>
Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-29 03:43:42 +00:00
|
|
|
#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | \
|
|
|
|
SLAB_CACHE_DMA32 | SLAB_PANIC | \
|
2017-01-18 10:53:44 +00:00
|
|
|
SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS )
|
2012-10-17 11:36:51 +00:00
|
|
|
|
|
|
|
#if defined(CONFIG_DEBUG_SLAB)
|
|
|
|
#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
|
|
|
|
#elif defined(CONFIG_SLUB_DEBUG)
|
|
|
|
#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
|
2016-03-15 21:55:06 +00:00
|
|
|
SLAB_TRACE | SLAB_CONSISTENCY_CHECKS)
|
2012-10-17 11:36:51 +00:00
|
|
|
#else
|
|
|
|
#define SLAB_DEBUG_FLAGS (0)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(CONFIG_SLAB)
|
|
|
|
#define SLAB_CACHE_FLAGS (SLAB_MEM_SPREAD | SLAB_NOLEAKTRACE | \
|
2016-01-14 23:18:15 +00:00
|
|
|
SLAB_RECLAIM_ACCOUNT | SLAB_TEMPORARY | \
|
mm/slab: introduce kmem_cache flag SLAB_NO_MERGE
Allow API users of kmem_cache_create to specify that they don't want
any slab merge or aliasing (with similar sized objects). Use this in
kfence_test.
The SKB (sk_buff) kmem_cache slab is critical for network performance.
Network stack uses kmem_cache_{alloc,free}_bulk APIs to gain
performance by amortising the alloc/free cost.
For the bulk API to perform efficiently the slub fragmentation need to
be low. Especially for the SLUB allocator, the efficiency of bulk free
API depend on objects belonging to the same slab (page).
When running different network performance microbenchmarks, I started
to notice that performance was reduced (slightly) when machines had
longer uptimes. I believe the cause was 'skbuff_head_cache' got
aliased/merged into the general slub for 256 bytes sized objects (with
my kernel config, without CONFIG_HARDENED_USERCOPY).
For SKB kmem_cache network stack have reasons for not merging, but it
varies depending on kernel config (e.g. CONFIG_HARDENED_USERCOPY).
We want to explicitly set SLAB_NO_MERGE for this kmem_cache.
Another use case for the flag has been described by David Sterba [1]:
> This can be used for more fine grained control over the caches or for
> debugging builds where separate slabs can verify that no objects leak.
> The slab_nomerge boot option is too coarse and would need to be
> enabled on all testing hosts. There are some other ways how to disable
> merging, e.g. a slab constructor but this disables poisoning besides
> that it adds additional overhead. Other flags are internal and may
> have other semantics.
> A concrete example what motivates the flag. During 'btrfs balance'
> slab top reported huge increase in caches like
> 1330095 1330095 100% 0.10K 34105 39 136420K Acpi-ParseExt
> 1734684 1734684 100% 0.14K 61953 28 247812K pid_namespace
> 8244036 6873075 83% 0.11K 229001 36 916004K khugepaged_mm_slot
> which was confusing and that it's because of slab merging was not the
> first idea. After rebooting with slab_nomerge all the caches were
> from btrfs_ namespace as expected.
[1] https://lore.kernel.org/all/20230524101748.30714-1-dsterba@suse.com/
[ vbabka@suse.cz: rename to SLAB_NO_MERGE, change the flag value to the
one proposed by David so it does not collide with internal SLAB/SLUB
flags, write a comment for the flag, expand changelog, drop the skbuff
part to be handled spearately ]
Link: https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/
Reported-by: David Sterba <dsterba@suse.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
2023-01-17 13:40:00 +00:00
|
|
|
SLAB_ACCOUNT | SLAB_NO_MERGE)
|
2012-10-17 11:36:51 +00:00
|
|
|
#elif defined(CONFIG_SLUB)
|
|
|
|
#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE | SLAB_RECLAIM_ACCOUNT | \
|
2022-11-30 08:54:51 +00:00
|
|
|
SLAB_TEMPORARY | SLAB_ACCOUNT | \
|
mm/slab: introduce kmem_cache flag SLAB_NO_MERGE
Allow API users of kmem_cache_create to specify that they don't want
any slab merge or aliasing (with similar sized objects). Use this in
kfence_test.
The SKB (sk_buff) kmem_cache slab is critical for network performance.
Network stack uses kmem_cache_{alloc,free}_bulk APIs to gain
performance by amortising the alloc/free cost.
For the bulk API to perform efficiently the slub fragmentation need to
be low. Especially for the SLUB allocator, the efficiency of bulk free
API depend on objects belonging to the same slab (page).
When running different network performance microbenchmarks, I started
to notice that performance was reduced (slightly) when machines had
longer uptimes. I believe the cause was 'skbuff_head_cache' got
aliased/merged into the general slub for 256 bytes sized objects (with
my kernel config, without CONFIG_HARDENED_USERCOPY).
For SKB kmem_cache network stack have reasons for not merging, but it
varies depending on kernel config (e.g. CONFIG_HARDENED_USERCOPY).
We want to explicitly set SLAB_NO_MERGE for this kmem_cache.
Another use case for the flag has been described by David Sterba [1]:
> This can be used for more fine grained control over the caches or for
> debugging builds where separate slabs can verify that no objects leak.
> The slab_nomerge boot option is too coarse and would need to be
> enabled on all testing hosts. There are some other ways how to disable
> merging, e.g. a slab constructor but this disables poisoning besides
> that it adds additional overhead. Other flags are internal and may
> have other semantics.
> A concrete example what motivates the flag. During 'btrfs balance'
> slab top reported huge increase in caches like
> 1330095 1330095 100% 0.10K 34105 39 136420K Acpi-ParseExt
> 1734684 1734684 100% 0.14K 61953 28 247812K pid_namespace
> 8244036 6873075 83% 0.11K 229001 36 916004K khugepaged_mm_slot
> which was confusing and that it's because of slab merging was not the
> first idea. After rebooting with slab_nomerge all the caches were
> from btrfs_ namespace as expected.
[1] https://lore.kernel.org/all/20230524101748.30714-1-dsterba@suse.com/
[ vbabka@suse.cz: rename to SLAB_NO_MERGE, change the flag value to the
one proposed by David so it does not collide with internal SLAB/SLUB
flags, write a comment for the flag, expand changelog, drop the skbuff
part to be handled spearately ]
Link: https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/
Reported-by: David Sterba <dsterba@suse.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
2023-01-17 13:40:00 +00:00
|
|
|
SLAB_NO_USER_FLAGS | SLAB_KMALLOC | SLAB_NO_MERGE)
|
2012-10-17 11:36:51 +00:00
|
|
|
#else
|
2021-11-20 00:43:37 +00:00
|
|
|
#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE)
|
2012-10-17 11:36:51 +00:00
|
|
|
#endif
|
|
|
|
|
2016-12-13 00:41:38 +00:00
|
|
|
/* Common flags available with current configuration */
|
2012-10-17 11:36:51 +00:00
|
|
|
#define CACHE_CREATE_MASK (SLAB_CORE_FLAGS | SLAB_DEBUG_FLAGS | SLAB_CACHE_FLAGS)
|
|
|
|
|
2016-12-13 00:41:38 +00:00
|
|
|
/* Common flags permitted for kmem_cache_create */
|
|
|
|
#define SLAB_FLAGS_PERMITTED (SLAB_CORE_FLAGS | \
|
|
|
|
SLAB_RED_ZONE | \
|
|
|
|
SLAB_POISON | \
|
|
|
|
SLAB_STORE_USER | \
|
|
|
|
SLAB_TRACE | \
|
|
|
|
SLAB_CONSISTENCY_CHECKS | \
|
|
|
|
SLAB_MEM_SPREAD | \
|
|
|
|
SLAB_NOLEAKTRACE | \
|
|
|
|
SLAB_RECLAIM_ACCOUNT | \
|
|
|
|
SLAB_TEMPORARY | \
|
2022-04-06 06:00:03 +00:00
|
|
|
SLAB_ACCOUNT | \
|
2022-11-30 08:54:51 +00:00
|
|
|
SLAB_KMALLOC | \
|
mm/slab: introduce kmem_cache flag SLAB_NO_MERGE
Allow API users of kmem_cache_create to specify that they don't want
any slab merge or aliasing (with similar sized objects). Use this in
kfence_test.
The SKB (sk_buff) kmem_cache slab is critical for network performance.
Network stack uses kmem_cache_{alloc,free}_bulk APIs to gain
performance by amortising the alloc/free cost.
For the bulk API to perform efficiently the slub fragmentation need to
be low. Especially for the SLUB allocator, the efficiency of bulk free
API depend on objects belonging to the same slab (page).
When running different network performance microbenchmarks, I started
to notice that performance was reduced (slightly) when machines had
longer uptimes. I believe the cause was 'skbuff_head_cache' got
aliased/merged into the general slub for 256 bytes sized objects (with
my kernel config, without CONFIG_HARDENED_USERCOPY).
For SKB kmem_cache network stack have reasons for not merging, but it
varies depending on kernel config (e.g. CONFIG_HARDENED_USERCOPY).
We want to explicitly set SLAB_NO_MERGE for this kmem_cache.
Another use case for the flag has been described by David Sterba [1]:
> This can be used for more fine grained control over the caches or for
> debugging builds where separate slabs can verify that no objects leak.
> The slab_nomerge boot option is too coarse and would need to be
> enabled on all testing hosts. There are some other ways how to disable
> merging, e.g. a slab constructor but this disables poisoning besides
> that it adds additional overhead. Other flags are internal and may
> have other semantics.
> A concrete example what motivates the flag. During 'btrfs balance'
> slab top reported huge increase in caches like
> 1330095 1330095 100% 0.10K 34105 39 136420K Acpi-ParseExt
> 1734684 1734684 100% 0.14K 61953 28 247812K pid_namespace
> 8244036 6873075 83% 0.11K 229001 36 916004K khugepaged_mm_slot
> which was confusing and that it's because of slab merging was not the
> first idea. After rebooting with slab_nomerge all the caches were
> from btrfs_ namespace as expected.
[1] https://lore.kernel.org/all/20230524101748.30714-1-dsterba@suse.com/
[ vbabka@suse.cz: rename to SLAB_NO_MERGE, change the flag value to the
one proposed by David so it does not collide with internal SLAB/SLUB
flags, write a comment for the flag, expand changelog, drop the skbuff
part to be handled spearately ]
Link: https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/
Reported-by: David Sterba <dsterba@suse.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
2023-01-17 13:40:00 +00:00
|
|
|
SLAB_NO_MERGE | \
|
2022-04-06 06:00:03 +00:00
|
|
|
SLAB_NO_USER_FLAGS)
|
2016-12-13 00:41:38 +00:00
|
|
|
|
2018-04-05 23:21:57 +00:00
|
|
|
bool __kmem_cache_empty(struct kmem_cache *);
|
2012-09-04 23:18:33 +00:00
|
|
|
int __kmem_cache_shutdown(struct kmem_cache *);
|
2016-02-17 21:11:37 +00:00
|
|
|
void __kmem_cache_release(struct kmem_cache *);
|
2017-02-22 23:41:27 +00:00
|
|
|
int __kmem_cache_shrink(struct kmem_cache *);
|
2014-05-06 19:50:08 +00:00
|
|
|
void slab_kmem_cache_release(struct kmem_cache *);
|
2012-09-04 23:18:33 +00:00
|
|
|
|
2012-10-19 14:20:25 +00:00
|
|
|
struct seq_file;
|
|
|
|
struct file;
|
|
|
|
|
2012-10-19 14:20:27 +00:00
|
|
|
struct slabinfo {
|
|
|
|
unsigned long active_objs;
|
|
|
|
unsigned long num_objs;
|
|
|
|
unsigned long active_slabs;
|
|
|
|
unsigned long num_slabs;
|
|
|
|
unsigned long shared_avail;
|
|
|
|
unsigned int limit;
|
|
|
|
unsigned int batchcount;
|
|
|
|
unsigned int shared;
|
|
|
|
unsigned int objects_per_slab;
|
|
|
|
unsigned int cache_order;
|
|
|
|
};
|
|
|
|
|
|
|
|
void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo);
|
|
|
|
void slabinfo_show_stats(struct seq_file *m, struct kmem_cache *s);
|
2012-10-19 14:20:25 +00:00
|
|
|
ssize_t slabinfo_write(struct file *file, const char __user *buffer,
|
|
|
|
size_t count, loff_t *ppos);
|
2012-12-18 22:22:27 +00:00
|
|
|
|
2020-12-15 03:06:24 +00:00
|
|
|
static inline enum node_stat_item cache_vmstat_idx(struct kmem_cache *s)
|
2019-07-12 03:56:16 +00:00
|
|
|
{
|
|
|
|
return (s->flags & SLAB_RECLAIM_ACCOUNT) ?
|
2020-08-07 06:20:39 +00:00
|
|
|
NR_SLAB_RECLAIMABLE_B : NR_SLAB_UNRECLAIMABLE_B;
|
2019-07-12 03:56:16 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:19:05 +00:00
|
|
|
#ifdef CONFIG_SLUB_DEBUG
|
|
|
|
#ifdef CONFIG_SLUB_DEBUG_ON
|
|
|
|
DECLARE_STATIC_KEY_TRUE(slub_debug_enabled);
|
|
|
|
#else
|
|
|
|
DECLARE_STATIC_KEY_FALSE(slub_debug_enabled);
|
|
|
|
#endif
|
|
|
|
extern void print_tracking(struct kmem_cache *s, void *object);
|
2021-06-29 02:34:33 +00:00
|
|
|
long validate_slab_cache(struct kmem_cache *s);
|
2021-07-15 04:26:34 +00:00
|
|
|
static inline bool __slub_debug_enabled(void)
|
|
|
|
{
|
|
|
|
return static_branch_unlikely(&slub_debug_enabled);
|
|
|
|
}
|
2020-08-07 06:19:05 +00:00
|
|
|
#else
|
|
|
|
static inline void print_tracking(struct kmem_cache *s, void *object)
|
|
|
|
{
|
|
|
|
}
|
2021-07-15 04:26:34 +00:00
|
|
|
static inline bool __slub_debug_enabled(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2020-08-07 06:19:05 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns true if any of the specified slub_debug flags is enabled for the
|
|
|
|
* cache. Use only for flags parsed by setup_slub_debug() as it also enables
|
|
|
|
* the static key.
|
|
|
|
*/
|
|
|
|
static inline bool kmem_cache_debug_flags(struct kmem_cache *s, slab_flags_t flags)
|
|
|
|
{
|
2021-07-15 04:26:34 +00:00
|
|
|
if (IS_ENABLED(CONFIG_SLUB_DEBUG))
|
|
|
|
VM_WARN_ON_ONCE(!(flags & SLAB_DEBUG_FLAGS));
|
|
|
|
if (__slub_debug_enabled())
|
2020-08-07 06:19:05 +00:00
|
|
|
return s->flags & flags;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-08-17 22:47:25 +00:00
|
|
|
#ifdef CONFIG_MEMCG_KMEM
|
2021-11-02 21:42:04 +00:00
|
|
|
/*
|
|
|
|
* slab_objcgs - get the object cgroups vector associated with a slab
|
|
|
|
* @slab: a pointer to the slab struct
|
|
|
|
*
|
|
|
|
* Returns a pointer to the object cgroups vector associated with the slab,
|
|
|
|
* or NULL if no such vector has been associated yet.
|
|
|
|
*/
|
|
|
|
static inline struct obj_cgroup **slab_objcgs(struct slab *slab)
|
|
|
|
{
|
|
|
|
unsigned long memcg_data = READ_ONCE(slab->memcg_data);
|
|
|
|
|
|
|
|
VM_BUG_ON_PAGE(memcg_data && !(memcg_data & MEMCG_DATA_OBJCGS),
|
|
|
|
slab_page(slab));
|
|
|
|
VM_BUG_ON_PAGE(memcg_data & MEMCG_DATA_KMEM, slab_page(slab));
|
|
|
|
|
|
|
|
return (struct obj_cgroup **)(memcg_data & ~MEMCG_DATA_FLAGS_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
int memcg_alloc_slab_cgroups(struct slab *slab, struct kmem_cache *s,
|
|
|
|
gfp_t gfp, bool new_slab);
|
mm/memcg: move mod_objcg_state() to memcontrol.c
Patch series "mm/memcg: Reduce kmemcache memory accounting overhead", v6.
With the recent introduction of the new slab memory controller, we
eliminate the need for having separate kmemcaches for each memory cgroup
and reduce overall kernel memory usage. However, we also add additional
memory accounting overhead to each call of kmem_cache_alloc() and
kmem_cache_free().
For workloads that require a lot of kmemcache allocations and
de-allocations, they may experience performance regression as illustrated
in [1] and [2].
A simple kernel module that performs repeated loop of 100,000,000
kmem_cache_alloc() and kmem_cache_free() of either a small 32-byte object
or a big 4k object at module init time with a batch size of 4 (4 kmalloc's
followed by 4 kfree's) is used for benchmarking. The benchmarking tool
was run on a kernel based on linux-next-20210419. The test was run on a
CascadeLake server with turbo-boosting disable to reduce run-to-run
variation.
The small object test exercises mainly the object stock charging and
vmstat update code paths. The large object test also exercises the
refill_obj_stock() and __memcg_kmem_charge()/__memcg_kmem_uncharge() code
paths.
With memory accounting disabled, the run time was 3.130s with both small
object big object tests.
With memory accounting enabled, both cgroup v1 and v2 showed similar
results in the small object test. The performance results of the large
object test, however, differed between cgroup v1 and v2.
The execution times with the application of various patches in the
patchset were:
Applied patches Run time Accounting overhead %age 1 %age 2
--------------- -------- ------------------- ------ ------
Small 32-byte object:
None 11.634s 8.504s 100.0% 271.7%
1-2 9.425s 6.295s 74.0% 201.1%
1-3 9.708s 6.578s 77.4% 210.2%
1-4 8.062s 4.932s 58.0% 157.6%
Large 4k object (v2):
None 22.107s 18.977s 100.0% 606.3%
1-2 20.960s 17.830s 94.0% 569.6%
1-3 14.238s 11.108s 58.5% 354.9%
1-4 11.329s 8.199s 43.2% 261.9%
Large 4k object (v1):
None 36.807s 33.677s 100.0% 1075.9%
1-2 36.648s 33.518s 99.5% 1070.9%
1-3 22.345s 19.215s 57.1% 613.9%
1-4 18.662s 15.532s 46.1% 496.2%
N.B. %age 1 = overhead/unpatched overhead
%age 2 = overhead/accounting disabled time
Patch 2 (vmstat data stock caching) helps in both the small object test
and the large v2 object test. It doesn't help much in v1 big object test.
Patch 3 (refill_obj_stock improvement) does help the small object test
but offer significant performance improvement for the large object test
(both v1 and v2).
Patch 4 (eliminating irq disable/enable) helps in all test cases.
To test for the extreme case, a multi-threaded kmalloc/kfree
microbenchmark was run on the 2-socket 48-core 96-thread system with
96 testing threads in the same memcg doing kmalloc+kfree of a 4k object
with accounting enabled for 10s. The total number of kmalloc+kfree done
in kilo operations per second (kops/s) were as follows:
Applied patches v1 kops/s v1 change v2 kops/s v2 change
--------------- --------- --------- --------- ---------
None 3,520 1.00X 6,242 1.00X
1-2 4,304 1.22X 8,478 1.36X
1-3 4,731 1.34X 418,142 66.99X
1-4 4,587 1.30X 438,838 70.30X
With memory accounting disabled, the kmalloc/kfree rate was 1,481,291
kop/s. This test shows how significant the memory accouting overhead
can be in some extreme situations.
For this multithreaded test, the improvement from patch 2 mainly
comes from the conditional atomic xchg of objcg->nr_charged_bytes in
mod_objcg_state(). By using an unconditional xchg, the operation rates
were similar to the unpatched kernel.
Patch 3 elminates the single highly contended cacheline of
objcg->nr_charged_bytes for cgroup v2 leading to a huge performance
improvement. Cgroup v1, however, still has another highly contended
cacheline in the shared page counter &memcg->kmem. So the improvement
is only modest.
Patch 4 helps in cgroup v2, but performs worse in cgroup v1 as
eliminating the irq_disable/irq_enable overhead seems to aggravate the
cacheline contention.
[1] https://lore.kernel.org/linux-mm/20210408193948.vfktg3azh2wrt56t@gabell/T/#u
[2] https://lore.kernel.org/lkml/20210114025151.GA22932@xsang-OptiPlex-9020/
This patch (of 4):
mod_objcg_state() is moved from mm/slab.h to mm/memcontrol.c so that
further optimization can be done to it in later patches without exposing
unnecessary details to other mm components.
Link: https://lkml.kernel.org/r/20210506150007.16288-1-longman@redhat.com
Link: https://lkml.kernel.org/r/20210506150007.16288-2-longman@redhat.com
Signed-off-by: Waiman Long <longman@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Roman Gushchin <guro@fb.com>
Cc: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Chris Down <chris@chrisdown.name>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
Cc: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-06-29 02:37:19 +00:00
|
|
|
void mod_objcg_state(struct obj_cgroup *objcg, struct pglist_data *pgdat,
|
|
|
|
enum node_stat_item idx, int nr);
|
2020-08-07 06:20:52 +00:00
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
static inline void memcg_free_slab_cgroups(struct slab *slab)
|
2020-08-07 06:20:52 +00:00
|
|
|
{
|
2021-11-02 21:42:04 +00:00
|
|
|
kfree(slab_objcgs(slab));
|
|
|
|
slab->memcg_data = 0;
|
2020-08-07 06:20:52 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:20:59 +00:00
|
|
|
static inline size_t obj_full_size(struct kmem_cache *s)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For each accounted object there is an extra space which is used
|
|
|
|
* to store obj_cgroup membership. Charge it too.
|
|
|
|
*/
|
|
|
|
return s->size + sizeof(struct obj_cgroup *);
|
|
|
|
}
|
|
|
|
|
2020-12-06 06:14:45 +00:00
|
|
|
/*
|
|
|
|
* Returns false if the allocation should fail.
|
|
|
|
*/
|
|
|
|
static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s,
|
2022-03-22 21:40:56 +00:00
|
|
|
struct list_lru *lru,
|
2020-12-06 06:14:45 +00:00
|
|
|
struct obj_cgroup **objcgp,
|
|
|
|
size_t objects, gfp_t flags)
|
2020-08-07 06:20:59 +00:00
|
|
|
{
|
2020-08-07 06:21:10 +00:00
|
|
|
struct obj_cgroup *objcg;
|
|
|
|
|
2023-02-13 19:29:22 +00:00
|
|
|
if (!memcg_kmem_online())
|
2020-12-06 06:14:45 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
if (!(flags & __GFP_ACCOUNT) && !(s->flags & SLAB_ACCOUNT))
|
|
|
|
return true;
|
|
|
|
|
2020-08-07 06:21:10 +00:00
|
|
|
objcg = get_obj_cgroup_from_current();
|
|
|
|
if (!objcg)
|
2020-12-06 06:14:45 +00:00
|
|
|
return true;
|
2020-08-07 06:21:10 +00:00
|
|
|
|
2022-03-22 21:40:56 +00:00
|
|
|
if (lru) {
|
|
|
|
int ret;
|
|
|
|
struct mem_cgroup *memcg;
|
|
|
|
|
|
|
|
memcg = get_mem_cgroup_from_objcg(objcg);
|
|
|
|
ret = memcg_list_lru_alloc(memcg, lru, flags);
|
|
|
|
css_put(&memcg->css);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-08-07 06:20:59 +00:00
|
|
|
}
|
|
|
|
|
2022-03-22 21:40:56 +00:00
|
|
|
if (obj_cgroup_charge(objcg, flags, objects * obj_full_size(s)))
|
|
|
|
goto out;
|
|
|
|
|
2020-12-06 06:14:45 +00:00
|
|
|
*objcgp = objcg;
|
|
|
|
return true;
|
2022-03-22 21:40:56 +00:00
|
|
|
out:
|
|
|
|
obj_cgroup_put(objcg);
|
|
|
|
return false;
|
2020-08-07 06:20:59 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:20:56 +00:00
|
|
|
static inline void memcg_slab_post_alloc_hook(struct kmem_cache *s,
|
|
|
|
struct obj_cgroup *objcg,
|
2020-08-07 06:21:27 +00:00
|
|
|
gfp_t flags, size_t size,
|
|
|
|
void **p)
|
2020-08-07 06:20:56 +00:00
|
|
|
{
|
2021-11-02 21:42:04 +00:00
|
|
|
struct slab *slab;
|
2020-08-07 06:20:56 +00:00
|
|
|
unsigned long off;
|
|
|
|
size_t i;
|
|
|
|
|
2023-02-13 19:29:22 +00:00
|
|
|
if (!memcg_kmem_online() || !objcg)
|
2020-08-07 06:21:27 +00:00
|
|
|
return;
|
|
|
|
|
2020-08-07 06:20:56 +00:00
|
|
|
for (i = 0; i < size; i++) {
|
|
|
|
if (likely(p[i])) {
|
2021-11-02 21:42:04 +00:00
|
|
|
slab = virt_to_slab(p[i]);
|
2020-08-07 06:21:27 +00:00
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
if (!slab_objcgs(slab) &&
|
|
|
|
memcg_alloc_slab_cgroups(slab, s, flags,
|
2021-02-24 20:03:11 +00:00
|
|
|
false)) {
|
2020-08-07 06:21:27 +00:00
|
|
|
obj_cgroup_uncharge(objcg, obj_full_size(s));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
off = obj_to_index(s, slab, p[i]);
|
2020-08-07 06:20:56 +00:00
|
|
|
obj_cgroup_get(objcg);
|
2021-11-02 21:42:04 +00:00
|
|
|
slab_objcgs(slab)[off] = objcg;
|
|
|
|
mod_objcg_state(objcg, slab_pgdat(slab),
|
2020-08-07 06:20:59 +00:00
|
|
|
cache_vmstat_idx(s), obj_full_size(s));
|
|
|
|
} else {
|
|
|
|
obj_cgroup_uncharge(objcg, obj_full_size(s));
|
2020-08-07 06:20:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
obj_cgroup_put(objcg);
|
|
|
|
}
|
|
|
|
|
2022-04-29 12:30:44 +00:00
|
|
|
static inline void memcg_slab_free_hook(struct kmem_cache *s, struct slab *slab,
|
2020-10-13 23:53:09 +00:00
|
|
|
void **p, int objects)
|
2020-08-07 06:20:56 +00:00
|
|
|
{
|
2020-12-01 21:58:28 +00:00
|
|
|
struct obj_cgroup **objcgs;
|
2020-10-13 23:53:09 +00:00
|
|
|
int i;
|
2020-08-07 06:20:56 +00:00
|
|
|
|
2023-02-13 19:29:22 +00:00
|
|
|
if (!memcg_kmem_online())
|
2020-08-07 06:21:27 +00:00
|
|
|
return;
|
|
|
|
|
2022-04-29 12:30:44 +00:00
|
|
|
objcgs = slab_objcgs(slab);
|
|
|
|
if (!objcgs)
|
|
|
|
return;
|
2020-08-07 06:20:59 +00:00
|
|
|
|
2022-04-29 12:30:44 +00:00
|
|
|
for (i = 0; i < objects; i++) {
|
|
|
|
struct obj_cgroup *objcg;
|
|
|
|
unsigned int off;
|
2020-08-07 06:21:27 +00:00
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
off = obj_to_index(s, slab, p[i]);
|
2020-12-01 21:58:28 +00:00
|
|
|
objcg = objcgs[off];
|
2020-10-13 23:53:09 +00:00
|
|
|
if (!objcg)
|
|
|
|
continue;
|
2020-08-07 06:20:59 +00:00
|
|
|
|
2020-12-01 21:58:28 +00:00
|
|
|
objcgs[off] = NULL;
|
2020-10-13 23:53:09 +00:00
|
|
|
obj_cgroup_uncharge(objcg, obj_full_size(s));
|
2021-11-02 21:42:04 +00:00
|
|
|
mod_objcg_state(objcg, slab_pgdat(slab), cache_vmstat_idx(s),
|
2020-10-13 23:53:09 +00:00
|
|
|
-obj_full_size(s));
|
|
|
|
obj_cgroup_put(objcg);
|
|
|
|
}
|
2020-08-07 06:20:56 +00:00
|
|
|
}
|
|
|
|
|
2018-08-17 22:47:25 +00:00
|
|
|
#else /* CONFIG_MEMCG_KMEM */
|
2021-11-02 21:42:04 +00:00
|
|
|
static inline struct obj_cgroup **slab_objcgs(struct slab *slab)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2020-08-07 06:21:10 +00:00
|
|
|
static inline struct mem_cgroup *memcg_from_slab_obj(void *ptr)
|
2019-07-12 03:56:31 +00:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
static inline int memcg_alloc_slab_cgroups(struct slab *slab,
|
2021-02-24 20:03:11 +00:00
|
|
|
struct kmem_cache *s, gfp_t gfp,
|
2021-11-02 21:42:04 +00:00
|
|
|
bool new_slab)
|
2020-08-07 06:20:52 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-11-02 21:42:04 +00:00
|
|
|
static inline void memcg_free_slab_cgroups(struct slab *slab)
|
2020-08-07 06:20:52 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2020-12-06 06:14:45 +00:00
|
|
|
static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s,
|
2022-03-22 21:40:56 +00:00
|
|
|
struct list_lru *lru,
|
2020-12-06 06:14:45 +00:00
|
|
|
struct obj_cgroup **objcgp,
|
|
|
|
size_t objects, gfp_t flags)
|
2020-08-07 06:20:59 +00:00
|
|
|
{
|
2020-12-06 06:14:45 +00:00
|
|
|
return true;
|
2020-08-07 06:20:59 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:20:56 +00:00
|
|
|
static inline void memcg_slab_post_alloc_hook(struct kmem_cache *s,
|
|
|
|
struct obj_cgroup *objcg,
|
2020-08-07 06:21:27 +00:00
|
|
|
gfp_t flags, size_t size,
|
|
|
|
void **p)
|
2020-08-07 06:20:56 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2022-04-29 12:30:44 +00:00
|
|
|
static inline void memcg_slab_free_hook(struct kmem_cache *s, struct slab *slab,
|
2020-10-13 23:53:09 +00:00
|
|
|
void **p, int objects)
|
2020-08-07 06:20:56 +00:00
|
|
|
{
|
|
|
|
}
|
2018-08-17 22:47:25 +00:00
|
|
|
#endif /* CONFIG_MEMCG_KMEM */
|
2012-12-18 22:22:46 +00:00
|
|
|
|
2019-07-12 03:53:26 +00:00
|
|
|
static inline struct kmem_cache *virt_to_cache(const void *obj)
|
|
|
|
{
|
2021-10-04 13:45:53 +00:00
|
|
|
struct slab *slab;
|
2019-07-12 03:53:26 +00:00
|
|
|
|
2021-10-04 13:45:53 +00:00
|
|
|
slab = virt_to_slab(obj);
|
|
|
|
if (WARN_ONCE(!slab, "%s: Object is not a Slab page!\n",
|
2019-07-12 03:53:26 +00:00
|
|
|
__func__))
|
|
|
|
return NULL;
|
2021-10-04 13:45:53 +00:00
|
|
|
return slab->slab_cache;
|
2019-07-12 03:53:26 +00:00
|
|
|
}
|
|
|
|
|
2021-10-04 13:45:52 +00:00
|
|
|
static __always_inline void account_slab(struct slab *slab, int order,
|
|
|
|
struct kmem_cache *s, gfp_t gfp)
|
2019-07-12 03:56:16 +00:00
|
|
|
{
|
2023-02-13 19:29:22 +00:00
|
|
|
if (memcg_kmem_online() && (s->flags & SLAB_ACCOUNT))
|
2021-11-02 21:42:04 +00:00
|
|
|
memcg_alloc_slab_cgroups(slab, s, gfp, true);
|
2021-02-24 20:03:11 +00:00
|
|
|
|
2021-10-04 13:45:52 +00:00
|
|
|
mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s),
|
2020-08-07 06:20:59 +00:00
|
|
|
PAGE_SIZE << order);
|
2019-07-12 03:56:16 +00:00
|
|
|
}
|
|
|
|
|
2021-10-04 13:45:52 +00:00
|
|
|
static __always_inline void unaccount_slab(struct slab *slab, int order,
|
|
|
|
struct kmem_cache *s)
|
2019-07-12 03:56:16 +00:00
|
|
|
{
|
2023-02-13 19:29:22 +00:00
|
|
|
if (memcg_kmem_online())
|
2021-11-02 21:42:04 +00:00
|
|
|
memcg_free_slab_cgroups(slab);
|
2020-08-07 06:21:10 +00:00
|
|
|
|
2021-10-04 13:45:52 +00:00
|
|
|
mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s),
|
2020-08-07 06:20:59 +00:00
|
|
|
-(PAGE_SIZE << order));
|
2019-07-12 03:56:16 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:19:05 +00:00
|
|
|
static inline struct kmem_cache *cache_from_obj(struct kmem_cache *s, void *x)
|
|
|
|
{
|
|
|
|
struct kmem_cache *cachep;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_SLAB_FREELIST_HARDENED) &&
|
|
|
|
!kmem_cache_debug_flags(s, SLAB_CONSISTENCY_CHECKS))
|
|
|
|
return s;
|
|
|
|
|
|
|
|
cachep = virt_to_cache(x);
|
2020-08-07 06:21:27 +00:00
|
|
|
if (WARN(cachep && cachep != s,
|
2020-08-07 06:19:05 +00:00
|
|
|
"%s: Wrong slab cache. %s but object is from %s\n",
|
|
|
|
__func__, s->name, cachep->name))
|
|
|
|
print_tracking(cachep, x);
|
|
|
|
return cachep;
|
|
|
|
}
|
2022-08-17 10:18:19 +00:00
|
|
|
|
|
|
|
void free_large_kmalloc(struct folio *folio, void *object);
|
|
|
|
|
2022-08-17 10:18:25 +00:00
|
|
|
size_t __ksize(const void *objp);
|
|
|
|
|
2016-03-15 21:53:35 +00:00
|
|
|
static inline size_t slab_ksize(const struct kmem_cache *s)
|
|
|
|
{
|
|
|
|
#ifndef CONFIG_SLUB
|
|
|
|
return s->object_size;
|
|
|
|
|
|
|
|
#else /* CONFIG_SLUB */
|
|
|
|
# ifdef CONFIG_SLUB_DEBUG
|
|
|
|
/*
|
|
|
|
* Debugging requires use of the padding between object
|
|
|
|
* and whatever may come after it.
|
|
|
|
*/
|
|
|
|
if (s->flags & (SLAB_RED_ZONE | SLAB_POISON))
|
|
|
|
return s->object_size;
|
|
|
|
# endif
|
2016-07-28 22:49:07 +00:00
|
|
|
if (s->flags & SLAB_KASAN)
|
|
|
|
return s->object_size;
|
2016-03-15 21:53:35 +00:00
|
|
|
/*
|
|
|
|
* If we have the need to store the freelist pointer
|
|
|
|
* back there or track user information then we can
|
|
|
|
* only use the space before that information.
|
|
|
|
*/
|
2017-01-18 10:53:44 +00:00
|
|
|
if (s->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_STORE_USER))
|
2016-03-15 21:53:35 +00:00
|
|
|
return s->inuse;
|
|
|
|
/*
|
|
|
|
* Else we can use all the padding etc for the allocation
|
|
|
|
*/
|
|
|
|
return s->size;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s,
|
2022-03-22 21:40:56 +00:00
|
|
|
struct list_lru *lru,
|
2020-08-07 06:20:56 +00:00
|
|
|
struct obj_cgroup **objcgp,
|
|
|
|
size_t size, gfp_t flags)
|
2016-03-15 21:53:35 +00:00
|
|
|
{
|
|
|
|
flags &= gfp_allowed_mask;
|
2017-03-03 09:13:38 +00:00
|
|
|
|
2020-12-15 03:08:34 +00:00
|
|
|
might_alloc(flags);
|
2016-03-15 21:53:35 +00:00
|
|
|
|
2016-03-15 21:53:38 +00:00
|
|
|
if (should_failslab(s, flags))
|
2016-03-15 21:53:35 +00:00
|
|
|
return NULL;
|
|
|
|
|
2022-03-22 21:40:56 +00:00
|
|
|
if (!memcg_slab_pre_alloc_hook(s, lru, objcgp, size, flags))
|
2020-12-06 06:14:45 +00:00
|
|
|
return NULL;
|
2016-07-26 22:24:21 +00:00
|
|
|
|
|
|
|
return s;
|
2016-03-15 21:53:35 +00:00
|
|
|
}
|
|
|
|
|
2020-08-07 06:20:56 +00:00
|
|
|
static inline void slab_post_alloc_hook(struct kmem_cache *s,
|
2021-04-30 06:00:06 +00:00
|
|
|
struct obj_cgroup *objcg, gfp_t flags,
|
2022-10-21 03:24:03 +00:00
|
|
|
size_t size, void **p, bool init,
|
|
|
|
unsigned int orig_size)
|
2016-03-15 21:53:35 +00:00
|
|
|
{
|
2022-10-21 03:24:03 +00:00
|
|
|
unsigned int zero_size = s->object_size;
|
2023-07-05 12:44:02 +00:00
|
|
|
bool kasan_init = init;
|
2016-03-15 21:53:35 +00:00
|
|
|
size_t i;
|
|
|
|
|
|
|
|
flags &= gfp_allowed_mask;
|
2021-04-30 06:00:06 +00:00
|
|
|
|
2022-10-21 03:24:03 +00:00
|
|
|
/*
|
|
|
|
* For kmalloc object, the allocated memory size(object_size) is likely
|
|
|
|
* larger than the requested size(orig_size). If redzone check is
|
|
|
|
* enabled for the extra space, don't zero it, as it will be redzoned
|
|
|
|
* soon. The redzone operation for this extra space could be seen as a
|
|
|
|
* replacement of current poisoning under certain debug option, and
|
|
|
|
* won't break other sanity checks.
|
|
|
|
*/
|
|
|
|
if (kmem_cache_debug_flags(s, SLAB_STORE_USER | SLAB_RED_ZONE) &&
|
|
|
|
(s->flags & SLAB_KMALLOC))
|
|
|
|
zero_size = orig_size;
|
|
|
|
|
2023-07-05 12:44:02 +00:00
|
|
|
/*
|
|
|
|
* When slub_debug is enabled, avoid memory initialization integrated
|
|
|
|
* into KASAN and instead zero out the memory via the memset below with
|
|
|
|
* the proper size. Otherwise, KASAN might overwrite SLUB redzones and
|
|
|
|
* cause false-positive reports. This does not lead to a performance
|
|
|
|
* penalty on production builds, as slub_debug is not intended to be
|
|
|
|
* enabled there.
|
|
|
|
*/
|
|
|
|
if (__slub_debug_enabled())
|
|
|
|
kasan_init = false;
|
|
|
|
|
2021-04-30 06:00:06 +00:00
|
|
|
/*
|
|
|
|
* As memory initialization might be integrated into KASAN,
|
|
|
|
* kasan_slab_alloc and initialization memset must be
|
|
|
|
* kept together to avoid discrepancies in behavior.
|
|
|
|
*
|
|
|
|
* As p[i] might get tagged, memset and kmemleak hook come after KASAN.
|
|
|
|
*/
|
2016-03-15 21:53:35 +00:00
|
|
|
for (i = 0; i < size; i++) {
|
2023-07-05 12:44:02 +00:00
|
|
|
p[i] = kasan_slab_alloc(s, p[i], flags, kasan_init);
|
|
|
|
if (p[i] && init && (!kasan_init || !kasan_has_integrated_init()))
|
2022-10-21 03:24:03 +00:00
|
|
|
memset(p[i], 0, zero_size);
|
2019-02-21 06:19:11 +00:00
|
|
|
kmemleak_alloc_recursive(p[i], s->object_size, 1,
|
2016-03-15 21:53:35 +00:00
|
|
|
s->flags, flags);
|
2022-09-15 15:03:49 +00:00
|
|
|
kmsan_slab_alloc(s, p[i], flags);
|
2016-03-15 21:53:35 +00:00
|
|
|
}
|
2016-07-26 22:24:21 +00:00
|
|
|
|
2020-12-06 06:14:45 +00:00
|
|
|
memcg_slab_post_alloc_hook(s, objcg, flags, size, p);
|
2016-03-15 21:53:35 +00:00
|
|
|
}
|
|
|
|
|
2013-01-10 19:14:19 +00:00
|
|
|
/*
|
|
|
|
* The slab lists for all objects.
|
|
|
|
*/
|
|
|
|
struct kmem_cache_node {
|
|
|
|
#ifdef CONFIG_SLAB
|
2022-10-21 19:18:12 +00:00
|
|
|
raw_spinlock_t list_lock;
|
2013-01-10 19:14:19 +00:00
|
|
|
struct list_head slabs_partial; /* partial list first, better asm code */
|
|
|
|
struct list_head slabs_full;
|
|
|
|
struct list_head slabs_free;
|
2016-12-13 00:41:44 +00:00
|
|
|
unsigned long total_slabs; /* length of all slab lists */
|
|
|
|
unsigned long free_slabs; /* length of free slab list only */
|
2013-01-10 19:14:19 +00:00
|
|
|
unsigned long free_objects;
|
|
|
|
unsigned int free_limit;
|
|
|
|
unsigned int colour_next; /* Per-node cache coloring */
|
|
|
|
struct array_cache *shared; /* shared per node */
|
2014-08-06 23:04:29 +00:00
|
|
|
struct alien_cache **alien; /* on other nodes */
|
2013-01-10 19:14:19 +00:00
|
|
|
unsigned long next_reap; /* updated without locking */
|
|
|
|
int free_touched; /* updated without locking */
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_SLUB
|
2022-10-21 19:18:12 +00:00
|
|
|
spinlock_t list_lock;
|
2013-01-10 19:14:19 +00:00
|
|
|
unsigned long nr_partial;
|
|
|
|
struct list_head partial;
|
|
|
|
#ifdef CONFIG_SLUB_DEBUG
|
|
|
|
atomic_long_t nr_slabs;
|
|
|
|
atomic_long_t total_objects;
|
|
|
|
struct list_head full;
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
|
|
|
};
|
2013-07-04 00:33:23 +00:00
|
|
|
|
2014-08-06 23:04:07 +00:00
|
|
|
static inline struct kmem_cache_node *get_node(struct kmem_cache *s, int node)
|
|
|
|
{
|
|
|
|
return s->node[node];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Iterator over all nodes. The body will be executed for each node that has
|
|
|
|
* a kmem_cache_node structure allocated (which is true for all online nodes)
|
|
|
|
*/
|
|
|
|
#define for_each_kmem_cache_node(__s, __node, __n) \
|
2014-10-09 22:26:20 +00:00
|
|
|
for (__node = 0; __node < nr_node_ids; __node++) \
|
|
|
|
if ((__n = get_node(__s, __node)))
|
2014-08-06 23:04:07 +00:00
|
|
|
|
|
|
|
|
2017-11-16 01:32:07 +00:00
|
|
|
#if defined(CONFIG_SLAB) || defined(CONFIG_SLUB_DEBUG)
|
|
|
|
void dump_unreclaimable_slab(void);
|
|
|
|
#else
|
|
|
|
static inline void dump_unreclaimable_slab(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
mm: kasan: initial memory quarantine implementation
Quarantine isolates freed objects in a separate queue. The objects are
returned to the allocator later, which helps to detect use-after-free
errors.
When the object is freed, its state changes from KASAN_STATE_ALLOC to
KASAN_STATE_QUARANTINE. The object is poisoned and put into quarantine
instead of being returned to the allocator, therefore every subsequent
access to that object triggers a KASAN error, and the error handler is
able to say where the object has been allocated and deallocated.
When it's time for the object to leave quarantine, its state becomes
KASAN_STATE_FREE and it's returned to the allocator. From now on the
allocator may reuse it for another allocation. Before that happens,
it's still possible to detect a use-after free on that object (it
retains the allocation/deallocation stacks).
When the allocator reuses this object, the shadow is unpoisoned and old
allocation/deallocation stacks are wiped. Therefore a use of this
object, even an incorrect one, won't trigger ASan warning.
Without the quarantine, it's not guaranteed that the objects aren't
reused immediately, that's why the probability of catching a
use-after-free is lower than with quarantine in place.
Quarantine isolates freed objects in a separate queue. The objects are
returned to the allocator later, which helps to detect use-after-free
errors.
Freed objects are first added to per-cpu quarantine queues. When a
cache is destroyed or memory shrinking is requested, the objects are
moved into the global quarantine queue. Whenever a kmalloc call allows
memory reclaiming, the oldest objects are popped out of the global queue
until the total size of objects in quarantine is less than 3/4 of the
maximum quarantine size (which is a fraction of installed physical
memory).
As long as an object remains in the quarantine, KASAN is able to report
accesses to it, so the chance of reporting a use-after-free is
increased. Once the object leaves quarantine, the allocator may reuse
it, in which case the object is unpoisoned and KASAN can't detect
incorrect accesses to it.
Right now quarantine support is only enabled in SLAB allocator.
Unification of KASAN features in SLAB and SLUB will be done later.
This patch is based on the "mm: kasan: quarantine" patch originally
prepared by Dmitry Chernenkov. A number of improvements have been
suggested by Andrey Ryabinin.
[glider@google.com: v9]
Link: http://lkml.kernel.org/r/1462987130-144092-1-git-send-email-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrey Konovalov <adech.fo@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Konstantin Serebryany <kcc@google.com>
Cc: Dmitry Chernenkov <dmitryc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-20 23:59:11 +00:00
|
|
|
void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
|
|
|
|
|
2016-07-26 22:21:56 +00:00
|
|
|
#ifdef CONFIG_SLAB_FREELIST_RANDOM
|
|
|
|
int cache_random_seq_create(struct kmem_cache *cachep, unsigned int count,
|
|
|
|
gfp_t gfp);
|
|
|
|
void cache_random_seq_destroy(struct kmem_cache *cachep);
|
|
|
|
#else
|
|
|
|
static inline int cache_random_seq_create(struct kmem_cache *cachep,
|
|
|
|
unsigned int count, gfp_t gfp)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
static inline void cache_random_seq_destroy(struct kmem_cache *cachep) { }
|
|
|
|
#endif /* CONFIG_SLAB_FREELIST_RANDOM */
|
|
|
|
|
mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Patch series "add init_on_alloc/init_on_free boot options", v10.
Provide init_on_alloc and init_on_free boot options.
These are aimed at preventing possible information leaks and making the
control-flow bugs that depend on uninitialized values more deterministic.
Enabling either of the options guarantees that the memory returned by the
page allocator and SL[AU]B is initialized with zeroes. SLOB allocator
isn't supported at the moment, as its emulation of kmem caches complicates
handling of SLAB_TYPESAFE_BY_RCU caches correctly.
Enabling init_on_free also guarantees that pages and heap objects are
initialized right after they're freed, so it won't be possible to access
stale data by using a dangling pointer.
As suggested by Michal Hocko, right now we don't let the heap users to
disable initialization for certain allocations. There's not enough
evidence that doing so can speed up real-life cases, and introducing ways
to opt-out may result in things going out of control.
This patch (of 2):
The new options are needed to prevent possible information leaks and make
control-flow bugs that depend on uninitialized values more deterministic.
This is expected to be on-by-default on Android and Chrome OS. And it
gives the opportunity for anyone else to use it under distros too via the
boot args. (The init_on_free feature is regularly requested by folks
where memory forensics is included in their threat models.)
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap
objects with zeroes. Initialization is done at allocation time at the
places where checks for __GFP_ZERO are performed.
init_on_free=1 makes the kernel initialize freed pages and heap objects
with zeroes upon their deletion. This helps to ensure sensitive data
doesn't leak via use-after-free accesses.
Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator
returns zeroed memory. The two exceptions are slab caches with
constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never
zero-initialized to preserve their semantics.
Both init_on_alloc and init_on_free default to zero, but those defaults
can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and
CONFIG_INIT_ON_FREE_DEFAULT_ON.
If either SLUB poisoning or page poisoning is enabled, those options take
precedence over init_on_alloc and init_on_free: initialization is only
applied to unpoisoned allocations.
Slowdown for the new features compared to init_on_free=0, init_on_alloc=0:
hackbench, init_on_free=1: +7.62% sys time (st.err 0.74%)
hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%)
Linux build with -j12, init_on_free=1: +8.38% wall time (st.err 0.39%)
Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%)
Linux build with -j12, init_on_alloc=1: -0.13% wall time (st.err 0.42%)
Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline
is within the standard error.
The new features are also going to pave the way for hardware memory
tagging (e.g. arm64's MTE), which will require both on_alloc and on_free
hooks to set the tags for heap objects. With MTE, tagging will have the
same cost as memory initialization.
Although init_on_free is rather costly, there are paranoid use-cases where
in-memory data lifetime is desired to be minimized. There are various
arguments for/against the realism of the associated threat models, but
given that we'll need the infrastructure for MTE anyway, and there are
people who want wipe-on-free behavior no matter what the performance cost,
it seems reasonable to include it in this series.
[glider@google.com: v8]
Link: http://lkml.kernel.org/r/20190626121943.131390-2-glider@google.com
[glider@google.com: v9]
Link: http://lkml.kernel.org/r/20190627130316.254309-2-glider@google.com
[glider@google.com: v10]
Link: http://lkml.kernel.org/r/20190628093131.199499-2-glider@google.com
Link: http://lkml.kernel.org/r/20190617151050.92663-2-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.cz> [page and dmapool parts
Acked-by: James Morris <jamorris@linux.microsoft.com>]
Cc: Christoph Lameter <cl@linux.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Sandeep Patil <sspatil@android.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jann Horn <jannh@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marco Elver <elver@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-12 03:59:19 +00:00
|
|
|
static inline bool slab_want_init_on_alloc(gfp_t flags, struct kmem_cache *c)
|
|
|
|
{
|
2021-04-01 23:23:43 +00:00
|
|
|
if (static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON,
|
|
|
|
&init_on_alloc)) {
|
mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Patch series "add init_on_alloc/init_on_free boot options", v10.
Provide init_on_alloc and init_on_free boot options.
These are aimed at preventing possible information leaks and making the
control-flow bugs that depend on uninitialized values more deterministic.
Enabling either of the options guarantees that the memory returned by the
page allocator and SL[AU]B is initialized with zeroes. SLOB allocator
isn't supported at the moment, as its emulation of kmem caches complicates
handling of SLAB_TYPESAFE_BY_RCU caches correctly.
Enabling init_on_free also guarantees that pages and heap objects are
initialized right after they're freed, so it won't be possible to access
stale data by using a dangling pointer.
As suggested by Michal Hocko, right now we don't let the heap users to
disable initialization for certain allocations. There's not enough
evidence that doing so can speed up real-life cases, and introducing ways
to opt-out may result in things going out of control.
This patch (of 2):
The new options are needed to prevent possible information leaks and make
control-flow bugs that depend on uninitialized values more deterministic.
This is expected to be on-by-default on Android and Chrome OS. And it
gives the opportunity for anyone else to use it under distros too via the
boot args. (The init_on_free feature is regularly requested by folks
where memory forensics is included in their threat models.)
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap
objects with zeroes. Initialization is done at allocation time at the
places where checks for __GFP_ZERO are performed.
init_on_free=1 makes the kernel initialize freed pages and heap objects
with zeroes upon their deletion. This helps to ensure sensitive data
doesn't leak via use-after-free accesses.
Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator
returns zeroed memory. The two exceptions are slab caches with
constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never
zero-initialized to preserve their semantics.
Both init_on_alloc and init_on_free default to zero, but those defaults
can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and
CONFIG_INIT_ON_FREE_DEFAULT_ON.
If either SLUB poisoning or page poisoning is enabled, those options take
precedence over init_on_alloc and init_on_free: initialization is only
applied to unpoisoned allocations.
Slowdown for the new features compared to init_on_free=0, init_on_alloc=0:
hackbench, init_on_free=1: +7.62% sys time (st.err 0.74%)
hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%)
Linux build with -j12, init_on_free=1: +8.38% wall time (st.err 0.39%)
Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%)
Linux build with -j12, init_on_alloc=1: -0.13% wall time (st.err 0.42%)
Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline
is within the standard error.
The new features are also going to pave the way for hardware memory
tagging (e.g. arm64's MTE), which will require both on_alloc and on_free
hooks to set the tags for heap objects. With MTE, tagging will have the
same cost as memory initialization.
Although init_on_free is rather costly, there are paranoid use-cases where
in-memory data lifetime is desired to be minimized. There are various
arguments for/against the realism of the associated threat models, but
given that we'll need the infrastructure for MTE anyway, and there are
people who want wipe-on-free behavior no matter what the performance cost,
it seems reasonable to include it in this series.
[glider@google.com: v8]
Link: http://lkml.kernel.org/r/20190626121943.131390-2-glider@google.com
[glider@google.com: v9]
Link: http://lkml.kernel.org/r/20190627130316.254309-2-glider@google.com
[glider@google.com: v10]
Link: http://lkml.kernel.org/r/20190628093131.199499-2-glider@google.com
Link: http://lkml.kernel.org/r/20190617151050.92663-2-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.cz> [page and dmapool parts
Acked-by: James Morris <jamorris@linux.microsoft.com>]
Cc: Christoph Lameter <cl@linux.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Sandeep Patil <sspatil@android.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jann Horn <jannh@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marco Elver <elver@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-12 03:59:19 +00:00
|
|
|
if (c->ctor)
|
|
|
|
return false;
|
|
|
|
if (c->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON))
|
|
|
|
return flags & __GFP_ZERO;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return flags & __GFP_ZERO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool slab_want_init_on_free(struct kmem_cache *c)
|
|
|
|
{
|
2021-04-01 23:23:43 +00:00
|
|
|
if (static_branch_maybe(CONFIG_INIT_ON_FREE_DEFAULT_ON,
|
|
|
|
&init_on_free))
|
mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Patch series "add init_on_alloc/init_on_free boot options", v10.
Provide init_on_alloc and init_on_free boot options.
These are aimed at preventing possible information leaks and making the
control-flow bugs that depend on uninitialized values more deterministic.
Enabling either of the options guarantees that the memory returned by the
page allocator and SL[AU]B is initialized with zeroes. SLOB allocator
isn't supported at the moment, as its emulation of kmem caches complicates
handling of SLAB_TYPESAFE_BY_RCU caches correctly.
Enabling init_on_free also guarantees that pages and heap objects are
initialized right after they're freed, so it won't be possible to access
stale data by using a dangling pointer.
As suggested by Michal Hocko, right now we don't let the heap users to
disable initialization for certain allocations. There's not enough
evidence that doing so can speed up real-life cases, and introducing ways
to opt-out may result in things going out of control.
This patch (of 2):
The new options are needed to prevent possible information leaks and make
control-flow bugs that depend on uninitialized values more deterministic.
This is expected to be on-by-default on Android and Chrome OS. And it
gives the opportunity for anyone else to use it under distros too via the
boot args. (The init_on_free feature is regularly requested by folks
where memory forensics is included in their threat models.)
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap
objects with zeroes. Initialization is done at allocation time at the
places where checks for __GFP_ZERO are performed.
init_on_free=1 makes the kernel initialize freed pages and heap objects
with zeroes upon their deletion. This helps to ensure sensitive data
doesn't leak via use-after-free accesses.
Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator
returns zeroed memory. The two exceptions are slab caches with
constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never
zero-initialized to preserve their semantics.
Both init_on_alloc and init_on_free default to zero, but those defaults
can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and
CONFIG_INIT_ON_FREE_DEFAULT_ON.
If either SLUB poisoning or page poisoning is enabled, those options take
precedence over init_on_alloc and init_on_free: initialization is only
applied to unpoisoned allocations.
Slowdown for the new features compared to init_on_free=0, init_on_alloc=0:
hackbench, init_on_free=1: +7.62% sys time (st.err 0.74%)
hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%)
Linux build with -j12, init_on_free=1: +8.38% wall time (st.err 0.39%)
Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%)
Linux build with -j12, init_on_alloc=1: -0.13% wall time (st.err 0.42%)
Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline
is within the standard error.
The new features are also going to pave the way for hardware memory
tagging (e.g. arm64's MTE), which will require both on_alloc and on_free
hooks to set the tags for heap objects. With MTE, tagging will have the
same cost as memory initialization.
Although init_on_free is rather costly, there are paranoid use-cases where
in-memory data lifetime is desired to be minimized. There are various
arguments for/against the realism of the associated threat models, but
given that we'll need the infrastructure for MTE anyway, and there are
people who want wipe-on-free behavior no matter what the performance cost,
it seems reasonable to include it in this series.
[glider@google.com: v8]
Link: http://lkml.kernel.org/r/20190626121943.131390-2-glider@google.com
[glider@google.com: v9]
Link: http://lkml.kernel.org/r/20190627130316.254309-2-glider@google.com
[glider@google.com: v10]
Link: http://lkml.kernel.org/r/20190628093131.199499-2-glider@google.com
Link: http://lkml.kernel.org/r/20190617151050.92663-2-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.cz> [page and dmapool parts
Acked-by: James Morris <jamorris@linux.microsoft.com>]
Cc: Christoph Lameter <cl@linux.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Sandeep Patil <sspatil@android.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jann Horn <jannh@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marco Elver <elver@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-12 03:59:19 +00:00
|
|
|
return !(c->ctor ||
|
|
|
|
(c->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-06-29 02:34:55 +00:00
|
|
|
#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_SLUB_DEBUG)
|
|
|
|
void debugfs_slab_release(struct kmem_cache *);
|
|
|
|
#else
|
|
|
|
static inline void debugfs_slab_release(struct kmem_cache *s) { }
|
|
|
|
#endif
|
|
|
|
|
2021-01-07 21:46:11 +00:00
|
|
|
#ifdef CONFIG_PRINTK
|
mm: Add mem_dump_obj() to print source of memory block
There are kernel facilities such as per-CPU reference counts that give
error messages in generic handlers or callbacks, whose messages are
unenlightening. In the case of per-CPU reference-count underflow, this
is not a problem when creating a new use of this facility because in that
case the bug is almost certainly in the code implementing that new use.
However, trouble arises when deploying across many systems, which might
exercise corner cases that were not seen during development and testing.
Here, it would be really nice to get some kind of hint as to which of
several uses the underflow was caused by.
This commit therefore exposes a mem_dump_obj() function that takes
a pointer to memory (which must still be allocated if it has been
dynamically allocated) and prints available information on where that
memory came from. This pointer can reference the middle of the block as
well as the beginning of the block, as needed by things like RCU callback
functions and timer handlers that might not know where the beginning of
the memory block is. These functions and handlers can use mem_dump_obj()
to print out better hints as to where the problem might lie.
The information printed can depend on kernel configuration. For example,
the allocation return address can be printed only for slab and slub,
and even then only when the necessary debug has been enabled. For slab,
build with CONFIG_DEBUG_SLAB=y, and either use sizes with ample space
to the next power of two or use the SLAB_STORE_USER when creating the
kmem_cache structure. For slub, build with CONFIG_SLUB_DEBUG=y and
boot with slub_debug=U, or pass SLAB_STORE_USER to kmem_cache_create()
if more focused use is desired. Also for slub, use CONFIG_STACKTRACE
to enable printing of the allocation-time stack trace.
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Reported-by: Andrii Nakryiko <andrii@kernel.org>
[ paulmck: Convert to printing and change names per Joonsoo Kim. ]
[ paulmck: Move slab definition per Stephen Rothwell and kbuild test robot. ]
[ paulmck: Handle CONFIG_MMU=n case where vmalloc() is kmalloc(). ]
[ paulmck: Apply Vlastimil Babka feedback on slab.c kmem_provenance(). ]
[ paulmck: Extract more info from !SLUB_DEBUG per Joonsoo Kim. ]
[ paulmck: Explicitly check for small pointers per Naresh Kamboju. ]
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-12-08 01:41:02 +00:00
|
|
|
#define KS_ADDRS_COUNT 16
|
|
|
|
struct kmem_obj_info {
|
|
|
|
void *kp_ptr;
|
2021-10-04 13:45:55 +00:00
|
|
|
struct slab *kp_slab;
|
mm: Add mem_dump_obj() to print source of memory block
There are kernel facilities such as per-CPU reference counts that give
error messages in generic handlers or callbacks, whose messages are
unenlightening. In the case of per-CPU reference-count underflow, this
is not a problem when creating a new use of this facility because in that
case the bug is almost certainly in the code implementing that new use.
However, trouble arises when deploying across many systems, which might
exercise corner cases that were not seen during development and testing.
Here, it would be really nice to get some kind of hint as to which of
several uses the underflow was caused by.
This commit therefore exposes a mem_dump_obj() function that takes
a pointer to memory (which must still be allocated if it has been
dynamically allocated) and prints available information on where that
memory came from. This pointer can reference the middle of the block as
well as the beginning of the block, as needed by things like RCU callback
functions and timer handlers that might not know where the beginning of
the memory block is. These functions and handlers can use mem_dump_obj()
to print out better hints as to where the problem might lie.
The information printed can depend on kernel configuration. For example,
the allocation return address can be printed only for slab and slub,
and even then only when the necessary debug has been enabled. For slab,
build with CONFIG_DEBUG_SLAB=y, and either use sizes with ample space
to the next power of two or use the SLAB_STORE_USER when creating the
kmem_cache structure. For slub, build with CONFIG_SLUB_DEBUG=y and
boot with slub_debug=U, or pass SLAB_STORE_USER to kmem_cache_create()
if more focused use is desired. Also for slub, use CONFIG_STACKTRACE
to enable printing of the allocation-time stack trace.
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Reported-by: Andrii Nakryiko <andrii@kernel.org>
[ paulmck: Convert to printing and change names per Joonsoo Kim. ]
[ paulmck: Move slab definition per Stephen Rothwell and kbuild test robot. ]
[ paulmck: Handle CONFIG_MMU=n case where vmalloc() is kmalloc(). ]
[ paulmck: Apply Vlastimil Babka feedback on slab.c kmem_provenance(). ]
[ paulmck: Extract more info from !SLUB_DEBUG per Joonsoo Kim. ]
[ paulmck: Explicitly check for small pointers per Naresh Kamboju. ]
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-12-08 01:41:02 +00:00
|
|
|
void *kp_objp;
|
|
|
|
unsigned long kp_data_offset;
|
|
|
|
struct kmem_cache *kp_slab_cache;
|
|
|
|
void *kp_ret;
|
|
|
|
void *kp_stack[KS_ADDRS_COUNT];
|
2021-03-16 10:37:11 +00:00
|
|
|
void *kp_free_stack[KS_ADDRS_COUNT];
|
mm: Add mem_dump_obj() to print source of memory block
There are kernel facilities such as per-CPU reference counts that give
error messages in generic handlers or callbacks, whose messages are
unenlightening. In the case of per-CPU reference-count underflow, this
is not a problem when creating a new use of this facility because in that
case the bug is almost certainly in the code implementing that new use.
However, trouble arises when deploying across many systems, which might
exercise corner cases that were not seen during development and testing.
Here, it would be really nice to get some kind of hint as to which of
several uses the underflow was caused by.
This commit therefore exposes a mem_dump_obj() function that takes
a pointer to memory (which must still be allocated if it has been
dynamically allocated) and prints available information on where that
memory came from. This pointer can reference the middle of the block as
well as the beginning of the block, as needed by things like RCU callback
functions and timer handlers that might not know where the beginning of
the memory block is. These functions and handlers can use mem_dump_obj()
to print out better hints as to where the problem might lie.
The information printed can depend on kernel configuration. For example,
the allocation return address can be printed only for slab and slub,
and even then only when the necessary debug has been enabled. For slab,
build with CONFIG_DEBUG_SLAB=y, and either use sizes with ample space
to the next power of two or use the SLAB_STORE_USER when creating the
kmem_cache structure. For slub, build with CONFIG_SLUB_DEBUG=y and
boot with slub_debug=U, or pass SLAB_STORE_USER to kmem_cache_create()
if more focused use is desired. Also for slub, use CONFIG_STACKTRACE
to enable printing of the allocation-time stack trace.
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Reported-by: Andrii Nakryiko <andrii@kernel.org>
[ paulmck: Convert to printing and change names per Joonsoo Kim. ]
[ paulmck: Move slab definition per Stephen Rothwell and kbuild test robot. ]
[ paulmck: Handle CONFIG_MMU=n case where vmalloc() is kmalloc(). ]
[ paulmck: Apply Vlastimil Babka feedback on slab.c kmem_provenance(). ]
[ paulmck: Extract more info from !SLUB_DEBUG per Joonsoo Kim. ]
[ paulmck: Explicitly check for small pointers per Naresh Kamboju. ]
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-12-08 01:41:02 +00:00
|
|
|
};
|
2022-04-15 02:13:40 +00:00
|
|
|
void __kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab);
|
2021-01-07 21:46:11 +00:00
|
|
|
#endif
|
mm: Add mem_dump_obj() to print source of memory block
There are kernel facilities such as per-CPU reference counts that give
error messages in generic handlers or callbacks, whose messages are
unenlightening. In the case of per-CPU reference-count underflow, this
is not a problem when creating a new use of this facility because in that
case the bug is almost certainly in the code implementing that new use.
However, trouble arises when deploying across many systems, which might
exercise corner cases that were not seen during development and testing.
Here, it would be really nice to get some kind of hint as to which of
several uses the underflow was caused by.
This commit therefore exposes a mem_dump_obj() function that takes
a pointer to memory (which must still be allocated if it has been
dynamically allocated) and prints available information on where that
memory came from. This pointer can reference the middle of the block as
well as the beginning of the block, as needed by things like RCU callback
functions and timer handlers that might not know where the beginning of
the memory block is. These functions and handlers can use mem_dump_obj()
to print out better hints as to where the problem might lie.
The information printed can depend on kernel configuration. For example,
the allocation return address can be printed only for slab and slub,
and even then only when the necessary debug has been enabled. For slab,
build with CONFIG_DEBUG_SLAB=y, and either use sizes with ample space
to the next power of two or use the SLAB_STORE_USER when creating the
kmem_cache structure. For slub, build with CONFIG_SLUB_DEBUG=y and
boot with slub_debug=U, or pass SLAB_STORE_USER to kmem_cache_create()
if more focused use is desired. Also for slub, use CONFIG_STACKTRACE
to enable printing of the allocation-time stack trace.
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Reported-by: Andrii Nakryiko <andrii@kernel.org>
[ paulmck: Convert to printing and change names per Joonsoo Kim. ]
[ paulmck: Move slab definition per Stephen Rothwell and kbuild test robot. ]
[ paulmck: Handle CONFIG_MMU=n case where vmalloc() is kmalloc(). ]
[ paulmck: Apply Vlastimil Babka feedback on slab.c kmem_provenance(). ]
[ paulmck: Extract more info from !SLUB_DEBUG per Joonsoo Kim. ]
[ paulmck: Explicitly check for small pointers per Naresh Kamboju. ]
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-12-08 01:41:02 +00:00
|
|
|
|
2021-10-04 13:45:56 +00:00
|
|
|
void __check_heap_object(const void *ptr, unsigned long n,
|
|
|
|
const struct slab *slab, bool to_user);
|
|
|
|
|
mm/slub: extend redzone check to extra allocated kmalloc space than requested
kmalloc will round up the request size to a fixed size (mostly power
of 2), so there could be a extra space than what is requested, whose
size is the actual buffer size minus original request size.
To better detect out of bound access or abuse of this space, add
redzone sanity check for it.
In current kernel, some kmalloc user already knows the existence of
the space and utilizes it after calling 'ksize()' to know the real
size of the allocated buffer. So we skip the sanity check for objects
which have been called with ksize(), as treating them as legitimate
users. Kees Cook is working on sanitizing all these user cases,
by using kmalloc_size_roundup() to avoid ambiguous usages. And after
this is done, this special handling for ksize() can be removed.
In some cases, the free pointer could be saved inside the latter
part of object data area, which may overlap the redzone part(for
small sizes of kmalloc objects). As suggested by Hyeonggon Yoo,
force the free pointer to be in meta data area when kmalloc redzone
debug is enabled, to make all kmalloc objects covered by redzone
check.
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2022-10-21 03:24:05 +00:00
|
|
|
#ifdef CONFIG_SLUB_DEBUG
|
|
|
|
void skip_orig_size_check(struct kmem_cache *s, const void *object);
|
|
|
|
#endif
|
|
|
|
|
2014-08-06 23:04:14 +00:00
|
|
|
#endif /* MM_SLAB_H */
|