Modules that use static_key_deferred need a way to synchronize with
any delayed work that is still pending when the module is unloaded.
Introduce static_key_deferred_flush() which flushes any pending
jump label updates.
Signed-off-by: David Matlack <[email protected]>
---
include/linux/jump_label_ratelimit.h | 5 +++++
kernel/jump_label.c | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
index 089f70f..23da3af 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -14,6 +14,7 @@ struct static_key_deferred {
#ifdef HAVE_JUMP_LABEL
extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void static_key_deferred_flush(struct static_key_deferred *key);
extern void
jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
@@ -26,6 +27,10 @@ static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
STATIC_KEY_CHECK_USE();
static_key_slow_dec(&key->key);
}
+static inline void static_key_deferred_flush(struct static_key_deferred *key)
+{
+ STATIC_KEY_CHECK_USE();
+}
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 93ad6c1..a9b8cf5 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -182,6 +182,13 @@ void static_key_slow_dec_deferred(struct static_key_deferred *key)
}
EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
+void static_key_deferred_flush(struct static_key_deferred *key)
+{
+ STATIC_KEY_CHECK_USE();
+ flush_delayed_work(&key->work);
+}
+EXPORT_SYMBOL_GPL(static_key_deferred_flush);
+
void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
--
2.8.0.rc3.226.g39d4020
KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled).
These are implemented with delayed_work structs which can still be
pending when the KVM module is unloaded. We've seen this cause kernel
panics when the kvm_intel module is quickly reloaded.
Use the new static_key_deferred_flush() API to flush pending updates on
module unload.
Signed-off-by: David Matlack <[email protected]>
---
arch/x86/kvm/lapic.c | 6 ++++++
arch/x86/kvm/lapic.h | 1 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 8 insertions(+)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 34a66b2..1b80fa3 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2426,3 +2426,9 @@ void kvm_lapic_init(void)
jump_label_rate_limit(&apic_hw_disabled, HZ);
jump_label_rate_limit(&apic_sw_disabled, HZ);
}
+
+void kvm_lapic_exit(void)
+{
+ static_key_deferred_flush(&apic_hw_disabled);
+ static_key_deferred_flush(&apic_sw_disabled);
+}
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index e0c8023..ff8039d 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -110,6 +110,7 @@ static inline bool kvm_hv_vapic_assist_page_enabled(struct kvm_vcpu *vcpu)
int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data);
void kvm_lapic_init(void);
+void kvm_lapic_exit(void);
#define VEC_POS(v) ((v) & (32 - 1))
#define REG_POS(v) (((v) >> 5) << 4)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8f86c0c..da386bf 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6007,6 +6007,7 @@ int kvm_arch_init(void *opaque)
void kvm_arch_exit(void)
{
+ kvm_lapic_exit();
perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
--
2.8.0.rc3.226.g39d4020
2016-12-16 14:30-0800, David Matlack:
> KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled).
> These are implemented with delayed_work structs which can still be
> pending when the KVM module is unloaded. We've seen this cause kernel
> panics when the kvm_intel module is quickly reloaded.
>
> Use the new static_key_deferred_flush() API to flush pending updates on
> module unload.
>
> Signed-off-by: David Matlack <[email protected]>
> ---
Oh, this forgotten bug. I guess that patches to do this automatically
from generic module unload code would be over-engineering it ...
Reviewed-by: Radim Krčmář <[email protected]>
Thanks.
On Fri, Dec 16, 2016 at 02:30:35PM -0800, David Matlack wrote:
> Modules that use static_key_deferred need a way to synchronize with
> any delayed work that is still pending when the module is unloaded.
> Introduce static_key_deferred_flush() which flushes any pending
> jump label updates.
Makes sense I suppose.
It also appears I forgot to provide new style APIs for this
functionality as I completely forgot about it for it lives in its own
file :-/
In any case,
Acked-by: Peter Zijlstra (Intel) <[email protected]>
On 19/12/2016 15:58, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 02:30:35PM -0800, David Matlack wrote:
>> Modules that use static_key_deferred need a way to synchronize with
>> any delayed work that is still pending when the module is unloaded.
>> Introduce static_key_deferred_flush() which flushes any pending
>> jump label updates.
>
> Makes sense I suppose.
>
> It also appears I forgot to provide new style APIs for this
> functionality as I completely forgot about it for it lives in its own
> file :-/
>
> In any case,
>
> Acked-by: Peter Zijlstra (Intel) <[email protected]>
Thanks, I'll merge these through the KVM tree.
Paolo