Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp122561iof; Sun, 5 Jun 2022 23:02:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxq+aQutn18vOQQK8JCWUnWErRaORjg+KDqLSx4l/wqze9rew9F+Sx5/EuZQTljoK+z0zEN X-Received: by 2002:a62:d10e:0:b0:51b:d711:b189 with SMTP id z14-20020a62d10e000000b0051bd711b189mr18547147pfg.40.1654495367028; Sun, 05 Jun 2022 23:02:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654495367; cv=none; d=google.com; s=arc-20160816; b=CYcNDXY7ueLNBpor8gnhquR73TIkzXq7wzaxeURfCD3G6yLQUGR3JCYsedPPcDNaDZ fNAwgOIHDtOc1qzNPw+qAuzBkGBWfIoeSUDjYKwONjYfFys4J9p1lo311O24JpEXopoe A3Ji7JU9avc+RrKZnF84OT4rU3/zAk3Wm7+zkQIZzSUEPaL9GLBPNYAEexcGnv/0JtQm nd//bYAu8d4YiFnMmZkZK9p0r9urY4MTc5mzXYFfgttEsYVXUNf9+AZpauX0dmK4dzuT G4pKxIPExgEDmMhVj9HOjGJb/Bm1r5n1m3Mkd1RHE2P8pdiWHkAuZtlm5iS1V7lxUF0A zZEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=WMOtfeNCRjQCKp3N7qKtbgzQJGDjKVa0/x8niFPof+o=; b=qk/Yq6Rz77Q02k+bLc0+JzODLhnvSjGUCGr+fIpmEQE6A19bv4X8TwMP3ltkGcawaG 1M2jiCK9exeksnVBFM6b6Ig7kY31rsi9VJRP4CYnJcdRQlkUx9DYbQTJ6nDcozowK+HS g+z14h4prgETrxmFuDAbDGtjoeKhos5uGK9J7AP1T/OKYzQtpAmbw6+9N+J5MQ2rvdJA /G+GxnCY93g8adVA+s4YGnM+CIo1R+crWTKRQIGYdn9WyxbcJx6rFGZlB1rkdHHIJrq5 ki0is8vv82zuOwqRmMFkzkbkz+O8nY7y2IWUh44NnRenWfRidxeMt1i8WgGrrYY5ct20 AKQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UtaAMXSF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j2-20020a63cf02000000b003f84815e5d8si18539804pgg.634.2022.06.05.23.02.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 23:02:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UtaAMXSF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 524C330F6E4; Sun, 5 Jun 2022 21:50:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346071AbiFCR7g (ORCPT + 99 others); Fri, 3 Jun 2022 13:59:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346235AbiFCRuy (ORCPT ); Fri, 3 Jun 2022 13:50:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 930CD5A09A; Fri, 3 Jun 2022 10:47:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A6C2260A57; Fri, 3 Jun 2022 17:47:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B821EC385A9; Fri, 3 Jun 2022 17:47:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278435; bh=4CV2YYdOdmtQY/EHPZAR8SenSGDXz6x4jpKV19cuIKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UtaAMXSFh/jUidi3209vJXcff2PlDFoyIri/41GRdi74FUtEb+6TPuRe23CtJ5WJq hL2wUWCioEWXS7HNYK9CzKVWbt8oGEcrqrpmkKCPD8t6zZUCPlJq9x1PYYcyt+/VFE Xh2iPgyY2ybo+Pjb2MRpK2pgjKN1Y1IR66ttM7G0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yajun Deng , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.10 32/53] x86/kvm: Alloc dummy async #PF token outside of raw spinlock Date: Fri, 3 Jun 2022 19:43:17 +0200 Message-Id: <20220603173819.658900854@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson commit 0547758a6de3cc71a0cfdd031a3621a30db6a68b upstream. Drop the raw spinlock in kvm_async_pf_task_wake() before allocating the the dummy async #PF token, the allocator is preemptible on PREEMPT_RT kernels and must not be called from truly atomic contexts. Opportunistically document why it's ok to loop on allocation failure, i.e. why the function won't get stuck in an infinite loop. Reported-by: Yajun Deng Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/kvm.c | 41 +++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 14 deletions(-) --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -188,7 +188,7 @@ void kvm_async_pf_task_wake(u32 token) { u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS); struct kvm_task_sleep_head *b = &async_pf_sleepers[key]; - struct kvm_task_sleep_node *n; + struct kvm_task_sleep_node *n, *dummy = NULL; if (token == ~0) { apf_task_wake_all(); @@ -200,28 +200,41 @@ again: n = _find_apf_task(b, token); if (!n) { /* - * async PF was not yet handled. - * Add dummy entry for the token. + * Async #PF not yet handled, add a dummy entry for the token. + * Allocating the token must be down outside of the raw lock + * as the allocator is preemptible on PREEMPT_RT kernels. */ - n = kzalloc(sizeof(*n), GFP_ATOMIC); - if (!n) { + if (!dummy) { + raw_spin_unlock(&b->lock); + dummy = kzalloc(sizeof(*dummy), GFP_KERNEL); + /* - * Allocation failed! Busy wait while other cpu - * handles async PF. + * Continue looping on allocation failure, eventually + * the async #PF will be handled and allocating a new + * node will be unnecessary. + */ + if (!dummy) + cpu_relax(); + + /* + * Recheck for async #PF completion before enqueueing + * the dummy token to avoid duplicate list entries. */ - raw_spin_unlock(&b->lock); - cpu_relax(); goto again; } - n->token = token; - n->cpu = smp_processor_id(); - init_swait_queue_head(&n->wq); - hlist_add_head(&n->link, &b->list); + dummy->token = token; + dummy->cpu = smp_processor_id(); + init_swait_queue_head(&dummy->wq); + hlist_add_head(&dummy->link, &b->list); + dummy = NULL; } else { 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);