Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp87575iof; Sun, 5 Jun 2022 21:59:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4fmeRcC4aAsocYVGRjpOE4T8D6m0/T9ggTxTXR55flISKmWq2ElfHJpEvUEMc1VQzaKL3 X-Received: by 2002:a17:90b:170b:b0:1e8:6d34:eba6 with SMTP id ko11-20020a17090b170b00b001e86d34eba6mr7503028pjb.105.1654491562076; Sun, 05 Jun 2022 21:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654491562; cv=none; d=google.com; s=arc-20160816; b=jVvYb6HtuHFBFk6PeyG7x+X3XlEzxs1vVXuJ/8NZvZiPhdRgeGgqn5/VOnp4SqCMSA m7aM5bhcdUCSkWnoJqcJ+KFZkridfDEy29gSFqhsbLFCzg054uciQcHd/ORA3Oq3eYCD +mBDHC942us8220JFa3dBCPwohhEHsCDejYNVVkIfpEu7GIgYGF2dNwBSzR9PpfZK2D3 onEJKs6R8JXdkaf2Qj6dzlwH4vhEwQ6zsI/XMiweOQer+cr1BxajIEuVyc3MNI4JjxmM 3Og7PtJqyyYxEgk/LzNK4Do4+gUf4KX5lGylO1WzkGF/hZJYs/rjnhYVldBaiSDgn5K0 6cLg== 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=FjUH2Iq3im0aBuqFdbMpXd5RBseLcho4Jb5n8QUBS/dWROZAPQHkVb5ZDwDtiwAtJy yFVgb3rwCIOXELMohfZAn6A0ycP0DODWjupchIU6r2HuyoEMKzhtmn7Uzz1s2ezU+XFZ ykqDGUrVUDLs/d1SyHtN7n/qb8lIGrkBv643zFzygBNRNo/S/Vzn8WEwnnsWuJAOOgCN Bvg4F/y8E9/t9Ho6NAu0vkMN5lotWIWOJbp1hkfSpAiYiaWigWrXaE47bH88E8oMlIva iEa+ue04cGOwN5SM9cGBKNulh8G8XMgE4O2obgj1kG4iknWHaEbEa4kO8PhI3ZZkEcDQ pv4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="bqhNK/7u"; 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 u17-20020a170902e81100b00163f793f119si22970578plg.196.2022.06.05.21.59.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 21:59:22 -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="bqhNK/7u"; 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 8F90C1157E7; Sun, 5 Jun 2022 21:13:22 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346009AbiFCR6m (ORCPT + 99 others); Fri, 3 Jun 2022 13:58:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346999AbiFCRvt (ORCPT ); Fri, 3 Jun 2022 13:51:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CF601023; Fri, 3 Jun 2022 10:49:56 -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 ams.source.kernel.org (Postfix) with ESMTPS id DDBD0B8241E; Fri, 3 Jun 2022 17:49:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32D8BC385A9; Fri, 3 Jun 2022 17:49:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278593; bh=4CV2YYdOdmtQY/EHPZAR8SenSGDXz6x4jpKV19cuIKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bqhNK/7uTqP2rLGIkVVDDRUtVZtL8dDgxHcol9rexwS3Ne1ORODOmZMKBDvvTGb6z 6zNYOQvniI0bJp9WhFRdiFZLRmb0PAcf95UtcfPKmpB0Mu5xB0hkLakEj3dU1vRgmP IYqWhMsN9eFvB+Ebi3x/RntjIwheTOB/6ZPiiBww= 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.15 29/66] x86/kvm: Alloc dummy async #PF token outside of raw spinlock Date: Fri, 3 Jun 2022 19:43:09 +0200 Message-Id: <20220603173821.498239266@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.663747061@linuxfoundation.org> References: <20220603173820.663747061@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);