Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2357913rwb; Fri, 11 Nov 2022 08:13:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf6xbAq6Bw1p1vrmwFM3VOyhiXjHzTNWnl/Clj4hyHaPcqGzEyMRsVhOZtbNLjTitrefpPRV X-Received: by 2002:a17:903:2788:b0:188:64b7:e433 with SMTP id jw8-20020a170903278800b0018864b7e433mr3313850plb.17.1668183239652; Fri, 11 Nov 2022 08:13:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668183239; cv=none; d=google.com; s=arc-20160816; b=Csxx8ON5bm4Dl20+boxS4ogcr/yRvRLXIcV0cSByb8Nu3CTI8hreQQeoREMZwAKG4u x2aNozhqg20q6eodIQ586GiV0yeIU1sHO/h12/lsSaOb0NOI3DkRuf9H5/+8tVKGbeLQ a+G+WGeGzgzlg2vtZnCvSnQ4aROyDXpbj4eWuIi+0M9fgPn8TAXdZ1iSloQg60mKC/mf Im4GRQ0BH6tvJCrEMdISm+Z6Fr1zThsmbFKgKJMPiK3hJLJuevw743E/4j+r3cCKHskl 2GDN7ByqxTDoa0EBw+l/OLEtU1VhaZFt7/1YEugP7SMGXjwUzVXQKbIz5sVQam6Hc6yN Mm7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=muhy8/X6qyhPhPaCUUlmnlcITmJN+okpbg1Hf0EptoE=; b=iGtoWy7dCN9rtm0E2/mWOgGhf84mRlheIhBe+/rDl6A4TQBGmxXJpEkCFW49XuLd0v 0LjVNMGCOR8wpFKjG7gQVqHW7BcxN0KBbi4uxrheDKzu5QZP1pgsEpJEHrcKagjBq3f7 hXbC2gu9XorCJrp3CUh30Z6Md5jbbuJg3a+EF1YR4PLplrhuZp8MJAG05LS1ZT2N6z/Q WA4G/glzM52VXGRiZUg1Tbhcw+VYmyFbX6amLiELy7ekQvdCBWCKz0KLsGEn6jUuOcrv R9SxHOCFgUS96xCTg0wgCq5q9Oe7mz9JE/5PdoOfgFXZXABtmUy9VviX9JthVomOvzVX zjbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 7-20020a630207000000b0047011874d9fsi2857236pgc.627.2022.11.11.08.13.47; Fri, 11 Nov 2022 08:13:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234186AbiKKPtb (ORCPT + 91 others); Fri, 11 Nov 2022 10:49:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234188AbiKKPtQ (ORCPT ); Fri, 11 Nov 2022 10:49:16 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2325AF03C for ; Fri, 11 Nov 2022 07:49:14 -0800 (PST) Received: from kwepemi100025.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4N836353knzRp6d; Fri, 11 Nov 2022 23:48:59 +0800 (CST) Received: from [10.174.148.223] (10.174.148.223) by kwepemi100025.china.huawei.com (7.221.188.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 11 Nov 2022 23:49:11 +0800 Message-ID: <0f25506f-b9ca-1578-f944-cfb3936ced50@huawei.com> Date: Fri, 11 Nov 2022 23:49:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] vp_vdpa: harden the logic of set status To: Stefano Garzarella CC: , , , , , , , , References: <20221111145505.1232-1-longpeng2@huawei.com> <20221111151459.dyz42jclq26ai26q@sgarzare-redhat> From: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" In-Reply-To: <20221111151459.dyz42jclq26ai26q@sgarzare-redhat> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.148.223] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemi100025.china.huawei.com (7.221.188.158) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 在 2022/11/11 23:14, Stefano Garzarella 写道: > On Fri, Nov 11, 2022 at 10:55:05PM +0800, Longpeng(Mike) wrote: >> From: Longpeng >> >> 1. We should not set status to 0 when invoking vp_vdpa_set_status(). >> >> 2. The driver MUST wait for a read of device_status to return 0 before >>   reinitializing the device. >> >> Signed-off-by: Longpeng >> --- >> drivers/vdpa/virtio_pci/vp_vdpa.c | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c >> b/drivers/vdpa/virtio_pci/vp_vdpa.c >> index d448db0c4de3..d35fac5cde11 100644 >> --- a/drivers/vdpa/virtio_pci/vp_vdpa.c >> +++ b/drivers/vdpa/virtio_pci/vp_vdpa.c >> @@ -212,8 +212,12 @@ static void vp_vdpa_set_status(struct vdpa_device >> *vdpa, u8 status) >> { >>     struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa); >>     struct virtio_pci_modern_device *mdev = vp_vdpa_to_mdev(vp_vdpa); >> -    u8 s = vp_vdpa_get_status(vdpa); > > Is this change really needed? > No need to get the status if we try to set status to 0 (trigger BUG). >> +    u8 s; >> + >> +    /* We should never be setting status to 0. */ >> +    BUG_ON(status == 0); > > IMHO panicking the kernel seems excessive in this case, please use > WARN_ON and maybe return earlier. > Um...I referenced the vp_reset/vp_set_status, >> >> +    s = vp_vdpa_get_status(vdpa); >>     if (status & VIRTIO_CONFIG_S_DRIVER_OK && >>         !(s & VIRTIO_CONFIG_S_DRIVER_OK)) { >>         vp_vdpa_request_irq(vp_vdpa); >> @@ -229,6 +233,11 @@ static int vp_vdpa_reset(struct vdpa_device *vdpa) >>     u8 s = vp_vdpa_get_status(vdpa); >> >>     vp_modern_set_status(mdev, 0); >> +    /* After writing 0 to device_status, the driver MUST wait for a >> read of >> +     * device_status to return 0 before reinitializing the device. >> +     */ >> +    while (vp_modern_get_status(mdev)) >> +        msleep(1); > > Should we set a limit after which we give up? A malfunctioning device > could keep us here forever. > Yes, but the malfunctioning device maybe can not work anymore, how to handle it? > Thanks, > Stefano > >> >>     if (s & VIRTIO_CONFIG_S_DRIVER_OK) >>         vp_vdpa_free_irq(vp_vdpa); >> -- >> 2.23.0 >> > > .