lkml.org 
[lkml]   [2022]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2022-05-20 16:50    [W:0.067 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site