From: Paolo Bonzini <pbonzini@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Andrew Jones <drjones@redhat.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 1/7] static_key: flush rate limit timer on rmmod
Date: Thu, 17 Oct 2013 12:35:29 +0200 [thread overview]
Message-ID: <525FBD71.7000608@redhat.com> (raw)
In-Reply-To: <1382004631-25895-2-git-send-email-rkrcmar@redhat.com>
Il 17/10/2013 12:10, Radim Krčmář ha scritto:
> Fix a bug when we free module memory while timer is pending by marking
> deferred static keys and flushing the timer on module unload.
>
> Also make static_key_rate_limit() useable more than once.
>
> Reproducer: (host crasher)
> modprobe kvm_intel
> (sleep 1; echo quit) \
> | qemu-kvm -kernel /dev/null -monitor stdio &
> sleep 0.5
> until modprobe -rv kvm_intel 2>/dev/null; do true; done
> modprobe -v kvm_intel
>
> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
> ---
> Very hacky; I've already queued generalizing ratelimit and applying it
> here, but there is still a lot to do on static keys ...
>
> include/linux/jump_label.h | 1 +
> kernel/jump_label.c | 17 ++++++++++++++++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index a507907..848bd15 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -58,6 +58,7 @@ struct static_key {
> #ifdef CONFIG_MODULES
> struct static_key_mod *next;
> #endif
> + atomic_t deferred;
> };
>
> # include <asm/jump_label.h>
> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index 297a924..7018042 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -116,8 +116,9 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
> void jump_label_rate_limit(struct static_key_deferred *key,
> unsigned long rl)
> {
> + if (!atomic_xchg(&key->key.deferred, 1))
> + INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
Can it actually happen that jump_label_rate_limit is called multiple
times? If so, this hunk alone would be a separate bugfix. I don't
think all the concurrency that you're protecting against can actually
happen, but in any case I'd just take the jump_label_lock() instead of
using atomics.
It's also not necessary to use a new field, since you can just check
key->timeout.
All this gives something like this for static_key_rate_limit_flush:
if (key->timeout) {
jump_label_lock();
if (key->enabled) {
jump_label_unlock();
flush_delayed_work(&dkey->work);
} else
jump_label_unlock();
}
Paolo
> key->timeout = rl;
> - INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
> }
> EXPORT_SYMBOL_GPL(jump_label_rate_limit);
>
> @@ -185,6 +186,14 @@ static enum jump_label_type jump_label_type(struct static_key *key)
> return JUMP_LABEL_DISABLE;
> }
>
> +static void static_key_rate_limit_flush(struct static_key *key)
> +{
> + struct static_key_deferred *dkey =
> + container_of(key, struct static_key_deferred, key);
> + if (atomic_read(&key->deferred))
> + flush_delayed_work(&dkey->work);
> +}
> +
> void __init jump_label_init(void)
> {
> struct jump_entry *iter_start = __start___jump_table;
> @@ -334,6 +343,12 @@ static void jump_label_del_module(struct module *mod)
>
> key = (struct static_key *)(unsigned long)iter->key;
>
> + /* We could also check if the static_key is used in its
> + * defining module and skip this flush then.
> + * (Rewrite of ratelimit in planned, so we don't care much)
> + */
> + static_key_rate_limit_flush(key);
> +
> if (__module_address(iter->key) == mod)
> continue;
>
>
next prev parent reply other threads:[~2013-10-17 10:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 10:10 [PATCH 0/7] static_key: fix timer bugs & change api (a bit) Radim Krčmář
2013-10-17 10:10 ` [PATCH 1/7] static_key: flush rate limit timer on rmmod Radim Krčmář
2013-10-17 10:35 ` Paolo Bonzini [this message]
2013-10-18 7:24 ` Radim Krčmář
2013-10-17 10:10 ` [PATCH 2/7] static_key: add static_key_slow_inc_deferred() Radim Krčmář
2013-10-17 10:10 ` [PATCH 3/7] static_key: keep deferred enabled counter debt Radim Krčmář
2013-10-17 10:10 ` [PATCH 4/7] static_key: use static_key_slow_inc_deferred() Radim Krčmář
2013-10-17 10:39 ` Paolo Bonzini
2013-10-18 7:29 ` Radim Krčmář
2013-10-17 10:10 ` [PATCH 5/7] jump_label: relax branch hinting restrictions Radim Krčmář
2013-10-17 17:35 ` Steven Rostedt
2013-10-18 7:30 ` Radim Krčmář
2013-10-17 10:10 ` [PATCH 7/7] init: execute jump_label_init() earlier Radim Krčmář
2013-10-17 10:43 ` [PATCH 0/7] static_key: fix timer bugs & change api (a bit) Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525FBD71.7000608@redhat.com \
--to=pbonzini@redhat.com \
--cc=drjones@redhat.com \
--cc=hpa@linux.intel.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox