Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp638158pxb; Thu, 31 Mar 2022 13:37:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzB7ghHnesKDYL6Jz7xVwbOCfNIGz3SUlcEXSugXVyQ/JL1ohB8whh8wScN2EJOonu3BlFw X-Received: by 2002:a17:902:7686:b0:156:47a4:fc8f with SMTP id m6-20020a170902768600b0015647a4fc8fmr7300290pll.98.1648759066444; Thu, 31 Mar 2022 13:37:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648759066; cv=none; d=google.com; s=arc-20160816; b=XzqS4T48ZaoZrAStwcR/41yjkTj/zUKkbbogq5T80sLyJfx+fRqLFC68pfN/NE2v+H M4kFAIaCRlWoIyu3notizrHDRO6B0X/BjJBim0UHT9ESDc8gmGyfZWvMltCVseckdPVZ CJhSC/HVSCRb3BoqO6GmYHhzsbPSXKvPUdyDfHTcHMMCzERHmGk5iARevyjFxqduTscy Oz7FR/L5FB1V+vvOkQnfiX6O6OBoy42Q9F4D82kxVS48iKreTjzEWTmK85nAWpq7iYFX axpfS4oVhjrzUwoBE6UtBgWHquzOUWtGTRsfLKG7kMQwYVV4V+sbG6GtnqhmbTUNFj+B tckw== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=4AfbyPy4SWzRXPVjHP0oBQj2Lh8yjlIRr7X3xHwYmlQ=; b=FF1lO29+f0kGh1zuBXFvlWpFRoFSwf4HyvEzwD33VBVrDBrMeSRS3483ObHgagcSeX c4+AKHuU7FUa8tnLlHD7huXALeKt3OZMwS8WQx4PHmTTFwxXJyxiGSn1qUJuo99muO9x eQttho3jRPoUx2DU/WfrQkVsYtgM/PbJwMa8qo87W7RuNXKZBy7GeBithRmDSp7tAjiJ 761eLzjzwX9cVZo/sS1/AQbjpzMfhTqHFcBFw9JNPnoP6vgKOOsEC6nhJjRI+Wh4Zz15 AeNgpmMEflZhsqrmMmKnTk/eFHz2bajsLv4lgHwwlX5mAWDmYabmWXig5M+zCR+IpYZp lj9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Um1furVD; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m123-20020a633f81000000b00398997edf14si544802pga.534.2022.03.31.13.37.32; Thu, 31 Mar 2022 13:37:46 -0700 (PDT) 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=@redhat.com header.s=mimecast20190719 header.b=Um1furVD; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238527AbiCaPu2 (ORCPT + 99 others); Thu, 31 Mar 2022 11:50:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237419AbiCaPu0 (ORCPT ); Thu, 31 Mar 2022 11:50:26 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F07661116C for ; Thu, 31 Mar 2022 08:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648741718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4AfbyPy4SWzRXPVjHP0oBQj2Lh8yjlIRr7X3xHwYmlQ=; b=Um1furVD0vZqiV4iFx/qgSZ/beSsnVXi+iwtbIJC6BMZ2QWWbqFHSLFP5xuF4ILKDhcx+2 TJTuLjf1tE83loAuBO8pIt0PxmDyasKMoVjxoNtwIBMbwo5GjxQB7NdZ/w66OsAW74FhZt Sov8YQi/+VN7eFYT4a1uWtqNWHfvq+k= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-640-M8hUdgw9N_e9gs5xMqi0OA-1; Thu, 31 Mar 2022 11:48:36 -0400 X-MC-Unique: M8hUdgw9N_e9gs5xMqi0OA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E4FC9185A79C; Thu, 31 Mar 2022 15:48:35 +0000 (UTC) Received: from ceranb (unknown [10.40.192.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id 680862157F29; Thu, 31 Mar 2022 15:48:33 +0000 (UTC) Date: Thu, 31 Mar 2022 17:48:32 +0200 From: Ivan Vecera To: Maciej Fijalkowski Cc: netdev@vger.kernel.org, "moderated list:INTEL ETHERNET DRIVERS" , mschmidt@redhat.com, Brett Creeley , open list , poros@redhat.com, Jakub Kicinski , Paolo Abeni , "David S. Miller" Subject: Re: [Intel-wired-lan] [PATCH net] ice: Fix incorrect locking in ice_vc_process_vf_msg() Message-ID: <20220331174832.68e17c4a@ceranb> In-Reply-To: References: <20220331105005.2580771-1-ivecera@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, 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 On Thu, 31 Mar 2022 15:14:29 +0200 Maciej Fijalkowski wrote: > On Thu, Mar 31, 2022 at 12:50:04PM +0200, Ivan Vecera wrote: > > Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect > > because message sent from VF is ignored and never processed. > >=20 > > Use mutex_lock() instead to fix the issue. It is safe because this =20 >=20 > We need to know what is *the* issue in the first place. > Could you please provide more context what is being fixed to the readers > that don't have an access to bugzilla? >=20 > Specifically, what is the case that ignoring a particular message when > mutex is already held is a broken behavior? Reproducer: #!/bin/sh set -xe PF=3D"ens7f0" VF=3D"${PF}v0" echo 1 > /sys/class/net/${PF}/device/sriov_numvfs sleep 2 ip link set ${VF} up ip addr add 172.30.29.11/24 dev ${VF} while true; do # Set VF to be trusted ip link set ${PF} vf 0 trust on # Ping server again ping -c5 172.30.29.2 || { echo Ping failed ip link show dev ${VF} # <- No carrier here break } ip link set ${PF} vf 0 trust off sleep 1 done echo 0 > /sys/class/net/${PF}/device/sriov_numvfs [root@wsfd-advnetlab150 ~]# uname -r 5.17.0+ # Current net.git HEAD [root@wsfd-advnetlab150 ~]# ./repro_simple.sh=20 + PF=3Dens7f0 + VF=3Dens7f0v0 + echo 1 + sleep 2 + ip link set ens7f0v0 up + ip addr add 172.30.29.11/24 dev ens7f0v0 + true + ip link set ens7f0 vf 0 trust on + ping -c5 172.30.29.2 PING 172.30.29.2 (172.30.29.2) 56(84) bytes of data. 64 bytes from 172.30.29.2: icmp_seq=3D2 ttl=3D64 time=3D0.820 ms 64 bytes from 172.30.29.2: icmp_seq=3D3 ttl=3D64 time=3D0.142 ms 64 bytes from 172.30.29.2: icmp_seq=3D4 ttl=3D64 time=3D0.128 ms 64 bytes from 172.30.29.2: icmp_seq=3D5 ttl=3D64 time=3D0.129 ms --- 172.30.29.2 ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4110ms rtt min/avg/max/mdev =3D 0.128/0.304/0.820/0.298 ms + ip link set ens7f0 vf 0 trust off + sleep 1 + true + ip link set ens7f0 vf 0 trust on + ping -c5 172.30.29.2 PING 172.30.29.2 (172.30.29.2) 56(84) bytes of data. =46rom 172.30.29.11 icmp_seq=3D1 Destination Host Unreachable =46rom 172.30.29.11 icmp_seq=3D2 Destination Host Unreachable =46rom 172.30.29.11 icmp_seq=3D3 Destination Host Unreachable --- 172.30.29.2 ping statistics --- 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4125ms pipe 3 + echo Ping failed Ping failed + ip link show dev ens7f0v0 20: ens7f0v0: mtu 1500 qdisc mq state D= OWN mode DEFAULT group default qlen 1000 link/ether de:69:e3:a5:68:b6 brd ff:ff:ff:ff:ff:ff altname enp202s0f0v0 + break + echo 0 [root@wsfd-advnetlab150 ~]# dmesg | tail -8 [ 220.265891] iavf 0000:ca:01.0: Reset indication received from the PF [ 220.272250] iavf 0000:ca:01.0: Scheduling reset task [ 220.277217] iavf 0000:ca:01.0: Hardware reset detected [ 220.292854] ice 0000:ca:00.0: VF 0 is now trusted [ 220.295027] ice 0000:ca:00.0: VF 0 is being configured in another contex= t that will trigger a VFR, so there is no need to handle this message [ 234.445819] iavf 0000:ca:01.0: PF returned error -64 (IAVF_NOT_SUPPORTED= ) to our request 9 [ 234.466827] iavf 0000:ca:01.0: Failed to delete MAC filter, error IAVF_N= OT_SUPPORTED [ 234.474574] iavf 0000:ca:01.0: Remove device User set VF to be trusted so .ndo_set_vf_trust (ice_set_vf_trust) is called. Function ice_set_vf_trust() takes vf->cfg_lock and calls ice_vc_reset_vf() = that sends message to iavf that initiates reset task. During this reset task iav= f sends config messages to ice. These messages are handled in ice_service_task() co= ntext via ice_clean_adminq_subtask() -> __ice_clean_ctrlq() -> ice_vc_process_vf_= msg(). Function ice_vc_process_vf_msg() tries to take vf->cfg_lock but this can be= locked from ice_set_vf_trust() yet (as in sample above). The lock attempt failed s= o the function returns, message is not processed. Thanks, Ivan