From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA27D3112DA for ; Mon, 22 Jun 2026 15:30:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782142248; cv=none; b=IFBnqCXrk0IS+AnzOe7UgOim7PMnA6YbtPZIK2xYHxv5lymQOd8uFR04ok85/0UQqiwS1+ixOawH4DrCDRA94z1Zzd2MnbonmhDMpH7qkZFWP8+w8i/srMLSecOBjrTuyPz7R/6xLsMABH2zUrxoZywoMeH0nMl+OvZRfEFVX+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782142248; c=relaxed/simple; bh=KZReCBBbLPwYuR8X8Oxf6kb/nsr8OJG1g9lSh2phYz4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NbbpO6RBd1Bh92/LDGiuQHfo6CkOJEJLk/rjwiME4qUwcfKLYMZVMF08VJkAeQ8tCTw9wkU+1mcvMsLral9MxcgcDmm0QJTBKgVw+ZON5x2s2A7HgxFiHpHjnQvm5LA3Tjm/Ax6G92d31zLNZyFJNLsz0CeLXcn1j79TnpaYqj4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=jCQ2EFzm; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=H3iWbVwP; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="jCQ2EFzm"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="H3iWbVwP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782142245; 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=+BSJeeMyYcuKSEwdVpAPNISat771zywrHCdgKCUDl20=; b=jCQ2EFzmkTSxTxgVYo0ZCcM0whFhhSqve2wOU8S+Mw0wSFZGjOXGoBjU9MVRHg/LNdJ8BK PSHi87wDJODwZoFLEotCBik8SqZgHuLcKnHaKT+LGt0PSS5KZx6IrGn7t1urDNzIpMeGHY c/z2szlR2WCF+b+No73stpIvXS713Rg= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-319-CQjWm9ZDNyisBa-X8ZuERA-1; Mon, 22 Jun 2026 11:30:44 -0400 X-MC-Unique: CQjWm9ZDNyisBa-X8ZuERA-1 X-Mimecast-MFC-AGG-ID: CQjWm9ZDNyisBa-X8ZuERA_1782142242 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-46250b59ed5so3304063f8f.2 for ; Mon, 22 Jun 2026 08:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782142242; x=1782747042; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+BSJeeMyYcuKSEwdVpAPNISat771zywrHCdgKCUDl20=; b=H3iWbVwP8NhD6QKyalB3SqU0kqhzzOB5aD/M1xTdfCAOBJ/5yTSSVnNeLPDj31cU0Q /9JLbA5ByTQagNA9yst0dp4MqPWjJxaquNUPE6JfLt3+9grwS2LJ5JZ29duUgvMydmBM 332+hvSnn+jX1sd3p0tGdBsC+M2ND+/0k/wT4q7xnecLmEo25mLf29wkvVASAN4s1rOu ocRyy0KmJYJdj5HD6rxS2jpl9ij7MF85PGHGqKXP1Dx/T2zzKfPZ7fIxu+Oh2TTVrMJZ s7BM40SRnmi91J1LsPeVbIMrt1SmLiIN7myy+auoIayTC4mb+piW/Zva5IUgSaZZthPv Il4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782142242; x=1782747042; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+BSJeeMyYcuKSEwdVpAPNISat771zywrHCdgKCUDl20=; b=Y7A8/nhl5rV9MlbKyZ3gYAEG5lg77dw6+27WrZBHU37CWAiRxnAzH2KWgRNKCkOKI8 ms0/U8IBUAI+mBFceou/HgvTvRrs7DGnoZBMjUn7RBlnbaWuF0u+jXJjBMhPmAKmuu8I E7iA+Pvvi6CkSb4qDxjxMCAW60GUNSZqkE5smQK9+sNxmNEpMqwJ/oSDhv84hpZihKJY mgba4PWgf+m2FANtvqMA379WibeACZ3ju20iypSj6f11DyKLK+/Tksg/9zDWuZNjiXdC cYDNuElvkk6aOoZ1pIafGPMCjc/iNIwzeDwrDnydhV0UQEP72v/Edbi77M+Whn6gvcIp yVCw== X-Forwarded-Encrypted: i=1; AHgh+Rqdkk1evtDNmlVqrim95UHs+SMYOISLGRJfKPcM+/B7Y2sTPpk/9kqJZvWl3aZ/tzvWQv9kUGTORVB3kvg=@vger.kernel.org X-Gm-Message-State: AOJu0YwJAu4y6a4INawvtE1B5bXMwy+OY77epayEBC9vUxIDMHk1VhfM AL7RSInF1vdZhAD+MbEEz39q96zoTUa32H9bvjl07VvqHhV11pgHQHlRQ8qHqWx53Tw6I2UDUhe RGXo5YxPuuh28zYUctxTfmrLVlXrkNinNFFpBRXW0QAAZaBmlQEETTEce7wurZzGAEw== X-Gm-Gg: AfdE7cn8hz/Kk9xbYTxg5skxcDsTPeplLN6mbFFjIakSF6ch3JdNLoYHp+c3RYZQ4zg GQQPWEfRmvFdFHzTCUixOCBNc4YsPvePus3kTkK4v5Wqt1qE/T9l41w5YMHy+egyZtGGRqY94Lz u3kXCy+rz4GvqE8n8idW7uIdXQdR/ZmTCTrkrKa29C1YnxtVXthi+/lxKMRZmAtUf9+lTxQYq5g GIx21Z7MkUzYUbpcbEKzhUMDPFxBsBAnGmoOnmPwaeHl9aUymdrSTq4fnsH+ixsSMB34/KEirYg WODmBdBVZ1htzRi5Yn6TM9GpMpURSMXCCgNouyG6f+a68s3/DrbkxDYMUfjDag2eliWLZskSXj2 xzfWD9fab6A== X-Received: by 2002:a05:6000:4918:b0:469:763f:942d with SMTP id ffacd0b85a97d-469763f96e8mr5560523f8f.5.1782142241959; Mon, 22 Jun 2026 08:30:41 -0700 (PDT) X-Received: by 2002:a05:6000:4918:b0:469:763f:942d with SMTP id ffacd0b85a97d-469763f96e8mr5560420f8f.5.1782142241255; Mon, 22 Jun 2026 08:30:41 -0700 (PDT) Received: from [192.168.2.83] ([46.175.183.46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46666c57afasm27778756f8f.29.2026.06.22.08.30.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2026 08:30:40 -0700 (PDT) Message-ID: Date: Mon, 22 Jun 2026 17:30:37 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: clear the default forwarding VSI rule when releasing a VSI To: Marcin Szycik , netdev@vger.kernel.org Cc: Przemek Kitszel , Eric Dumazet , linux-kernel@vger.kernel.org, Andrew Lunn , Tony Nguyen , Michal Swiatkowski , Jacob Keller , Jakub Kicinski , Paolo Abeni , "David S. Miller" , intel-wired-lan@lists.osuosl.org References: <20260622081030.2312129-1-poros@redhat.com> <4dc1eb2d-e69f-4f13-ab08-ed0077305098@linux.intel.com> Content-Language: en-US From: Petr Oros In-Reply-To: <4dc1eb2d-e69f-4f13-ab08-ed0077305098@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/22/26 15:52, Marcin Szycik wrote: > > On 22/06/2026 10:10, Petr Oros wrote: >> When a VSI is configured as the switch's default forwarding VSI >> (ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in >> the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF >> free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release() >> -> ice_vsi_release()) does not disable promiscuous mode either, which >> only happens on VF reset in ice_vf_clear_all_promisc_modes(). >> >> A trusted VF that enters unicast promiscuous mode becomes the default >> forwarding VSI (this is the default mode, when the PF does not have VF >> true-promiscuous mode enabled). If the VFs are then destroyed without >> the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for >> the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the >> freed hw_vsi_id. If it is assigned a different VSI handle than the >> leaked rule holds, ice_set_dflt_vsi() does not recognize it as >> already-default, and ice_add_update_vsi_list() folds the dangling >> (freed) handle into a VSI list, which the firmware rejects. The VSI >> handle assigned on re-creation varies, so the failure is intermittent >> rather than every cycle. >> >> Reproduce by repeatedly running the cycle below on the two ports of the >> same card, where $VF0 and $VF1 are the netdevs of vf 15 once they >> appear. The VF must be brought up so iavf actually pushes the unicast >> promiscuous request, and the rule must settle before the VFs are torn >> down again: >> >> echo 16 > /sys/class/net/$PF0/device/sriov_numvfs >> echo 16 > /sys/class/net/$PF1/device/sriov_numvfs >> ip link set $PF0 vf 15 trust on >> ip link set $PF1 vf 15 trust on >> ip link set $VF0 up >> ip link set $VF1 up >> ip link set $VF0 promisc on >> ip link set $VF1 promisc on >> sleep 1 >> echo 0 > /sys/class/net/$PF0/device/sriov_numvfs >> echo 0 > /sys/class/net/$PF1/device/sriov_numvfs >> >> Within a few cycles the ice PF and iavf VF log: >> >> Failed to set VSI 25 as the default forwarding VSI, error -22 >> Turning on/off promiscuous mode for VF 63 failed, error: -22 >> PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14 >> >> This cleanup used to live in ice_vsi_release() but was dropped by the >> referenced refactor. Restore it. Clear the default forwarding VSI rule >> in ice_vsi_release() when this VSI owns it, which covers every teardown >> path. >> >> Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") >> Signed-off-by: Petr Oros >> --- >> drivers/net/ethernet/intel/ice/ice_lib.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c >> index 2717cc31bff8fe..408464434506ef 100644 >> --- a/drivers/net/ethernet/intel/ice/ice_lib.c >> +++ b/drivers/net/ethernet/intel/ice/ice_lib.c >> @@ -2872,6 +2872,9 @@ int ice_vsi_release(struct ice_vsi *vsi) >> return -ENODEV; >> pf = vsi->back; >> >> + if (ice_is_vsi_dflt_vsi(vsi)) >> + ice_clear_dflt_vsi(vsi); > In the referenced commit, the chunk of code that contained these missing 2 lines > was moved to ice_vsi_decfg(). It also sounds like a good place for them and will > be called from ice_vsi_release(). Are you sure we should place them directly in > ice_vsi_release() instead? No, ice_vsi_decfg() is not a good place for them because it is not release only. It also runs on the rebuild and reconfig paths (ice_vsi_rebuild(), ice_vf_reconfig_vsi(), the ice_vsi_cfg() error path), where the VSI is reconfigured in place and stays alive, so it can still be the default VSI afterwards. Before the refactor the release-path clear lived only in ice_vsi_release() and the old ice_vsi_rebuild() never cleared it. Putting it in ice_vsi_decfg() would also clear the default VSI whenever the default VSI itself is reset or reconfigured, which the original code never did. ice_vsi_release() keeps it to the case where the owning VSI is actually torn down, and the ice_is_vsi_dflt_vsi() guard makes it a no-op everywhere else. So I would prefer to keep it in ice_vsi_release(). Regards, Petr > Thanks, > Marcin > >> + >> if (test_bit(ICE_FLAG_RSS_ENA, pf->flags)) >> ice_rss_clean(vsi); >> >