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 53BC5393DDB for ; Fri, 6 Mar 2026 13:12:30 +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=1772802751; cv=none; b=bvkGreWZfOUDE5ZXOVi6N277G5Nxq2PybbJ91WUxFtsIzsi6lxtGY6BaUgPRCWKoM+0/JCm4DGISJF27QgNqCbDt5P0L/cRuPy7TY3Fr0CQlsSbfNBUJi1cBu0bJc1B7QvDoN/sFOYpR9YhI7ygD+EZpR60ifsEVOgCh5UlUsgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772802751; c=relaxed/simple; bh=bgR+u4X+EfGkHcGi9RUq+i16jPyWfF2EMadRRWpzyhs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=quDJ/wDkj//2+DQ4YbN9k0fls8m7nj4tXYZZRVhrkFCHHoB9Zmb/EnS6Z+DIt0lbDks76Zv65vH8p89nalC6lLV7GS4D/57NR/q9fiKIzqy7kK2BS1xAB33MlaOLg4Qbp931P7LYiQxYUxPk3UdF+h40EqbTvqIl/0eH3Tqkb1o= 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=h3uU89F5; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=GLkd5JUO; 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="h3uU89F5"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="GLkd5JUO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772802749; 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=dXD46sZBbQ0HinTPPSaWF5tUOxdfFWBYFR/OarMz7d8=; b=h3uU89F5ksDCmYbWBLGJX92iCHx5NAKKrcw2nespEzBrzXPuEspDm9W3v/5tF0gPjsVQPE w6M8QmhZMms09tPKoIYkj9TbbtRaukN/zCNQ7RVODsNiZ061kJsyWrCBGlOOIZgL13YTyY ic/ftitgBgK+mokfvnN9cMBIIQ6Aplw= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-673-PAue-NWrP8SIxWRUMCbViA-1; Fri, 06 Mar 2026 08:12:28 -0500 X-MC-Unique: PAue-NWrP8SIxWRUMCbViA-1 X-Mimecast-MFC-AGG-ID: PAue-NWrP8SIxWRUMCbViA_1772802747 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4837907ec88so101840285e9.0 for ; Fri, 06 Mar 2026 05:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772802745; x=1773407545; 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=dXD46sZBbQ0HinTPPSaWF5tUOxdfFWBYFR/OarMz7d8=; b=GLkd5JUOp/9phdeCGDgzoSGyNbRFm4Ux68IfMG2ECCCHM+iH9tOhP1s572YSTyVU9Z SkVXK+JKvpQ9kf4E2yv2CmJIC62TxAlAGlJZUrOBmT9q8uuA5R38/2P1mXua67jEyzdU fZJYQtO9G3PjUzcyWReFDZES4lRuDgWBopf+UJ0iHpITuZMvGZ4MYCCRijZf/tq1Pzad W1RMApIiXKGtLaRhQIjMKIFxL6TUTCHIwU7gfC/7bZ6C1UV7Y3Q6i8ArcQSLcaQcdsqY 6JVGQQNZVmWTok7gJW5KZJicsf6h91+M2Hzq3P3GGXCN1JnjVZVcDHRWyPb5n3R3/VUL ghyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772802745; x=1773407545; 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=dXD46sZBbQ0HinTPPSaWF5tUOxdfFWBYFR/OarMz7d8=; b=YJ4c6bvMww6kBUAfrxpsmZOfb+MmnxqnEiG2X5V5ZR3fU29Jo1RfLuOGDlNAz8FhK5 iZRzobCxfBVddQam0YAjikCUwzWTqgYOZagBtCbY20EZhIna4+gK7VN9hPV8AnuT62FC pLEH9jCSWPmctQkCslr3GOhGdjhIfamxq+u4daZLKP7ZFIBr/3GU43gZymFluFTI85W6 6uFDpNTud6OuKAP0YJTHkoduIK2Ll6dfkAngXmVrRJfSe/Hjd9Iy94pc2iCs+ySmSd+R eRlCqoBFNyAkrx4Jjxr3zV4QsReHoYx7tUJ3eR+smOm8ARFR33gFlcXpNSUfT/31cE2I 63Mw== X-Forwarded-Encrypted: i=1; AJvYcCW1oGdA2P48ELRlTSRae/E2d6miefZpiWKDg3IHyMH94fpY+FV8hmkvDyVmYIhkHGiGD4H5wDF+gbAu0iE=@vger.kernel.org X-Gm-Message-State: AOJu0YzFtZe0Hpi5iv28Zv7BhXvghl993hIR/FsggLiWugLGvgZNjjSL zIsW62IxZUtG6ASUlAzAIIyWXDOWvNWuF4GRHBvRNS3bb4wWQCPAfzyPoA6ZRYsDL8N2Yh+AaDT hb2TW1c5uRcKpHG8OAupuUZSTSBShKjYzq0ZulOXbXWzRQp0MARjAQ38dP537slaKW9HA7gm2qU xh X-Gm-Gg: ATEYQzzv1RoMT1s44sOj+gw5zooXLTW8obfjeySogTSLiUwQluxcXo+YmCj9Ym/wpHx s5ddFh/6FrPa4goPzMQ+4YOz/GP5SfmgBgybeMuwOBmhjSjLfif6f3Cd4xBQzTteTt1O85aYuvp 63cWUAV2gNXd5kzz0AYITMefDOJBwvQDVScbFlo72szr40ZLorcBzOzp5+nMfwpFQS4vNm9vMGe sRdvhB2umzrrQyFo6mSenNLXZLePfcgsIC5+2vVU3UHpBSBPALnQUoHQLk8lvA2akdt4SGbqAfa V6LZOO+k9CSjezgLAUa/40dzxife0B+iCPpZio+zvWF7Xq7zVq2HFl7mrTqB2fRqiSRlMcFwGzw 8wbVvwOAwX2WLle1ii8NN X-Received: by 2002:a05:600c:c4a5:b0:477:63b5:7148 with SMTP id 5b1f17b1804b1-485269199a2mr31101365e9.6.1772802744871; Fri, 06 Mar 2026 05:12:24 -0800 (PST) X-Received: by 2002:a05:600c:c4a5:b0:477:63b5:7148 with SMTP id 5b1f17b1804b1-485269199a2mr31100855e9.6.1772802744373; Fri, 06 Mar 2026 05:12:24 -0800 (PST) Received: from [192.168.2.83] ([46.175.183.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851fae00absm110527045e9.4.2026.03.06.05.12.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Mar 2026 05:12:23 -0800 (PST) Message-ID: <76331edf-2963-4527-9f01-80fed3f6d49b@redhat.com> Date: Fri, 6 Mar 2026 14:12:22 +0100 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: [PATCH RFC iwl-next 0/4] iavf: fix VLAN filter state machine races To: netdev@vger.kernel.org Cc: jacob.e.keller@intel.com, Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org References: <20260302114025.1017985-1-poros@redhat.com> Content-Language: en-US From: Petr Oros In-Reply-To: <20260302114025.1017985-1-poros@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I leveraged Claude Opus 4.6 to develop a stress-test suite with a primary 'break-it' objective targeting VF stability. The suite focuses on aggressive edge cases, specifically cyclic VF migration between network namespaces while VLAN filtering is active a sequence known to trigger state machine regressions. The following output demonstrates the failure state on an unpatched iavf driver (prior to the 'fix VLAN filter state machine races' patch): echo 8 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs # ./tools/testing/selftests/drivers/net/iavf_vlan_state.sh ================================================   iavf VLAN state machine test suite ================================================   VF1:  enp65s0f0v0 (0000:41:01.0) -> iavf-t1-6502   VF2:  enp65s0f0v1 (0000:41:01.1) -> iavf-t2-6502   PF:   enp65s0f0np0 (0000:41:00.0)   MAX:  8 user VLANs per VF ================================================   PASS  state: basic add/remove RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  state: 8 VLANs add/remove  (only 7 created)   PASS  state: VLAN persists across down/up   PASS  state: 5 VLANs persist across down/up   PASS  state: rapid add/del same VLAN x100   PASS  state: add during remove (REMOVING race) RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   PASS  state: bulk 8 add then remove   PASS  state: 20x rapid down/up with VLAN   PASS  state: add VLAN while down   PASS  state: remove VLAN while down   PASS  state: down -> remove -> up   PASS  state: add VLANs while down, verify all after up   PASS  state: double add same VLAN (idempotent)   PASS  state: double remove same VLAN   PASS  state: interleaved add/remove different VIDs   PASS  state: remove+re-add loop x50 RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  state: stress 8 VLANs (fill to max)  (expected 8, got 7)   PASS  state: VLAN VID 1 (common edge case)   PASS  state: VLAN VID 4094 (max)   PASS  state: concurrent VLAN adds (4 parallel)   PASS  state: concurrent VLAN deletes (4 parallel)   PASS  state: add/del storm (200 ops, 5 VIDs) RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  state: over-limit VLAN rejected, existing survive  (fill: expected 8, got 7)   PASS  reset: VLANs recover after VF PCI FLR   PASS  reset: 5 VLANs recover after VF PCI FLR   PASS  reset: rapid VF resets x5 with VLANs   PASS  reset: VLANs survive PF link flap   PASS  reset: 5 VLANs survive PF link flap   PASS  reset: VLANs survive 3x PF link flap   PASS  reset: VLANs survive PF PCI FLR RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  reset: all 8 VLANs recover after VF FLR  (VLAN 107 gone) RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  reset: all 8 VLANs survive PF link flap  (VLAN 107 gone) RTNETLINK answers: Input/output error Cannot find device "enp65s0f0v0.107" Cannot find device "enp65s0f0v0.107"   FAIL  reset: all 8 VLANs survive PF PCI FLR  (VLAN 107 gone)   PASS  reset: FLR during VLAN add/del (race)   PASS  reset: VF driver unbind/bind cycle   PASS  ping: basic VLAN traffic   PASS  ping: 5 VLANs simultaneously   PASS  ping: survives VF down/up   PASS  ping: survives 10x rapid VF flap   PASS  ping: survives VF PCI FLR   PASS  ping: survives PF link flap   PASS  ping: survives PF PCI FLR   PASS  ping: stable while adding/removing other VLANs   PASS  ping: all 3 VLANs work after down/up   PASS  ping: parallel VLAN churn from both VFs   PASS  ping: VLANs work after rapid add/del churn   PASS  ping: VLANs survive repeated NS move cycle   PASS  ping: all VLANs survive PF link flap   PASS  ping: VLAN isolation (no cross-VLAN leakage)   PASS  ping: traffic works with spoofchk enabled   PASS  ping: port VLAN (PF-assigned pvid)   PASS  dmesg: no call traces / BUGs / stalls ================================================   PASS 46  |  FAIL 6  |  SKIP 0  |  TOTAL 52 ================================================   RESULT: FAIL  -- check dmesg The underlying failures stem from a breakdown in state synchronization between the VF and the PF. This desynchronization prevents the driver from maintaining a consistent hardware state during rapid configuration cycles, leading to the observed issues. ................... Patched kernel: # echo 8 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs # ./tools/testing/selftests/drivers/net/iavf_vlan_state.sh ================================================   iavf VLAN state machine test suite ================================================   VF1:  enp65s0f0v0 (0000:41:01.0) -> iavf-t1-6573   VF2:  enp65s0f0v1 (0000:41:01.1) -> iavf-t2-6573   PF:   enp65s0f0np0 (0000:41:00.0)   MAX:  8 user VLANs per VF ================================================   PASS  state: basic add/remove   PASS  state: 8 VLANs add/remove   PASS  state: VLAN persists across down/up   PASS  state: 5 VLANs persist across down/up   PASS  state: rapid add/del same VLAN x100   PASS  state: add during remove (REMOVING race)   PASS  state: bulk 8 add then remove   PASS  state: 20x rapid down/up with VLAN   PASS  state: add VLAN while down   PASS  state: remove VLAN while down   PASS  state: down -> remove -> up   PASS  state: add VLANs while down, verify all after up   PASS  state: double add same VLAN (idempotent)   PASS  state: double remove same VLAN   PASS  state: interleaved add/remove different VIDs   PASS  state: remove+re-add loop x50   PASS  state: stress 8 VLANs (fill to max)   PASS  state: VLAN VID 1 (common edge case)   PASS  state: VLAN VID 4094 (max)   PASS  state: concurrent VLAN adds (4 parallel)   PASS  state: concurrent VLAN deletes (4 parallel)   PASS  state: add/del storm (200 ops, 5 VIDs)   PASS  state: over-limit VLAN rejected, existing survive   PASS  reset: VLANs recover after VF PCI FLR   PASS  reset: 5 VLANs recover after VF PCI FLR   PASS  reset: rapid VF resets x5 with VLANs   PASS  reset: VLANs survive PF link flap   PASS  reset: 5 VLANs survive PF link flap   PASS  reset: VLANs survive 3x PF link flap   PASS  reset: VLANs survive PF PCI FLR   PASS  reset: all 8 VLANs recover after VF FLR   PASS  reset: all 8 VLANs survive PF link flap   PASS  reset: all 8 VLANs survive PF PCI FLR   PASS  reset: FLR during VLAN add/del (race)   PASS  reset: VF driver unbind/bind cycle   PASS  ping: basic VLAN traffic   PASS  ping: 5 VLANs simultaneously   PASS  ping: survives VF down/up   PASS  ping: survives 10x rapid VF flap   PASS  ping: survives VF PCI FLR   PASS  ping: survives PF link flap   PASS  ping: survives PF PCI FLR   PASS  ping: stable while adding/removing other VLANs   PASS  ping: all 3 VLANs work after down/up   PASS  ping: parallel VLAN churn from both VFs   PASS  ping: VLANs work after rapid add/del churn   PASS  ping: VLANs survive repeated NS move cycle   PASS  ping: all VLANs survive PF link flap   PASS  ping: VLAN isolation (no cross-VLAN leakage)   PASS  ping: traffic works with spoofchk enabled   PASS  ping: port VLAN (PF-assigned pvid)   PASS  dmesg: no call traces / BUGs / stalls ================================================   PASS 52  |  FAIL 0  |  SKIP 0  |  TOTAL 52 ================================================   RESULT: OK Additionally, interface up/down performance with active VLAN filtering is significantly improved. The previous bottleneck—a synchronous VLAN filtering cycle (VF -> PF -> HW -> PF -> VF) utilizing AdminQ for per-VLAN updates introduced substantial latency. Test suite: https://github.com/torvalds/linux/commit/5c60850c33da80a1c2497fb6bc31f956316197a9 Regards, Petr