2019-05-19 05:08:55 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2010-09-17 08:09:00 -07:00
|
|
|
/*
|
|
|
|
* jump label support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2009 Jason Baron <jbaron@redhat.com>
|
2015-11-16 03:08:45 -07:00
|
|
|
* Copyright (C) 2011 Peter Zijlstra
|
2010-09-17 08:09:00 -07:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
#include <linux/memory.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/sort.h>
|
|
|
|
#include <linux/err.h>
|
2012-02-24 00:31:31 -07:00
|
|
|
#include <linux/static_key.h>
|
2013-08-09 07:21:57 -07:00
|
|
|
#include <linux/jump_label_ratelimit.h>
|
2016-08-03 13:46:36 -07:00
|
|
|
#include <linux/bug.h>
|
2017-05-24 01:15:35 -07:00
|
|
|
#include <linux/cpu.h>
|
2018-03-19 11:18:57 -07:00
|
|
|
#include <asm/sections.h>
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2020-10-15 20:10:28 -07:00
|
|
|
/* mutex to protect coming/going of the jump_label table */
|
2010-09-17 08:09:00 -07:00
|
|
|
static DEFINE_MUTEX(jump_label_mutex);
|
|
|
|
|
2010-10-01 14:23:48 -07:00
|
|
|
void jump_label_lock(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&jump_label_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void jump_label_unlock(void)
|
|
|
|
{
|
|
|
|
mutex_unlock(&jump_label_mutex);
|
|
|
|
}
|
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
static int jump_label_cmp(const void *a, const void *b)
|
|
|
|
{
|
|
|
|
const struct jump_entry *jea = a;
|
|
|
|
const struct jump_entry *jeb = b;
|
|
|
|
|
2019-06-12 02:57:28 -07:00
|
|
|
/*
|
|
|
|
* Entrires are sorted by key.
|
|
|
|
*/
|
2018-09-18 23:51:36 -07:00
|
|
|
if (jump_entry_key(jea) < jump_entry_key(jeb))
|
2010-09-17 08:09:00 -07:00
|
|
|
return -1;
|
|
|
|
|
2018-09-18 23:51:36 -07:00
|
|
|
if (jump_entry_key(jea) > jump_entry_key(jeb))
|
2010-09-17 08:09:00 -07:00
|
|
|
return 1;
|
|
|
|
|
2019-06-12 02:57:28 -07:00
|
|
|
/*
|
|
|
|
* In the batching mode, entries should also be sorted by the code
|
|
|
|
* inside the already sorted list of entries, enabling a bsearch in
|
|
|
|
* the vector.
|
|
|
|
*/
|
|
|
|
if (jump_entry_code(jea) < jump_entry_code(jeb))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (jump_entry_code(jea) > jump_entry_code(jeb))
|
|
|
|
return 1;
|
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-18 23:51:37 -07:00
|
|
|
static void jump_label_swap(void *a, void *b, int size)
|
|
|
|
{
|
|
|
|
long delta = (unsigned long)a - (unsigned long)b;
|
|
|
|
struct jump_entry *jea = a;
|
|
|
|
struct jump_entry *jeb = b;
|
|
|
|
struct jump_entry tmp = *jea;
|
|
|
|
|
|
|
|
jea->code = jeb->code - delta;
|
|
|
|
jea->target = jeb->target - delta;
|
|
|
|
jea->key = jeb->key - delta;
|
|
|
|
|
|
|
|
jeb->code = tmp.code + delta;
|
|
|
|
jeb->target = tmp.target + delta;
|
|
|
|
jeb->key = tmp.key + delta;
|
|
|
|
}
|
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
static void
|
2011-03-16 14:29:47 -07:00
|
|
|
jump_label_sort_entries(struct jump_entry *start, struct jump_entry *stop)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
|
|
|
unsigned long size;
|
2018-09-18 23:51:37 -07:00
|
|
|
void *swapfn = NULL;
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE))
|
|
|
|
swapfn = jump_label_swap;
|
2010-09-17 08:09:00 -07:00
|
|
|
|
|
|
|
size = (((unsigned long)stop - (unsigned long)start)
|
|
|
|
/ sizeof(struct jump_entry));
|
2018-09-18 23:51:37 -07:00
|
|
|
sort(start, size, sizeof(struct jump_entry), jump_label_cmp, swapfn);
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static void jump_label_update(struct static_key *key);
|
2015-07-24 05:55:40 -07:00
|
|
|
|
2016-08-03 13:46:36 -07:00
|
|
|
/*
|
2018-12-30 08:14:15 -07:00
|
|
|
* There are similar definitions for the !CONFIG_JUMP_LABEL case in jump_label.h.
|
2016-08-03 13:46:36 -07:00
|
|
|
* The use of 'atomic_read()' requires atomic.h and its problematic for some
|
|
|
|
* kernel headers such as kernel.h and others. Since static_key_count() is not
|
2018-12-30 08:14:15 -07:00
|
|
|
* used in the branch statements as it is for the !CONFIG_JUMP_LABEL case its ok
|
2016-08-03 13:46:36 -07:00
|
|
|
* to have it be a function here. Similarly, for 'static_key_enable()' and
|
|
|
|
* 'static_key_disable()', which require bug.h. This should allow jump_label.h
|
2018-12-30 08:14:15 -07:00
|
|
|
* to be included from most/all places for CONFIG_JUMP_LABEL.
|
2016-08-03 13:46:36 -07:00
|
|
|
*/
|
|
|
|
int static_key_count(struct static_key *key)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* -1 means the first static_key_slow_inc() is in progress.
|
|
|
|
* static_key_enabled() must return true, so return 1 here.
|
|
|
|
*/
|
|
|
|
int n = atomic_read(&key->enabled);
|
|
|
|
|
|
|
|
return n >= 0 ? n : 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_count);
|
|
|
|
|
2022-11-23 10:38:55 -07:00
|
|
|
/*
|
|
|
|
* static_key_fast_inc_not_disabled - adds a user for a static key
|
|
|
|
* @key: static key that must be already enabled
|
|
|
|
*
|
|
|
|
* The caller must make sure that the static key can't get disabled while
|
|
|
|
* in this function. It doesn't patch jump labels, only adds a user to
|
|
|
|
* an already enabled static key.
|
|
|
|
*
|
|
|
|
* Returns true if the increment was done. Unlike refcount_t the ref counter
|
|
|
|
* is not saturated, but will fail to increment on overflow.
|
|
|
|
*/
|
|
|
|
bool static_key_fast_inc_not_disabled(struct static_key *key)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
2022-11-23 10:38:55 -07:00
|
|
|
int v;
|
|
|
|
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2022-11-23 10:38:55 -07:00
|
|
|
/*
|
|
|
|
* Negative key->enabled has a special meaning: it sends
|
2024-06-10 05:46:36 -07:00
|
|
|
* static_key_slow_inc/dec() down the slow path, and it is non-zero
|
2024-06-10 05:46:37 -07:00
|
|
|
* so it counts as "enabled" in jump_label_update().
|
|
|
|
*
|
|
|
|
* The INT_MAX overflow condition is either used by the networking
|
|
|
|
* code to reset or detected in the slow path of
|
|
|
|
* static_key_slow_inc_cpuslocked().
|
2022-11-23 10:38:55 -07:00
|
|
|
*/
|
|
|
|
v = atomic_read(&key->enabled);
|
|
|
|
do {
|
2024-06-10 05:46:37 -07:00
|
|
|
if (v <= 0 || v == INT_MAX)
|
2022-11-23 10:38:55 -07:00
|
|
|
return false;
|
|
|
|
} while (!likely(atomic_try_cmpxchg(&key->enabled, &v, v + 1)));
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_fast_inc_not_disabled);
|
|
|
|
|
|
|
|
bool static_key_slow_inc_cpuslocked(struct static_key *key)
|
|
|
|
{
|
2018-07-31 05:35:32 -07:00
|
|
|
lockdep_assert_cpus_held();
|
2016-06-21 09:52:17 -07:00
|
|
|
|
|
|
|
/*
|
2024-06-10 05:46:36 -07:00
|
|
|
* Careful if we get concurrent static_key_slow_inc/dec() calls;
|
2016-06-21 09:52:17 -07:00
|
|
|
* later calls must wait for the first one to _finish_ the
|
|
|
|
* jump_label_update() process. At the same time, however,
|
|
|
|
* the jump_label_update() call below wants to see
|
|
|
|
* static_key_enabled(&key) for jumps to be updated properly.
|
|
|
|
*/
|
2022-11-23 10:38:55 -07:00
|
|
|
if (static_key_fast_inc_not_disabled(key))
|
|
|
|
return true;
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2024-06-10 05:46:39 -07:00
|
|
|
guard(mutex)(&jump_label_mutex);
|
|
|
|
/* Try to mark it as 'enabling in progress. */
|
|
|
|
if (!atomic_cmpxchg(&key->enabled, 0, -1)) {
|
2015-07-24 06:06:37 -07:00
|
|
|
jump_label_update(key);
|
2017-08-01 14:58:50 -07:00
|
|
|
/*
|
2024-06-10 05:46:39 -07:00
|
|
|
* Ensure that when static_key_fast_inc_not_disabled() or
|
2024-09-09 03:50:09 -07:00
|
|
|
* static_key_dec_not_one() observe the positive value,
|
2024-06-10 05:46:39 -07:00
|
|
|
* they must also observe all the text changes.
|
2017-08-01 14:58:50 -07:00
|
|
|
*/
|
|
|
|
atomic_set_release(&key->enabled, 1);
|
2016-06-21 09:52:17 -07:00
|
|
|
} else {
|
2024-06-10 05:46:39 -07:00
|
|
|
/*
|
|
|
|
* While holding the mutex this should never observe
|
|
|
|
* anything else than a value >= 1 and succeed
|
|
|
|
*/
|
|
|
|
if (WARN_ON_ONCE(!static_key_fast_inc_not_disabled(key)))
|
2022-11-23 10:38:55 -07:00
|
|
|
return false;
|
2016-06-21 09:52:17 -07:00
|
|
|
}
|
2022-11-23 10:38:55 -07:00
|
|
|
return true;
|
2017-08-01 01:02:55 -07:00
|
|
|
}
|
|
|
|
|
2022-11-23 10:38:55 -07:00
|
|
|
bool static_key_slow_inc(struct static_key *key)
|
2017-08-01 01:02:55 -07:00
|
|
|
{
|
2022-11-23 10:38:55 -07:00
|
|
|
bool ret;
|
|
|
|
|
2017-08-01 01:02:55 -07:00
|
|
|
cpus_read_lock();
|
2022-11-23 10:38:55 -07:00
|
|
|
ret = static_key_slow_inc_cpuslocked(key);
|
2017-05-24 01:15:35 -07:00
|
|
|
cpus_read_unlock();
|
2022-11-23 10:38:55 -07:00
|
|
|
return ret;
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
2012-02-24 00:31:31 -07:00
|
|
|
EXPORT_SYMBOL_GPL(static_key_slow_inc);
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2017-08-01 01:02:56 -07:00
|
|
|
void static_key_enable_cpuslocked(struct static_key *key)
|
2017-08-01 08:24:04 -07:00
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2018-07-31 05:35:32 -07:00
|
|
|
lockdep_assert_cpus_held();
|
2017-08-01 01:02:56 -07:00
|
|
|
|
2017-08-01 08:24:04 -07:00
|
|
|
if (atomic_read(&key->enabled) > 0) {
|
|
|
|
WARN_ON_ONCE(atomic_read(&key->enabled) != 1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
jump_label_lock();
|
|
|
|
if (atomic_read(&key->enabled) == 0) {
|
|
|
|
atomic_set(&key->enabled, -1);
|
|
|
|
jump_label_update(key);
|
2017-08-01 14:58:50 -07:00
|
|
|
/*
|
|
|
|
* See static_key_slow_inc().
|
|
|
|
*/
|
|
|
|
atomic_set_release(&key->enabled, 1);
|
2017-08-01 08:24:04 -07:00
|
|
|
}
|
|
|
|
jump_label_unlock();
|
2017-08-01 01:02:56 -07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_enable_cpuslocked);
|
|
|
|
|
|
|
|
void static_key_enable(struct static_key *key)
|
|
|
|
{
|
|
|
|
cpus_read_lock();
|
|
|
|
static_key_enable_cpuslocked(key);
|
2017-08-01 08:24:04 -07:00
|
|
|
cpus_read_unlock();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_enable);
|
|
|
|
|
2017-08-01 01:02:56 -07:00
|
|
|
void static_key_disable_cpuslocked(struct static_key *key)
|
2017-08-01 08:24:04 -07:00
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2018-07-31 05:35:32 -07:00
|
|
|
lockdep_assert_cpus_held();
|
2017-08-01 01:02:56 -07:00
|
|
|
|
2017-08-01 08:24:04 -07:00
|
|
|
if (atomic_read(&key->enabled) != 1) {
|
|
|
|
WARN_ON_ONCE(atomic_read(&key->enabled) != 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
jump_label_lock();
|
2024-07-31 03:43:21 -07:00
|
|
|
if (atomic_cmpxchg(&key->enabled, 1, 0) == 1)
|
2017-08-01 08:24:04 -07:00
|
|
|
jump_label_update(key);
|
|
|
|
jump_label_unlock();
|
2017-08-01 01:02:56 -07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_disable_cpuslocked);
|
|
|
|
|
|
|
|
void static_key_disable(struct static_key *key)
|
|
|
|
{
|
|
|
|
cpus_read_lock();
|
|
|
|
static_key_disable_cpuslocked(key);
|
2017-08-01 08:24:04 -07:00
|
|
|
cpus_read_unlock();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(static_key_disable);
|
|
|
|
|
2024-09-09 03:50:09 -07:00
|
|
|
static bool static_key_dec_not_one(struct static_key *key)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
2024-06-10 05:46:36 -07:00
|
|
|
int v;
|
2018-07-31 05:35:32 -07:00
|
|
|
|
2016-06-21 09:52:17 -07:00
|
|
|
/*
|
2024-06-10 05:46:36 -07:00
|
|
|
* Go into the slow path if key::enabled is less than or equal than
|
|
|
|
* one. One is valid to shut down the key, anything less than one
|
|
|
|
* is an imbalance, which is handled at the call site.
|
|
|
|
*
|
|
|
|
* That includes the special case of '-1' which is set in
|
|
|
|
* static_key_slow_inc_cpuslocked(), but that's harmless as it is
|
|
|
|
* fully serialized in the slow path below. By the time this task
|
|
|
|
* acquires the jump label lock the value is back to one and the
|
|
|
|
* retry under the lock must succeed.
|
2016-06-21 09:52:17 -07:00
|
|
|
*/
|
2024-06-10 05:46:36 -07:00
|
|
|
v = atomic_read(&key->enabled);
|
|
|
|
do {
|
|
|
|
/*
|
|
|
|
* Warn about the '-1' case though; since that means a
|
|
|
|
* decrement is concurrent with a first (0->1) increment. IOW
|
|
|
|
* people are trying to disable something that wasn't yet fully
|
|
|
|
* enabled. This suggests an ordering problem on the user side.
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(v < 0);
|
2024-09-09 03:50:09 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Warn about underflow, and lie about success in an attempt to
|
|
|
|
* not make things worse.
|
|
|
|
*/
|
|
|
|
if (WARN_ON_ONCE(v == 0))
|
|
|
|
return true;
|
|
|
|
|
2024-06-10 05:46:36 -07:00
|
|
|
if (v <= 1)
|
|
|
|
return false;
|
|
|
|
} while (!likely(atomic_try_cmpxchg(&key->enabled, &v, v - 1)));
|
|
|
|
|
2019-03-29 17:08:53 -07:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-03-29 17:08:54 -07:00
|
|
|
static void __static_key_slow_dec_cpuslocked(struct static_key *key)
|
2019-03-29 17:08:53 -07:00
|
|
|
{
|
|
|
|
lockdep_assert_cpus_held();
|
2024-09-09 03:50:09 -07:00
|
|
|
int val;
|
2019-03-29 17:08:53 -07:00
|
|
|
|
2024-09-09 03:50:09 -07:00
|
|
|
if (static_key_dec_not_one(key))
|
2011-03-16 14:29:47 -07:00
|
|
|
return;
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2024-06-10 05:46:36 -07:00
|
|
|
guard(mutex)(&jump_label_mutex);
|
2024-09-09 03:50:09 -07:00
|
|
|
val = atomic_read(&key->enabled);
|
|
|
|
/*
|
|
|
|
* It should be impossible to observe -1 with jump_label_mutex held,
|
|
|
|
* see static_key_slow_inc_cpuslocked().
|
|
|
|
*/
|
|
|
|
if (WARN_ON_ONCE(val == -1))
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* Cannot already be 0, something went sideways.
|
|
|
|
*/
|
|
|
|
if (WARN_ON_ONCE(val == 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (atomic_dec_and_test(&key->enabled))
|
2019-03-29 17:08:54 -07:00
|
|
|
jump_label_update(key);
|
2017-08-01 01:02:55 -07:00
|
|
|
}
|
|
|
|
|
2019-03-29 17:08:54 -07:00
|
|
|
static void __static_key_slow_dec(struct static_key *key)
|
2017-08-01 01:02:55 -07:00
|
|
|
{
|
|
|
|
cpus_read_lock();
|
2019-03-29 17:08:54 -07:00
|
|
|
__static_key_slow_dec_cpuslocked(key);
|
2017-05-24 01:15:35 -07:00
|
|
|
cpus_read_unlock();
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
|
|
|
|
2019-03-29 17:08:52 -07:00
|
|
|
void jump_label_update_timeout(struct work_struct *work)
|
2011-11-27 08:59:09 -07:00
|
|
|
{
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key_deferred *key =
|
|
|
|
container_of(work, struct static_key_deferred, work.work);
|
2019-03-29 17:08:54 -07:00
|
|
|
__static_key_slow_dec(&key->key);
|
2011-11-27 08:59:09 -07:00
|
|
|
}
|
2019-03-29 17:08:52 -07:00
|
|
|
EXPORT_SYMBOL_GPL(jump_label_update_timeout);
|
2011-11-27 08:59:09 -07:00
|
|
|
|
2012-02-24 00:31:31 -07:00
|
|
|
void static_key_slow_dec(struct static_key *key)
|
2011-11-27 08:59:09 -07:00
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2019-03-29 17:08:54 -07:00
|
|
|
__static_key_slow_dec(key);
|
2011-11-27 08:59:09 -07:00
|
|
|
}
|
2012-02-24 00:31:31 -07:00
|
|
|
EXPORT_SYMBOL_GPL(static_key_slow_dec);
|
2011-11-27 08:59:09 -07:00
|
|
|
|
2018-01-22 14:53:28 -07:00
|
|
|
void static_key_slow_dec_cpuslocked(struct static_key *key)
|
|
|
|
{
|
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2019-03-29 17:08:54 -07:00
|
|
|
__static_key_slow_dec_cpuslocked(key);
|
2018-01-22 14:53:28 -07:00
|
|
|
}
|
|
|
|
|
2019-03-29 17:08:52 -07:00
|
|
|
void __static_key_slow_dec_deferred(struct static_key *key,
|
|
|
|
struct delayed_work *work,
|
|
|
|
unsigned long timeout)
|
2011-11-27 08:59:09 -07:00
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2019-03-29 17:08:54 -07:00
|
|
|
|
2024-09-09 03:50:09 -07:00
|
|
|
if (static_key_dec_not_one(key))
|
2019-03-29 17:08:54 -07:00
|
|
|
return;
|
|
|
|
|
|
|
|
schedule_delayed_work(work, timeout);
|
2011-11-27 08:59:09 -07:00
|
|
|
}
|
2019-03-29 17:08:52 -07:00
|
|
|
EXPORT_SYMBOL_GPL(__static_key_slow_dec_deferred);
|
2011-11-27 08:59:09 -07:00
|
|
|
|
2019-03-29 17:08:52 -07:00
|
|
|
void __static_key_deferred_flush(void *key, struct delayed_work *work)
|
2016-12-16 15:30:35 -07:00
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2019-03-29 17:08:52 -07:00
|
|
|
flush_delayed_work(work);
|
2016-12-16 15:30:35 -07:00
|
|
|
}
|
2019-03-29 17:08:52 -07:00
|
|
|
EXPORT_SYMBOL_GPL(__static_key_deferred_flush);
|
2016-12-16 15:30:35 -07:00
|
|
|
|
2012-02-24 00:31:31 -07:00
|
|
|
void jump_label_rate_limit(struct static_key_deferred *key,
|
2011-11-27 08:59:09 -07:00
|
|
|
unsigned long rl)
|
|
|
|
{
|
2017-10-18 08:24:28 -07:00
|
|
|
STATIC_KEY_CHECK_USE(key);
|
2011-11-27 08:59:09 -07:00
|
|
|
key->timeout = rl;
|
|
|
|
INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
|
|
|
|
}
|
2012-08-05 05:58:29 -07:00
|
|
|
EXPORT_SYMBOL_GPL(jump_label_rate_limit);
|
2011-11-27 08:59:09 -07:00
|
|
|
|
2010-09-17 08:09:08 -07:00
|
|
|
static int addr_conflict(struct jump_entry *entry, void *start, void *end)
|
|
|
|
{
|
2018-09-18 23:51:36 -07:00
|
|
|
if (jump_entry_code(entry) <= (unsigned long)end &&
|
2021-05-06 12:33:58 -07:00
|
|
|
jump_entry_code(entry) + jump_entry_size(entry) > (unsigned long)start)
|
2010-09-17 08:09:08 -07:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
static int __jump_label_text_reserved(struct jump_entry *iter_start,
|
2021-06-28 04:24:10 -07:00
|
|
|
struct jump_entry *iter_stop, void *start, void *end, bool init)
|
2010-09-17 08:09:08 -07:00
|
|
|
{
|
|
|
|
struct jump_entry *iter;
|
|
|
|
|
|
|
|
iter = iter_start;
|
|
|
|
while (iter < iter_stop) {
|
2021-06-28 04:24:10 -07:00
|
|
|
if (init || !jump_entry_is_init(iter)) {
|
|
|
|
if (addr_conflict(iter, start, end))
|
|
|
|
return 1;
|
|
|
|
}
|
2010-09-17 08:09:08 -07:00
|
|
|
iter++;
|
|
|
|
}
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-15 08:41:42 -07:00
|
|
|
#ifndef arch_jump_label_transform_static
|
|
|
|
static void arch_jump_label_transform_static(struct jump_entry *entry,
|
|
|
|
enum jump_label_type type)
|
2011-10-03 11:01:46 -07:00
|
|
|
{
|
2022-06-15 08:41:42 -07:00
|
|
|
/* nothing to do on most architectures */
|
2011-10-03 11:01:46 -07:00
|
|
|
}
|
2022-06-15 08:41:42 -07:00
|
|
|
#endif
|
2011-10-03 11:01:46 -07:00
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static inline struct jump_entry *static_key_entries(struct static_key *key)
|
2011-03-16 14:29:47 -07:00
|
|
|
{
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
WARN_ON_ONCE(key->type & JUMP_TYPE_LINKED);
|
|
|
|
return (struct jump_entry *)(key->type & ~JUMP_TYPE_MASK);
|
2010-09-17 08:09:08 -07:00
|
|
|
}
|
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static inline bool static_key_type(struct static_key *key)
|
2012-02-24 00:31:31 -07:00
|
|
|
{
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
return key->type & JUMP_TYPE_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool static_key_linked(struct static_key *key)
|
|
|
|
{
|
|
|
|
return key->type & JUMP_TYPE_LINKED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void static_key_clear_linked(struct static_key *key)
|
|
|
|
{
|
|
|
|
key->type &= ~JUMP_TYPE_LINKED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void static_key_set_linked(struct static_key *key)
|
|
|
|
{
|
|
|
|
key->type |= JUMP_TYPE_LINKED;
|
2015-07-24 05:55:40 -07:00
|
|
|
}
|
2012-02-24 00:31:31 -07:00
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
/***
|
|
|
|
* A 'struct static_key' uses a union such that it either points directly
|
|
|
|
* to a table of 'struct jump_entry' or to a linked list of modules which in
|
|
|
|
* turn point to 'struct jump_entry' tables.
|
|
|
|
*
|
|
|
|
* The two lower bits of the pointer are used to keep track of which pointer
|
|
|
|
* type is in use and to store the initial branch direction, we use an access
|
|
|
|
* function which preserves these bits.
|
|
|
|
*/
|
|
|
|
static void static_key_set_entries(struct static_key *key,
|
|
|
|
struct jump_entry *entries)
|
|
|
|
{
|
|
|
|
unsigned long type;
|
|
|
|
|
|
|
|
WARN_ON_ONCE((unsigned long)entries & JUMP_TYPE_MASK);
|
|
|
|
type = key->type & JUMP_TYPE_MASK;
|
|
|
|
key->entries = entries;
|
|
|
|
key->type |= type;
|
|
|
|
}
|
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static enum jump_label_type jump_label_type(struct jump_entry *entry)
|
2015-07-24 05:55:40 -07:00
|
|
|
{
|
2015-07-24 06:06:37 -07:00
|
|
|
struct static_key *key = jump_entry_key(entry);
|
2015-07-24 05:55:40 -07:00
|
|
|
bool enabled = static_key_enabled(key);
|
2018-09-18 23:51:36 -07:00
|
|
|
bool branch = jump_entry_is_branch(entry);
|
2012-02-24 00:31:31 -07:00
|
|
|
|
2015-07-24 06:09:55 -07:00
|
|
|
/* See the comment in linux/jump_label.h */
|
|
|
|
return enabled ^ branch;
|
2012-02-24 00:31:31 -07:00
|
|
|
}
|
|
|
|
|
2019-06-12 02:57:26 -07:00
|
|
|
static bool jump_label_can_update(struct jump_entry *entry, bool init)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Cannot update code that was in an init text area.
|
|
|
|
*/
|
|
|
|
if (!init && jump_entry_is_init(entry))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!kernel_text_address(jump_entry_code(entry))) {
|
2021-03-18 03:31:51 -07:00
|
|
|
/*
|
|
|
|
* This skips patching built-in __exit, which
|
|
|
|
* is part of init_section_contains() but is
|
|
|
|
* not part of kernel_text_address().
|
|
|
|
*
|
|
|
|
* Skipping built-in __exit is fine since it
|
|
|
|
* will never be executed.
|
|
|
|
*/
|
2019-08-28 10:50:05 -07:00
|
|
|
WARN_ONCE(!jump_entry_is_init(entry),
|
|
|
|
"can't patch jump_label at %pS",
|
|
|
|
(void *)jump_entry_code(entry));
|
2019-06-12 02:57:26 -07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
jump_label: Batch updates if arch supports it
If the architecture supports the batching of jump label updates, use it!
An easy way to see the benefits of this patch is switching the
schedstats on and off. For instance:
-------------------------- %< ----------------------------
#!/bin/sh
while [ true ]; do
sysctl -w kernel.sched_schedstats=1
sleep 2
sysctl -w kernel.sched_schedstats=0
sleep 2
done
-------------------------- >% ----------------------------
while watching the IPI count:
-------------------------- %< ----------------------------
# watch -n1 "cat /proc/interrupts | grep Function"
-------------------------- >% ----------------------------
With the current mode, it is possible to see +- 168 IPIs each 2 seconds,
while with this patch the number of IPIs goes to 3 each 2 seconds.
Regarding the performance impact of this patch set, I made two measurements:
The time to update a key (the task that is causing the change)
The time to run the int3 handler (the side effect on a thread that
hits the code being changed)
The schedstats static key was chosen as the key to being switched on and off.
The reason being is that it is used in more than 56 places, in a hot path. The
change in the schedstats static key will be done with the following command:
while [ true ]; do
sysctl -w kernel.sched_schedstats=1
usleep 500000
sysctl -w kernel.sched_schedstats=0
usleep 500000
done
In this way, they key will be updated twice per second. To force the hit of the
int3 handler, the system will also run a kernel compilation with two jobs per
CPU. The test machine is a two nodes/24 CPUs box with an Intel Xeon processor
@2.27GHz.
Regarding the update part, on average, the regular kernel takes 57 ms to update
the schedstats key, while the kernel with the batch updates takes just 1.4 ms
on average. Although it seems to be too good to be true, it makes sense: the
schedstats key is used in 56 places, so it was expected that it would take
around 56 times to update the keys with the current implementation, as the
IPIs are the most expensive part of the update.
Regarding the int3 handler, the non-batch handler takes 45 ns on average, while
the batch version takes around 180 ns. At first glance, it seems to be a high
value. But it is not, considering that it is doing 56 updates, rather than one!
It is taking four times more, only. This gain is possible because the patch
uses a binary search in the vector: log2(56)=5.8. So, it was expected to have
an overhead within four times.
(voice of tv propaganda) But, that is not all! As the int3 handler keeps on for
a shorter period (because the update part is on for a shorter time), the number
of hits in the int3 handler decreased by 10%.
The question then is: Is it worth paying the price of "135 ns" more in the int3
handler?
Considering that, in this test case, we are saving the handling of 53 IPIs,
that takes more than these 135 ns, it seems to be a meager price to be paid.
Moreover, the test case was forcing the hit of the int3, in practice, it
does not take that often. While the IPI takes place on all CPUs, hitting
the int3 handler or not!
For instance, in an isolated CPU with a process running in user-space
(nohz_full use-case), the chances of hitting the int3 handler is barely zero,
while there is no way to avoid the IPIs. By bounding the IPIs, we are improving
a lot this scenario.
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/acc891dbc2dbc9fd616dd680529a2337b1d1274c.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 02:57:30 -07:00
|
|
|
#ifndef HAVE_JUMP_LABEL_BATCH
|
2015-07-24 06:06:37 -07:00
|
|
|
static void __jump_label_update(struct static_key *key,
|
|
|
|
struct jump_entry *entry,
|
2018-09-18 23:51:42 -07:00
|
|
|
struct jump_entry *stop,
|
|
|
|
bool init)
|
2015-07-24 06:06:37 -07:00
|
|
|
{
|
|
|
|
for (; (entry < stop) && (jump_entry_key(entry) == key); entry++) {
|
2019-06-12 02:57:26 -07:00
|
|
|
if (jump_label_can_update(entry, init))
|
|
|
|
arch_jump_label_transform(entry, jump_label_type(entry));
|
2015-07-24 06:06:37 -07:00
|
|
|
}
|
|
|
|
}
|
jump_label: Batch updates if arch supports it
If the architecture supports the batching of jump label updates, use it!
An easy way to see the benefits of this patch is switching the
schedstats on and off. For instance:
-------------------------- %< ----------------------------
#!/bin/sh
while [ true ]; do
sysctl -w kernel.sched_schedstats=1
sleep 2
sysctl -w kernel.sched_schedstats=0
sleep 2
done
-------------------------- >% ----------------------------
while watching the IPI count:
-------------------------- %< ----------------------------
# watch -n1 "cat /proc/interrupts | grep Function"
-------------------------- >% ----------------------------
With the current mode, it is possible to see +- 168 IPIs each 2 seconds,
while with this patch the number of IPIs goes to 3 each 2 seconds.
Regarding the performance impact of this patch set, I made two measurements:
The time to update a key (the task that is causing the change)
The time to run the int3 handler (the side effect on a thread that
hits the code being changed)
The schedstats static key was chosen as the key to being switched on and off.
The reason being is that it is used in more than 56 places, in a hot path. The
change in the schedstats static key will be done with the following command:
while [ true ]; do
sysctl -w kernel.sched_schedstats=1
usleep 500000
sysctl -w kernel.sched_schedstats=0
usleep 500000
done
In this way, they key will be updated twice per second. To force the hit of the
int3 handler, the system will also run a kernel compilation with two jobs per
CPU. The test machine is a two nodes/24 CPUs box with an Intel Xeon processor
@2.27GHz.
Regarding the update part, on average, the regular kernel takes 57 ms to update
the schedstats key, while the kernel with the batch updates takes just 1.4 ms
on average. Although it seems to be too good to be true, it makes sense: the
schedstats key is used in 56 places, so it was expected that it would take
around 56 times to update the keys with the current implementation, as the
IPIs are the most expensive part of the update.
Regarding the int3 handler, the non-batch handler takes 45 ns on average, while
the batch version takes around 180 ns. At first glance, it seems to be a high
value. But it is not, considering that it is doing 56 updates, rather than one!
It is taking four times more, only. This gain is possible because the patch
uses a binary search in the vector: log2(56)=5.8. So, it was expected to have
an overhead within four times.
(voice of tv propaganda) But, that is not all! As the int3 handler keeps on for
a shorter period (because the update part is on for a shorter time), the number
of hits in the int3 handler decreased by 10%.
The question then is: Is it worth paying the price of "135 ns" more in the int3
handler?
Considering that, in this test case, we are saving the handling of 53 IPIs,
that takes more than these 135 ns, it seems to be a meager price to be paid.
Moreover, the test case was forcing the hit of the int3, in practice, it
does not take that often. While the IPI takes place on all CPUs, hitting
the int3 handler or not!
For instance, in an isolated CPU with a process running in user-space
(nohz_full use-case), the chances of hitting the int3 handler is barely zero,
while there is no way to avoid the IPIs. By bounding the IPIs, we are improving
a lot this scenario.
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/acc891dbc2dbc9fd616dd680529a2337b1d1274c.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 02:57:30 -07:00
|
|
|
#else
|
|
|
|
static void __jump_label_update(struct static_key *key,
|
|
|
|
struct jump_entry *entry,
|
|
|
|
struct jump_entry *stop,
|
|
|
|
bool init)
|
|
|
|
{
|
|
|
|
for (; (entry < stop) && (jump_entry_key(entry) == key); entry++) {
|
|
|
|
|
|
|
|
if (!jump_label_can_update(entry, init))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!arch_jump_label_transform_queue(entry, jump_label_type(entry))) {
|
|
|
|
/*
|
|
|
|
* Queue is full: Apply the current queue and try again.
|
|
|
|
*/
|
|
|
|
arch_jump_label_transform_apply();
|
|
|
|
BUG_ON(!arch_jump_label_transform_queue(entry, jump_label_type(entry)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
arch_jump_label_transform_apply();
|
|
|
|
}
|
|
|
|
#endif
|
2015-07-24 06:06:37 -07:00
|
|
|
|
2011-10-12 16:17:54 -07:00
|
|
|
void __init jump_label_init(void)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
|
|
|
struct jump_entry *iter_start = __start___jump_table;
|
|
|
|
struct jump_entry *iter_stop = __stop___jump_table;
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key *key = NULL;
|
2010-09-17 08:09:00 -07:00
|
|
|
struct jump_entry *iter;
|
|
|
|
|
2016-08-03 13:46:36 -07:00
|
|
|
/*
|
|
|
|
* Since we are initializing the static_key.enabled field with
|
|
|
|
* with the 'raw' int values (to avoid pulling in atomic.h) in
|
|
|
|
* jump_label.h, let's make sure that is safe. There are only two
|
|
|
|
* cases to check since we initialize to 0 or 1.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON((int)ATOMIC_INIT(0) != 0);
|
|
|
|
BUILD_BUG_ON((int)ATOMIC_INIT(1) != 1);
|
|
|
|
|
2016-07-23 02:12:37 -07:00
|
|
|
if (static_key_initialized)
|
|
|
|
return;
|
|
|
|
|
2017-05-24 01:15:35 -07:00
|
|
|
cpus_read_lock();
|
2010-10-01 14:23:48 -07:00
|
|
|
jump_label_lock();
|
2011-03-16 14:29:47 -07:00
|
|
|
jump_label_sort_entries(iter_start, iter_stop);
|
|
|
|
|
|
|
|
for (iter = iter_start; iter < iter_stop; iter++) {
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key *iterk;
|
2021-05-06 12:34:00 -07:00
|
|
|
bool in_init;
|
2011-09-29 11:10:05 -07:00
|
|
|
|
2015-07-24 06:09:55 -07:00
|
|
|
/* rewrite NOPs */
|
|
|
|
if (jump_label_type(iter) == JUMP_LABEL_NOP)
|
|
|
|
arch_jump_label_transform_static(iter, JUMP_LABEL_NOP);
|
|
|
|
|
2021-05-06 12:34:00 -07:00
|
|
|
in_init = init_section_contains((void *)jump_entry_code(iter), 1);
|
|
|
|
jump_entry_set_init(iter, in_init);
|
2018-09-18 23:51:42 -07:00
|
|
|
|
2015-07-24 06:02:27 -07:00
|
|
|
iterk = jump_entry_key(iter);
|
2011-09-29 11:10:05 -07:00
|
|
|
if (iterk == key)
|
2011-03-16 14:29:47 -07:00
|
|
|
continue;
|
|
|
|
|
2011-09-29 11:10:05 -07:00
|
|
|
key = iterk;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
static_key_set_entries(key, iter);
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
2013-10-19 12:48:53 -07:00
|
|
|
static_key_initialized = true;
|
2010-10-01 14:23:48 -07:00
|
|
|
jump_label_unlock();
|
2017-05-24 01:15:35 -07:00
|
|
|
cpus_read_unlock();
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
|
|
|
|
2024-03-13 11:01:03 -07:00
|
|
|
static inline bool static_key_sealed(struct static_key *key)
|
|
|
|
{
|
|
|
|
return (key->type & JUMP_TYPE_LINKED) && !(key->type & ~JUMP_TYPE_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void static_key_seal(struct static_key *key)
|
|
|
|
{
|
|
|
|
unsigned long type = key->type & JUMP_TYPE_TRUE;
|
|
|
|
key->type = JUMP_TYPE_LINKED | type;
|
|
|
|
}
|
|
|
|
|
|
|
|
void jump_label_init_ro(void)
|
|
|
|
{
|
|
|
|
struct jump_entry *iter_start = __start___jump_table;
|
|
|
|
struct jump_entry *iter_stop = __stop___jump_table;
|
|
|
|
struct jump_entry *iter;
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!static_key_initialized))
|
|
|
|
return;
|
|
|
|
|
|
|
|
cpus_read_lock();
|
|
|
|
jump_label_lock();
|
|
|
|
|
|
|
|
for (iter = iter_start; iter < iter_stop; iter++) {
|
|
|
|
struct static_key *iterk = jump_entry_key(iter);
|
|
|
|
|
|
|
|
if (!is_kernel_ro_after_init((unsigned long)iterk))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (static_key_sealed(iterk))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
static_key_seal(iterk);
|
|
|
|
}
|
|
|
|
|
|
|
|
jump_label_unlock();
|
|
|
|
cpus_read_unlock();
|
|
|
|
}
|
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
|
2022-06-15 08:41:41 -07:00
|
|
|
enum jump_label_type jump_label_init_type(struct jump_entry *entry)
|
2015-07-24 06:09:55 -07:00
|
|
|
{
|
|
|
|
struct static_key *key = jump_entry_key(entry);
|
|
|
|
bool type = static_key_type(key);
|
2018-09-18 23:51:36 -07:00
|
|
|
bool branch = jump_entry_is_branch(entry);
|
2015-07-24 06:09:55 -07:00
|
|
|
|
|
|
|
/* See the comment in linux/jump_label.h */
|
|
|
|
return type ^ branch;
|
|
|
|
}
|
|
|
|
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key_mod {
|
|
|
|
struct static_key_mod *next;
|
2011-03-16 14:29:47 -07:00
|
|
|
struct jump_entry *entries;
|
|
|
|
struct module *mod;
|
|
|
|
};
|
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
static inline struct static_key_mod *static_key_mod(struct static_key *key)
|
|
|
|
{
|
2018-09-09 04:42:52 -07:00
|
|
|
WARN_ON_ONCE(!static_key_linked(key));
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
return (struct static_key_mod *)(key->type & ~JUMP_TYPE_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/***
|
|
|
|
* key->type and key->next are the same via union.
|
|
|
|
* This sets key->next and preserves the type bits.
|
|
|
|
*
|
|
|
|
* See additional comments above static_key_set_entries().
|
|
|
|
*/
|
|
|
|
static void static_key_set_mod(struct static_key *key,
|
|
|
|
struct static_key_mod *mod)
|
|
|
|
{
|
|
|
|
unsigned long type;
|
|
|
|
|
|
|
|
WARN_ON_ONCE((unsigned long)mod & JUMP_TYPE_MASK);
|
|
|
|
type = key->type & JUMP_TYPE_MASK;
|
|
|
|
key->next = mod;
|
|
|
|
key->type |= type;
|
|
|
|
}
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
static int __jump_label_mod_text_reserved(void *start, void *end)
|
|
|
|
{
|
|
|
|
struct module *mod;
|
2020-08-18 06:57:39 -07:00
|
|
|
int ret;
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2016-07-26 19:47:35 -07:00
|
|
|
preempt_disable();
|
2011-03-16 14:29:47 -07:00
|
|
|
mod = __module_text_address((unsigned long)start);
|
2016-07-26 19:47:35 -07:00
|
|
|
WARN_ON_ONCE(__module_text_address((unsigned long)end) != mod);
|
2020-08-18 06:57:39 -07:00
|
|
|
if (!try_module_get(mod))
|
|
|
|
mod = NULL;
|
2016-07-26 19:47:35 -07:00
|
|
|
preempt_enable();
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
if (!mod)
|
|
|
|
return 0;
|
|
|
|
|
2020-08-18 06:57:39 -07:00
|
|
|
ret = __jump_label_text_reserved(mod->jump_entries,
|
2011-03-16 14:29:47 -07:00
|
|
|
mod->jump_entries + mod->num_jump_entries,
|
2021-06-28 04:24:10 -07:00
|
|
|
start, end, mod->state == MODULE_STATE_COMING);
|
2020-08-18 06:57:39 -07:00
|
|
|
|
|
|
|
module_put(mod);
|
|
|
|
|
|
|
|
return ret;
|
2011-03-16 14:29:47 -07:00
|
|
|
}
|
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static void __jump_label_mod_update(struct static_key *key)
|
2011-03-16 14:29:47 -07:00
|
|
|
{
|
2015-07-24 06:06:37 -07:00
|
|
|
struct static_key_mod *mod;
|
2011-03-16 14:29:47 -07:00
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
for (mod = static_key_mod(key); mod; mod = mod->next) {
|
|
|
|
struct jump_entry *stop;
|
|
|
|
struct module *m;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NULL if the static_key is defined in a module
|
|
|
|
* that does not use it
|
|
|
|
*/
|
|
|
|
if (!mod->entries)
|
|
|
|
continue;
|
2011-05-10 03:43:46 -07:00
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
m = mod->mod;
|
|
|
|
if (!m)
|
|
|
|
stop = __stop___jump_table;
|
|
|
|
else
|
|
|
|
stop = m->jump_entries + m->num_jump_entries;
|
2018-09-18 23:51:42 -07:00
|
|
|
__jump_label_update(key, mod->entries, stop,
|
2018-10-01 01:13:24 -07:00
|
|
|
m && m->state == MODULE_STATE_COMING);
|
2011-03-16 14:29:47 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int jump_label_add_module(struct module *mod)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
2011-03-16 14:29:47 -07:00
|
|
|
struct jump_entry *iter_start = mod->jump_entries;
|
|
|
|
struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
|
|
|
|
struct jump_entry *iter;
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key *key = NULL;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
struct static_key_mod *jlm, *jlm2;
|
2010-09-17 08:09:00 -07:00
|
|
|
|
|
|
|
/* if the module doesn't have jump label entries, just return */
|
2011-03-16 14:29:47 -07:00
|
|
|
if (iter_start == iter_stop)
|
2010-09-17 08:09:00 -07:00
|
|
|
return 0;
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
jump_label_sort_entries(iter_start, iter_stop);
|
|
|
|
|
|
|
|
for (iter = iter_start; iter < iter_stop; iter++) {
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key *iterk;
|
2021-05-06 12:34:00 -07:00
|
|
|
bool in_init;
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2021-05-06 12:34:00 -07:00
|
|
|
in_init = within_module_init(jump_entry_code(iter), mod);
|
|
|
|
jump_entry_set_init(iter, in_init);
|
2018-09-18 23:51:42 -07:00
|
|
|
|
2015-07-24 06:02:27 -07:00
|
|
|
iterk = jump_entry_key(iter);
|
2012-02-24 00:31:31 -07:00
|
|
|
if (iterk == key)
|
|
|
|
continue;
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2012-02-24 00:31:31 -07:00
|
|
|
key = iterk;
|
2018-09-18 23:51:36 -07:00
|
|
|
if (within_module((unsigned long)key, mod)) {
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
static_key_set_entries(key, iter);
|
2011-03-16 14:29:47 -07:00
|
|
|
continue;
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
2024-03-13 11:01:03 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the key was sealed at init, then there's no need to keep a
|
|
|
|
* reference to its module entries - just patch them now and be
|
|
|
|
* done with it.
|
|
|
|
*/
|
|
|
|
if (static_key_sealed(key))
|
|
|
|
goto do_poke;
|
|
|
|
|
2012-02-24 00:31:31 -07:00
|
|
|
jlm = kzalloc(sizeof(struct static_key_mod), GFP_KERNEL);
|
2011-03-16 14:29:47 -07:00
|
|
|
if (!jlm)
|
|
|
|
return -ENOMEM;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
if (!static_key_linked(key)) {
|
|
|
|
jlm2 = kzalloc(sizeof(struct static_key_mod),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!jlm2) {
|
|
|
|
kfree(jlm);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
preempt_disable();
|
|
|
|
jlm2->mod = __module_address((unsigned long)key);
|
|
|
|
preempt_enable();
|
|
|
|
jlm2->entries = static_key_entries(key);
|
|
|
|
jlm2->next = NULL;
|
|
|
|
static_key_set_mod(key, jlm2);
|
|
|
|
static_key_set_linked(key);
|
|
|
|
}
|
2011-03-16 14:29:47 -07:00
|
|
|
jlm->mod = mod;
|
|
|
|
jlm->entries = iter;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
jlm->next = static_key_mod(key);
|
|
|
|
static_key_set_mod(key, jlm);
|
|
|
|
static_key_set_linked(key);
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2015-07-24 06:09:55 -07:00
|
|
|
/* Only update if we've changed from our initial state */
|
2024-03-13 11:01:03 -07:00
|
|
|
do_poke:
|
2015-07-24 06:09:55 -07:00
|
|
|
if (jump_label_type(iter) != jump_label_init_type(iter))
|
2018-09-18 23:51:42 -07:00
|
|
|
__jump_label_update(key, iter, iter_stop, true);
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
static void jump_label_del_module(struct module *mod)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
2011-03-16 14:29:47 -07:00
|
|
|
struct jump_entry *iter_start = mod->jump_entries;
|
|
|
|
struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
|
|
|
|
struct jump_entry *iter;
|
2012-02-24 00:31:31 -07:00
|
|
|
struct static_key *key = NULL;
|
|
|
|
struct static_key_mod *jlm, **prev;
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
for (iter = iter_start; iter < iter_stop; iter++) {
|
2015-07-24 06:02:27 -07:00
|
|
|
if (jump_entry_key(iter) == key)
|
2011-03-16 14:29:47 -07:00
|
|
|
continue;
|
|
|
|
|
2015-07-24 06:02:27 -07:00
|
|
|
key = jump_entry_key(iter);
|
2011-03-16 14:29:47 -07:00
|
|
|
|
2018-09-18 23:51:36 -07:00
|
|
|
if (within_module((unsigned long)key, mod))
|
2011-03-16 14:29:47 -07:00
|
|
|
continue;
|
|
|
|
|
2024-03-13 11:01:03 -07:00
|
|
|
/* No @jlm allocated because key was sealed at init. */
|
|
|
|
if (static_key_sealed(key))
|
|
|
|
continue;
|
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
/* No memory during module load */
|
|
|
|
if (WARN_ON(!static_key_linked(key)))
|
|
|
|
continue;
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
prev = &key->next;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
jlm = static_key_mod(key);
|
2010-09-17 08:09:00 -07:00
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
while (jlm && jlm->mod != mod) {
|
|
|
|
prev = &jlm->next;
|
|
|
|
jlm = jlm->next;
|
|
|
|
}
|
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
/* No memory during module load */
|
|
|
|
if (WARN_ON(!jlm))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (prev == &key->next)
|
|
|
|
static_key_set_mod(key, jlm->next);
|
|
|
|
else
|
2011-03-16 14:29:47 -07:00
|
|
|
*prev = jlm->next;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
|
|
|
|
kfree(jlm);
|
|
|
|
|
|
|
|
jlm = static_key_mod(key);
|
|
|
|
/* if only one etry is left, fold it back into the static_key */
|
|
|
|
if (jlm->next == NULL) {
|
|
|
|
static_key_set_entries(key, jlm->entries);
|
|
|
|
static_key_clear_linked(key);
|
2011-03-16 14:29:47 -07:00
|
|
|
kfree(jlm);
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
jump_label_module_notify(struct notifier_block *self, unsigned long val,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct module *mod = data;
|
|
|
|
int ret = 0;
|
|
|
|
|
2017-05-24 01:15:35 -07:00
|
|
|
cpus_read_lock();
|
|
|
|
jump_label_lock();
|
|
|
|
|
2010-09-17 08:09:00 -07:00
|
|
|
switch (val) {
|
|
|
|
case MODULE_STATE_COMING:
|
2011-03-16 14:29:47 -07:00
|
|
|
ret = jump_label_add_module(mod);
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
if (ret) {
|
2018-09-07 03:35:21 -07:00
|
|
|
WARN(1, "Failed to allocate memory: jump_label may not work properly.\n");
|
2011-03-16 14:29:47 -07:00
|
|
|
jump_label_del_module(mod);
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
}
|
2010-09-17 08:09:00 -07:00
|
|
|
break;
|
|
|
|
case MODULE_STATE_GOING:
|
2011-03-16 14:29:47 -07:00
|
|
|
jump_label_del_module(mod);
|
2010-09-17 08:09:00 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-05-24 01:15:35 -07:00
|
|
|
jump_label_unlock();
|
|
|
|
cpus_read_unlock();
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
return notifier_from_errno(ret);
|
2010-09-17 08:09:00 -07:00
|
|
|
}
|
|
|
|
|
2016-06-17 10:19:40 -07:00
|
|
|
static struct notifier_block jump_label_module_nb = {
|
2010-09-17 08:09:00 -07:00
|
|
|
.notifier_call = jump_label_module_notify,
|
2011-03-16 14:29:47 -07:00
|
|
|
.priority = 1, /* higher than tracepoints */
|
2010-09-17 08:09:00 -07:00
|
|
|
};
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
static __init int jump_label_init_module(void)
|
2010-09-17 08:09:00 -07:00
|
|
|
{
|
|
|
|
return register_module_notifier(&jump_label_module_nb);
|
|
|
|
}
|
2011-03-16 14:29:47 -07:00
|
|
|
early_initcall(jump_label_init_module);
|
2010-09-17 08:09:00 -07:00
|
|
|
|
|
|
|
#endif /* CONFIG_MODULES */
|
|
|
|
|
2011-03-16 14:29:47 -07:00
|
|
|
/***
|
|
|
|
* jump_label_text_reserved - check if addr range is reserved
|
|
|
|
* @start: start text addr
|
|
|
|
* @end: end text addr
|
|
|
|
*
|
|
|
|
* checks if the text addr located between @start and @end
|
|
|
|
* overlaps with any of the jump label patch addresses. Code
|
|
|
|
* that wants to modify kernel text should first verify that
|
|
|
|
* it does not overlap with any of the jump label addresses.
|
|
|
|
* Caller must hold jump_label_mutex.
|
|
|
|
*
|
|
|
|
* returns 1 if there is an overlap, 0 otherwise
|
|
|
|
*/
|
|
|
|
int jump_label_text_reserved(void *start, void *end)
|
|
|
|
{
|
2021-06-28 04:24:10 -07:00
|
|
|
bool init = system_state < SYSTEM_RUNNING;
|
2011-03-16 14:29:47 -07:00
|
|
|
int ret = __jump_label_text_reserved(__start___jump_table,
|
2021-06-28 04:24:10 -07:00
|
|
|
__stop___jump_table, start, end, init);
|
2011-03-16 14:29:47 -07:00
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
ret = __jump_label_mod_text_reserved(start, end);
|
|
|
|
#endif
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-07-24 06:06:37 -07:00
|
|
|
static void jump_label_update(struct static_key *key)
|
2011-03-16 14:29:47 -07:00
|
|
|
{
|
2012-02-24 00:31:31 -07:00
|
|
|
struct jump_entry *stop = __stop___jump_table;
|
2020-12-16 04:21:36 -07:00
|
|
|
bool init = system_state < SYSTEM_RUNNING;
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
struct jump_entry *entry;
|
2011-03-16 14:29:47 -07:00
|
|
|
#ifdef CONFIG_MODULES
|
2015-05-26 18:39:35 -07:00
|
|
|
struct module *mod;
|
2011-06-20 19:35:55 -07:00
|
|
|
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
if (static_key_linked(key)) {
|
|
|
|
__jump_label_mod_update(key);
|
|
|
|
return;
|
|
|
|
}
|
2011-06-20 19:35:55 -07:00
|
|
|
|
2015-05-26 18:39:35 -07:00
|
|
|
preempt_disable();
|
|
|
|
mod = __module_address((unsigned long)key);
|
2020-12-16 04:21:36 -07:00
|
|
|
if (mod) {
|
2011-06-20 19:35:55 -07:00
|
|
|
stop = mod->jump_entries + mod->num_jump_entries;
|
2020-12-16 04:21:36 -07:00
|
|
|
init = mod->state == MODULE_STATE_COMING;
|
|
|
|
}
|
2015-05-26 18:39:35 -07:00
|
|
|
preempt_enable();
|
2011-03-16 14:29:47 -07:00
|
|
|
#endif
|
jump_label: Reduce the size of struct static_key
The static_key->next field goes mostly unused. The field is used for
associating module uses with a static key. Most uses of struct static_key
define a static key in the core kernel and make use of it entirely within
the core kernel, or define the static key in a module and make use of it
only from within that module. In fact, of the ~3,000 static keys defined,
I found only about 5 or so that did not fit this pattern.
Thus, we can remove the static_key->next field entirely and overload
the static_key->entries field. That is, when all the static_key uses
are contained within the same module, static_key->entries continues
to point to those uses. However, if the static_key uses are not contained
within the module where the static_key is defined, then we allocate a
struct static_key_mod, store a pointer to the uses within that
struct static_key_mod, and have the static key point at the static_key_mod.
This does incur some extra memory usage when a static_key is used in a
module that does not define it, but since there are only a handful of such
cases there is a net savings.
In order to identify if the static_key->entries pointer contains a
struct static_key_mod or a struct jump_entry pointer, bit 1 of
static_key->entries is set to 1 if it points to a struct static_key_mod and
is 0 if it points to a struct jump_entry. We were already using bit 0 in a
similar way to store the initial value of the static_key. This does mean
that allocations of struct static_key_mod and that the struct jump_entry
tables need to be at least 4-byte aligned in memory. As far as I can tell
all arches meet this criteria.
For my .config, the patch increased the text by 778 bytes, but reduced
the data + bss size by 14912, for a net savings of 14,134 bytes.
text data bss dec hex filename
8092427 5016512 790528 13899467 d416cb vmlinux.pre
8093205 5001600 790528 13885333 d3df95 vmlinux.post
Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-02-03 13:42:24 -07:00
|
|
|
entry = static_key_entries(key);
|
2011-06-20 19:35:55 -07:00
|
|
|
/* if there are no users, entry can be NULL */
|
|
|
|
if (entry)
|
2020-12-16 04:21:36 -07:00
|
|
|
__jump_label_update(key, entry, stop, init);
|
2011-03-16 14:29:47 -07:00
|
|
|
}
|
|
|
|
|
2015-07-27 09:32:09 -07:00
|
|
|
#ifdef CONFIG_STATIC_KEYS_SELFTEST
|
|
|
|
static DEFINE_STATIC_KEY_TRUE(sk_true);
|
|
|
|
static DEFINE_STATIC_KEY_FALSE(sk_false);
|
|
|
|
|
|
|
|
static __init int jump_label_test(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 2; i++) {
|
|
|
|
WARN_ON(static_key_enabled(&sk_true.key) != true);
|
|
|
|
WARN_ON(static_key_enabled(&sk_false.key) != false);
|
|
|
|
|
|
|
|
WARN_ON(!static_branch_likely(&sk_true));
|
|
|
|
WARN_ON(!static_branch_unlikely(&sk_true));
|
|
|
|
WARN_ON(static_branch_likely(&sk_false));
|
|
|
|
WARN_ON(static_branch_unlikely(&sk_false));
|
|
|
|
|
|
|
|
static_branch_disable(&sk_true);
|
|
|
|
static_branch_enable(&sk_false);
|
|
|
|
|
|
|
|
WARN_ON(static_key_enabled(&sk_true.key) == true);
|
|
|
|
WARN_ON(static_key_enabled(&sk_false.key) == false);
|
|
|
|
|
|
|
|
WARN_ON(static_branch_likely(&sk_true));
|
|
|
|
WARN_ON(static_branch_unlikely(&sk_true));
|
|
|
|
WARN_ON(!static_branch_likely(&sk_false));
|
|
|
|
WARN_ON(!static_branch_unlikely(&sk_false));
|
|
|
|
|
|
|
|
static_branch_enable(&sk_true);
|
|
|
|
static_branch_disable(&sk_false);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2017-11-13 14:48:47 -07:00
|
|
|
early_initcall(jump_label_test);
|
2015-07-27 09:32:09 -07:00
|
|
|
#endif /* STATIC_KEYS_SELFTEST */
|