Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1790360pxp; Mon, 7 Mar 2022 02:23:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzJK+oZKLi3t8UQB+HLBUMETEYZqhgCPcgaHMWy5FmbzdlRt3DKi8Yh4Hlhvk7knmpL30hd X-Received: by 2002:a63:5451:0:b0:378:6b6c:ed83 with SMTP id e17-20020a635451000000b003786b6ced83mr9206742pgm.446.1646648591495; Mon, 07 Mar 2022 02:23:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646648591; cv=none; d=google.com; s=arc-20160816; b=DjcvZmYGgEYk5OV5WmaTXm8FCc6nclwHXAHfbJFbS+pVOcmAEoK7iW3DKfGdXBU14W NoFTuoRN04CQR5+Kcf2XTJ3fDtxf8DQz1f5zi0SE00CBKpQBgiC2bG0plm2eWK9JoHSl EGJgj5ela4NOH5zyhJOEsNlj9XBJE96vWU/Aee0SjlzxAdUCQPG1libU1cz34M7JAoCK OVBBrjZFu9cWqWCohBaEU283pA0NmnRHDkvmH9ZJJuaazF6/+mYzGWaJaZkhinyipKuV 2SU9gw15W3Wn0yYaEmS/H/z04Hq02d9iVmw++RgsEDbvraO9+v/E7xnrWpbtkp4CdDpQ 09ig== 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=AX1Jx8mslM1jCD8GbxxsefVAMJ27zngWShMknkMsJ6g=; b=Zhkcfzi0O/A7jawxhl+SfdX6B1fRDnvpgnUrJQglCPCjaZBtjSEPHaQz9GN5XjlW7m hDVFTVGt+s2iPRGBpY52OR8gCMV//phkQJov1SeOMSbu952witcIyaDSPICYVUFUE3Lr mSDFZXFwklj8Foo7ZCizhy0k7W8N4261o93kvMDBUoWbty1DHWycBZHZ+aw7340+17MN s/pttD3CkfYGHQ0/MMHisen/vRJvSRQm2Nc5+7TPWYY/jOJUTfKTsL/QHgO3TSQ3zlfI o9dJGZTTGmVajsJWGzoqzB/a1TuTx37iraMVO7mI/4YYlrEizfwc5PRd8F8jwllg3BPu rc9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=TWm5DT2y; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n4-20020a170902e54400b00151bf332ad4si8751560plf.2.2022.03.07.02.22.57; Mon, 07 Mar 2022 02:23:11 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=TWm5DT2y; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238335AbiCGJzp (ORCPT + 99 others); Mon, 7 Mar 2022 04:55:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238402AbiCGJiY (ORCPT ); Mon, 7 Mar 2022 04:38:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3B7C62119; Mon, 7 Mar 2022 01:32:36 -0800 (PST) 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 189C260FF6; Mon, 7 Mar 2022 09:32:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AFBFC340E9; Mon, 7 Mar 2022 09:31:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646645520; bh=4cUGAbYITudA30+l+BZM4feCWlq9YwWvrWfKixVO6Zo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TWm5DT2yGkQxjeork6mxvtQg2B+UqiNisTgGgU5SnPdFZfW13l5GVuSA0L/BRV6Wa 3jqUuihnIXQx7quQr7utrOJY4oBo/vReDgvVc19T9ed9NEN8JYsVRjjvdMqxB+44aZ /4KpxpfHZRyRAxV/E4fkxzyfH0CapMp0lG5NI+dU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jacob Keller , Konrad Jankowski , Tony Nguyen Subject: [PATCH 5.10 056/105] ice: fix concurrent reset and removal of VFs Date: Mon, 7 Mar 2022 10:18:59 +0100 Message-Id: <20220307091645.757736961@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091644.179885033@linuxfoundation.org> References: <20220307091644.179885033@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=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 From: Jacob Keller commit fadead80fe4c033b5e514fcbadd20b55c4494112 upstream. Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs. This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession. It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues. Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit. Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. This ensures that we cannot remove the VF while any outstanding critical tasks such as a virtchnl message or a reset are occurring. This locking change also fixes the root cause originally fixed by commit c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we can simply revert it. Note that I kept these two changes together because simply reverting the original commit alone would leave the driver vulnerable to worse race conditions. Fixes: c503e63200c6 ("ice: Stop processing VF messages during teardown") Signed-off-by: Jacob Keller Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/intel/ice/ice_main.c | 2 + drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 35 ++++++++++++++++------- 2 files changed, 27 insertions(+), 10 deletions(-) --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -1602,7 +1602,9 @@ static void ice_handle_mdd_event(struct * reset, so print the event prior to reset. */ ice_print_vf_rx_mdd_event(vf); + mutex_lock(&pf->vf[i].cfg_lock); ice_reset_vf(&pf->vf[i], false); + mutex_unlock(&pf->vf[i].cfg_lock); } } } --- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c @@ -360,22 +360,26 @@ void ice_free_vfs(struct ice_pf *pf) else dev_warn(dev, "VFs are assigned - not disabling SR-IOV\n"); - /* Avoid wait time by stopping all VFs at the same time */ - ice_for_each_vf(pf, i) - ice_dis_vf_qs(&pf->vf[i]); - tmp = pf->num_alloc_vfs; pf->num_qps_per_vf = 0; pf->num_alloc_vfs = 0; for (i = 0; i < tmp; i++) { - if (test_bit(ICE_VF_STATE_INIT, pf->vf[i].vf_states)) { + struct ice_vf *vf = &pf->vf[i]; + + mutex_lock(&vf->cfg_lock); + + ice_dis_vf_qs(vf); + + if (test_bit(ICE_VF_STATE_INIT, vf->vf_states)) { /* disable VF qp mappings and set VF disable state */ - ice_dis_vf_mappings(&pf->vf[i]); - set_bit(ICE_VF_STATE_DIS, pf->vf[i].vf_states); - ice_free_vf_res(&pf->vf[i]); + ice_dis_vf_mappings(vf); + set_bit(ICE_VF_STATE_DIS, vf->vf_states); + ice_free_vf_res(vf); } - mutex_destroy(&pf->vf[i].cfg_lock); + mutex_unlock(&vf->cfg_lock); + + mutex_destroy(&vf->cfg_lock); } if (ice_sriov_free_msix_res(pf)) @@ -1223,9 +1227,13 @@ bool ice_reset_all_vfs(struct ice_pf *pf ice_for_each_vf(pf, v) { vf = &pf->vf[v]; + mutex_lock(&vf->cfg_lock); + ice_vf_pre_vsi_rebuild(vf); ice_vf_rebuild_vsi(vf); ice_vf_post_vsi_rebuild(vf); + + mutex_unlock(&vf->cfg_lock); } ice_flush(hw); @@ -1272,6 +1280,8 @@ bool ice_reset_vf(struct ice_vf *vf, boo u32 reg; int i; + lockdep_assert_held(&vf->cfg_lock); + dev = ice_pf_to_dev(pf); if (test_bit(__ICE_VF_RESETS_DISABLED, pf->state)) { @@ -1725,9 +1735,12 @@ void ice_process_vflr_event(struct ice_p bit_idx = (hw->func_caps.vf_base_id + vf_id) % 32; /* read GLGEN_VFLRSTAT register to find out the flr VFs */ reg = rd32(hw, GLGEN_VFLRSTAT(reg_idx)); - if (reg & BIT(bit_idx)) + if (reg & BIT(bit_idx)) { /* GLGEN_VFLRSTAT bit will be cleared in ice_reset_vf */ + mutex_lock(&vf->cfg_lock); ice_reset_vf(vf, true); + mutex_unlock(&vf->cfg_lock); + } } } @@ -1804,7 +1817,9 @@ ice_vf_lan_overflow_event(struct ice_pf if (!vf) return; + mutex_lock(&vf->cfg_lock); ice_vc_reset_vf(vf); + mutex_unlock(&vf->cfg_lock); } /**