Messages in this thread | | | Date | Fri, 20 May 2022 14:49:19 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCH] KVM: x86: Move kzalloc out of atomic context on PREEMPT_RT |
| |
On Fri, May 20, 2022, Paolo Bonzini wrote: > On 5/19/22 17:11, Sean Christopherson wrote: > > AFAICT, kfree() is safe to call under a raw spinlock, so this? Compile tested > > only... > > Freeing outside the lock is not complicated enough to check if it is: > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > index 6aa1241a80b7..f849f7c9fbf2 100644 > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -229,12 +229,15 @@ void kvm_async_pf_task_wake(u32 token) > dummy->cpu = smp_processor_id(); > init_swait_queue_head(&dummy->wq); > hlist_add_head(&dummy->link, &b->list); > + dummy = NULL; > } else { > - kfree(dummy); > apf_task_wake_one(n); > } > raw_spin_unlock(&b->lock); > - return; > + > + /* A dummy token might be allocated and ultimately not used. */ > + if (dummy) > + kfree(dummy); > } > EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake); > > > I queued your patch with the above fixup.
Ha, I wrote it exactly that way, then grepped around found a few instances of kfree() being called in side a raw spinlock, so changed it back :-)
100% agree it's not worth having to generate another patch if it turns out those callers are wrong.
| |