From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9B21C43387 for ; Mon, 7 Jan 2019 12:59:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A8D9A2089F for ; Mon, 7 Jan 2019 12:59:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546865941; bh=SEjH7hWMk1kJ6wnWDgwH8nwggylSawVimdrxbvUl/H0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=CDP7vufz2b2CLBAPD95IN1zlfffSIBly5t1G5C/mXKMEhmCLjSMpiq9y+KK7t/viF cds15CmJIOHUDvEBgFrbQ73C8ZrM/AQe0PVVnFclS+LSVGONox6ecZj73CWljMKllO S61u53Q3s8LAkAEt4lIU7kaSOYvD9AShjE3VuZIs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730102AbfAGM7A (ORCPT ); Mon, 7 Jan 2019 07:59:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:46640 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727845AbfAGM66 (ORCPT ); Mon, 7 Jan 2019 07:58:58 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 577C1206BB; Mon, 7 Jan 2019 12:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546865937; bh=SEjH7hWMk1kJ6wnWDgwH8nwggylSawVimdrxbvUl/H0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeBlDKiO4FxbHPfbDpsSUTW+O1TJ21IIcLFfo0BEI1ZvO+BFRA/+XQpOouEoBPjVY sffY/9zwI047e5tb7o7pPaVq9/nwTT1lwx/oy6nyhL3pkLUct9CbaVINiSqLQbWX4/ yCzrdKr+MeEqnjfq33XNic1bf+kphBtvI0uaKgYE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Julien Thierry , Christoffer Dall , Marc Zyngier Subject: [PATCH 4.19 163/170] KVM: arm/arm64: vgic: Do not cond_resched_lock() with IRQs disabled Date: Mon, 7 Jan 2019 13:33:10 +0100 Message-Id: <20190107104512.186733941@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190107104452.953560660@linuxfoundation.org> References: <20190107104452.953560660@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Julien Thierry commit 2e2f6c3c0b08eed3fcf7de3c7684c940451bdeb1 upstream. To change the active state of an MMIO, halt is requested for all vcpus of the affected guest before modifying the IRQ state. This is done by calling cond_resched_lock() in vgic_mmio_change_active(). However interrupts are disabled at this point and we cannot reschedule a vcpu. We actually don't need any of this, as kvm_arm_halt_guest ensures that all the other vcpus are out of the guest. Let's just drop that useless code. Signed-off-by: Julien Thierry Suggested-by: Christoffer Dall Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman --- virt/kvm/arm/vgic/vgic-mmio.c | 21 --------------------- 1 file changed, 21 deletions(-) --- a/virt/kvm/arm/vgic/vgic-mmio.c +++ b/virt/kvm/arm/vgic/vgic-mmio.c @@ -313,27 +313,6 @@ static void vgic_mmio_change_active(stru spin_lock_irqsave(&irq->irq_lock, flags); - /* - * If this virtual IRQ was written into a list register, we - * have to make sure the CPU that runs the VCPU thread has - * synced back the LR state to the struct vgic_irq. - * - * As long as the conditions below are true, we know the VCPU thread - * may be on its way back from the guest (we kicked the VCPU thread in - * vgic_change_active_prepare) and still has to sync back this IRQ, - * so we release and re-acquire the spin_lock to let the other thread - * sync back the IRQ. - * - * When accessing VGIC state from user space, requester_vcpu is - * NULL, which is fine, because we guarantee that no VCPUs are running - * when accessing VGIC state from user space so irq->vcpu->cpu is - * always -1. - */ - while (irq->vcpu && /* IRQ may have state in an LR somewhere */ - irq->vcpu != requester_vcpu && /* Current thread is not the VCPU thread */ - irq->vcpu->cpu != -1) /* VCPU thread is running */ - cond_resched_lock(&irq->irq_lock); - if (irq->hw) { vgic_hw_irq_change_active(vcpu, irq, active, !requester_vcpu); } else {