AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The changes only affect the fbnic driver (drivers/net/ethernet/meta/fbnic/), which is for Meta's proprietary PCIe NIC hardware. This hardware is not emulated in standard QEMU or GCE virtualized environments, making the modified code structurally unreachable for fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 1d66f6701bf5a327b37af0130b0330bd0af53298\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Nov 7 10:40:17 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h\nindex cbb25d11638c09..c371ac9f78c182 100644\n--- a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h\n+++ b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h\n@@ -441,6 +441,7 @@ enum {\n #define FBNIC_TMI_SOP_PROT_CTRL\t\t0x04400\t\t/* 0x11000 */\n #define FBNIC_TMI_DROP_CTRL\t\t0x04401\t\t/* 0x11004 */\n #define FBNIC_TMI_DROP_CTRL_EN\t\t\tCSR_BIT(0)\n+#define FBNIC_TMI_DROP_CTRL_CMPL_DIS\t\tCSR_BIT(1)\n #define FBNIC_TMI_DROP_PKTS\t\t0x04402\t\t/* 0x11008 */\n #define FBNIC_TMI_DROP_BYTE_L\t\t0x04403\t\t/* 0x1100c */\n #define FBNIC_TMI_ILLEGAL_PTP_REQS\t0x04409\t\t/* 0x11024 */\n@@ -955,6 +956,10 @@ enum {\n \n /* PUL User Registers */\n #define FBNIC_CSR_START_PUL_USER\t0x31000\t/* CSR section delimiter */\n+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS \\\n+\t\t\t\t\t0x31030\t\t/* 0xc40c0 */\n+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS_AW_FLUSH_DONE\tCSR_BIT(7)\n+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS_AR_FLUSH_DONE\tCSR_BIT(8)\n #define FBNIC_PUL_OB_TLP_HDR_AW_CFG\t0x3103d\t\t/* 0xc40f4 */\n #define FBNIC_PUL_OB_TLP_HDR_AW_CFG_FLUSH_MODE\tCSR_BIT(20)\n #define FBNIC_PUL_OB_TLP_HDR_AW_CFG_FLUSH\tCSR_BIT(19)\ndiff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c\nindex 49b8813a356438..e00d626f643847 100644\n--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c\n+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c\n@@ -7,6 +7,7 @@\n #include \u003clinux/dev_printk.h\u003e\n #include \u003clinux/dma-mapping.h\u003e\n #include \u003clinux/gfp.h\u003e\n+#include \u003clinux/iopoll.h\u003e\n #include \u003clinux/types.h\u003e\n \n #include \"fbnic.h\"\n@@ -176,10 +177,25 @@ static void fbnic_mbx_unmap_and_free_msg(struct fbnic_dev *fbd, int mbx_idx,\n \n static void fbnic_mbx_clean_desc_ring(struct fbnic_dev *fbd, int mbx_idx)\n {\n+\tu32 flush_done, val;\n \tint i;\n \n \tfbnic_mbx_reset_desc_ring(fbd, mbx_idx);\n \n+\t/* Arming the flush only starts it. Wait for the outbound path to\n+\t * retire the requests it still holds before the buffers they may\n+\t * target are unmapped and freed. A lost link reads back as all ones,\n+\t * which ends the poll on the first pass.\n+\t */\n+\tflush_done = mbx_idx == FBNIC_IPC_MBX_RX_IDX ?\n+\t\t     FBNIC_PUL_USER_IP_LINK_RST_STATUS_AW_FLUSH_DONE :\n+\t\t     FBNIC_PUL_USER_IP_LINK_RST_STATUS_AR_FLUSH_DONE;\n+\tif (read_poll_timeout_atomic(fbnic_rd32, val, val \u0026 flush_done, 2,\n+\t\t\t\t     1000, false, fbd,\n+\t\t\t\t     FBNIC_PUL_USER_IP_LINK_RST_STATUS))\n+\t\tdev_warn(fbd-\u003edev, \"Outbound flush did not complete: %08x\\n\",\n+\t\t\t val);\n+\n \tfor (i = FBNIC_IPC_MBX_DESC_LEN; i--;)\n \t\tfbnic_mbx_unmap_and_free_msg(fbd, mbx_idx, i);\n }\ndiff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c\nindex 8a6703afca3848..52244219d16687 100644\n--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c\n+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c\n@@ -86,11 +86,11 @@ static int fbnic_stop(struct net_device *netdev)\n {\n \tstruct fbnic_net *fbn = netdev_priv(netdev);\n \n+\tfbnic_down(fbn);\n+\n \tfbnic_mac_free_irq(fbn-\u003efbd);\n \tphylink_suspend(fbn-\u003ephylink, fbnic_bmc_present(fbn-\u003efbd));\n \n-\tfbnic_down(fbn);\n-\n \tfbnic_time_stop(fbn);\n \tfbnic_fw_xmit_ownership_msg(fbn-\u003efbd, false);\n \ndiff --git a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c\nindex ad234bb0f75d02..09ae797b1f0dc6 100644\n--- a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c\n+++ b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c\n@@ -181,10 +181,15 @@ static int fbnic_fw_config_after_crash(struct fbnic_dev *fbd)\n \t\treturn -1;\n \t}\n \n+\t/* The rx mode work rewrites the same shadow under the instance lock\n+\t * alone, and this runs from the service task under RTNL only.\n+\t */\n+\tnetdev_lock(fbd-\u003enetdev);\n \tfbnic_rpc_reset_valid_entries(fbd);\n \tnetif_addr_lock_bh(fbd-\u003enetdev);\n \t__fbnic_set_rx_mode(fbd, \u0026fbd-\u003enetdev-\u003euc, \u0026fbd-\u003enetdev-\u003emc);\n \tnetif_addr_unlock_bh(fbd-\u003enetdev);\n+\tnetdev_unlock(fbd-\u003enetdev);\n \n \treturn 0;\n }\n@@ -229,18 +234,25 @@ static void fbnic_service_task(struct work_struct *work)\n \n \tfbnic_fw_check_heartbeat(fbd);\n \n-\tfbnic_health_check(fbd);\n-\n-\tfbnic_bmc_rpc_check(fbd);\n-\n \tif (netif_carrier_ok(fbd-\u003enetdev)) {\n \t\tnetdev_lock(fbd-\u003enetdev);\n \t\tfbnic_napi_depletion_check(fbd-\u003enetdev);\n \t\tnetdev_unlock(fbd-\u003enetdev);\n \t}\n \n-\tif (netif_running(netdev))\n+\t/* fbnic_service_task_stop() does not wait for a pass that is already\n+\t * blocked on RTNL, so one can run after ndo_stop. Leave host state\n+\t * alone in that case, and do not re-arm; __fbnic_open() reclaims and\n+\t * rebuilds it. The PM path calls ndo_stop with the device detached but\n+\t * still running; fbnic_up() starts the task again on resume.\n+\t */\n+\tif (netif_running(netdev) \u0026\u0026 netif_device_present(netdev)) {\n+\t\tfbnic_health_check(fbd);\n+\n+\t\tfbnic_bmc_rpc_check(fbd);\n+\n \t\tschedule_delayed_work(\u0026fbd-\u003eservice_task, HZ);\n+\t}\n \n \trtnl_unlock();\n }\n@@ -453,6 +465,12 @@ static int fbnic_pm_suspend(struct device *dev)\n \tnetdev_unlock(netdev);\n \trtnl_unlock();\n \n+\t/* ndo_stop could not wait for a pass already blocked on RTNL. That\n+\t * pass no longer re-arms, but wait for it to finish before the\n+\t * mailbox, IRQs and MMIO go away.\n+\t */\n+\tcancel_delayed_work_sync(\u0026fbd-\u003eservice_task);\n+\n null_uc_addr:\n \tfbnic_fw_log_disable(fbd);\n \n@@ -553,19 +571,26 @@ static void __fbnic_pm_attach(struct device *dev)\n \tstruct net_device *netdev = fbd-\u003enetdev;\n \tstruct fbnic_net *fbn;\n \n-\trtnl_lock();\n-\tfbnic_reset_hw_stats(fbd);\n-\trtnl_unlock();\n-\n \tif (fbnic_init_failure(fbd))\n \t\treturn;\n \n \tfbn = netdev_priv(netdev);\n \n+\t/* Hold RTNL until the device is attached, so the service task pass\n+\t * fbnic_up() schedules cannot run until it will see it present.\n+\t */\n+\trtnl_lock();\n+\tnetdev_lock(netdev);\n+\n+\tfbnic_reset_hw_stats(fbd);\n+\n \tif (netif_running(netdev))\n \t\tfbnic_up(fbn);\n \n \tnetif_device_attach(netdev);\n+\n+\tnetdev_unlock(netdev);\n+\trtnl_unlock();\n }\n \n static int __maybe_unused fbnic_pm_resume(struct device *dev)\ndiff --git a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c\nindex 0bcee152d47c39..07d4b2e923627b 100644\n--- a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c\n+++ b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c\n@@ -2349,15 +2349,19 @@ void fbnic_disable(struct fbnic_net *fbn)\n \n static void fbnic_tx_flush(struct fbnic_dev *fbd)\n {\n+\tu32 drop_ctrl = FBNIC_TMI_DROP_CTRL_EN | FBNIC_TMI_DROP_CTRL_CMPL_DIS;\n+\n \tnetdev_warn(fbd-\u003enetdev, \"triggering Tx flush\\n\");\n \n-\tfbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, FBNIC_TMI_DROP_CTRL_EN,\n-\t\t    FBNIC_TMI_DROP_CTRL_EN);\n+\t/* Drop packets and retire their PTP completions */\n+\tfbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, drop_ctrl, drop_ctrl);\n }\n \n static void fbnic_tx_flush_off(struct fbnic_dev *fbd)\n {\n-\tfbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, FBNIC_TMI_DROP_CTRL_EN, 0);\n+\tu32 drop_ctrl = FBNIC_TMI_DROP_CTRL_EN | FBNIC_TMI_DROP_CTRL_CMPL_DIS;\n+\n+\tfbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, drop_ctrl, 0);\n }\n \n struct fbnic_idle_regs {\n"
}

core

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The changes only affect the fbnic driver (drivers/net/ethernet/meta/fbnic/), which is for Meta's proprietary PCIe NIC hardware. This hardware is not emulated in standard QEMU or GCE virtualized environments, making the modified code structurally unreachable for fuzzing.",
  "WorthFuzzing": false
}

You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.

================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.

- REACHABILITY IS THE PRIMARY GATE:
  Fuzzing can only discover bugs in code that can actually execute in standard virtualized
  environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
  If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
  regardless of whether it adds assertions or complex logic.

- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
  Patch authors routinely label changes as "cleanups", "refactorings", or state
  "No functional change intended". Do NOT take these claims at face value.
  Code refactorings that rearrange logic, introduce helper functions, or alter state management
  in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
  If reachable executable code is modified or refactored, it MUST be fuzzed.

- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
  When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
  BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
  Even if the author believes the invariant always holds, fuzzing is essential to verify whether
  an unusual sequence of operations can violate it.

================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:

- Non-kernel and non-executable changes:
  * Modifications to Documentation/, comments, or spelling fixes.
  * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
    that do not affect the compiled kernel image (vmlinux) or kernel modules.
  * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
    that do not alter control flow or data structures.
  * Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
  * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
    ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
  * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
    physical PCI hot-unplug or manual sysfs driver unbinding.
  * Code paths exclusive to architectures other than the target architecture.

================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
  * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
    BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
  * Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
  * Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
  * Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).

================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:

- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
  Do NOT list generic, ubiquitous functions called by almost every program in the corpus
  (including, but not limited to: general memory allocators and deallocators, page fault
  and trap handlers, or core synchronization primitives; this is not an exhaustive list).
  Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
  which severely dilutes fuzzing effort away from the actual changes.

- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
  List functions that specifically implement the logic being added or altered, or direct API entrypoints
  for the subsystem feature under review.

- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
  Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
  distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
  If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
  functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).

================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 1d66f6701bf5a327b37af0130b0330bd0af53298
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Nov 7 10:40:17 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
index cbb25d11638c09..c371ac9f78c182 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
@@ -441,6 +441,7 @@ enum {
 #define FBNIC_TMI_SOP_PROT_CTRL		0x04400		/* 0x11000 */
 #define FBNIC_TMI_DROP_CTRL		0x04401		/* 0x11004 */
 #define FBNIC_TMI_DROP_CTRL_EN			CSR_BIT(0)
+#define FBNIC_TMI_DROP_CTRL_CMPL_DIS		CSR_BIT(1)
 #define FBNIC_TMI_DROP_PKTS		0x04402		/* 0x11008 */
 #define FBNIC_TMI_DROP_BYTE_L		0x04403		/* 0x1100c */
 #define FBNIC_TMI_ILLEGAL_PTP_REQS	0x04409		/* 0x11024 */
@@ -955,6 +956,10 @@ enum {
 
 /* PUL User Registers */
 #define FBNIC_CSR_START_PUL_USER	0x31000	/* CSR section delimiter */
+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS \
+					0x31030		/* 0xc40c0 */
+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS_AW_FLUSH_DONE	CSR_BIT(7)
+#define FBNIC_PUL_USER_IP_LINK_RST_STATUS_AR_FLUSH_DONE	CSR_BIT(8)
 #define FBNIC_PUL_OB_TLP_HDR_AW_CFG	0x3103d		/* 0xc40f4 */
 #define FBNIC_PUL_OB_TLP_HDR_AW_CFG_FLUSH_MODE	CSR_BIT(20)
 #define FBNIC_PUL_OB_TLP_HDR_AW_CFG_FLUSH	CSR_BIT(19)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
index 49b8813a356438..e00d626f643847 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
@@ -7,6 +7,7 @@
 #include <linux/dev_printk.h>
 #include <linux/dma-mapping.h>
 #include <linux/gfp.h>
+#include <linux/iopoll.h>
 #include <linux/types.h>
 
 #include "fbnic.h"
@@ -176,10 +177,25 @@ static void fbnic_mbx_unmap_and_free_msg(struct fbnic_dev *fbd, int mbx_idx,
 
 static void fbnic_mbx_clean_desc_ring(struct fbnic_dev *fbd, int mbx_idx)
 {
+	u32 flush_done, val;
 	int i;
 
 	fbnic_mbx_reset_desc_ring(fbd, mbx_idx);
 
+	/* Arming the flush only starts it. Wait for the outbound path to
+	 * retire the requests it still holds before the buffers they may
+	 * target are unmapped and freed. A lost link reads back as all ones,
+	 * which ends the poll on the first pass.
+	 */
+	flush_done = mbx_idx == FBNIC_IPC_MBX_RX_IDX ?
+		     FBNIC_PUL_USER_IP_LINK_RST_STATUS_AW_FLUSH_DONE :
+		     FBNIC_PUL_USER_IP_LINK_RST_STATUS_AR_FLUSH_DONE;
+	if (read_poll_timeout_atomic(fbnic_rd32, val, val & flush_done, 2,
+				     1000, false, fbd,
+				     FBNIC_PUL_USER_IP_LINK_RST_STATUS))
+		dev_warn(fbd->dev, "Outbound flush did not complete: %08x\n",
+			 val);
+
 	for (i = FBNIC_IPC_MBX_DESC_LEN; i--;)
 		fbnic_mbx_unmap_and_free_msg(fbd, mbx_idx, i);
 }
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
index 8a6703afca3848..52244219d16687 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
@@ -86,11 +86,11 @@ static int fbnic_stop(struct net_device *netdev)
 {
 	struct fbnic_net *fbn = netdev_priv(netdev);
 
+	fbnic_down(fbn);
+
 	fbnic_mac_free_irq(fbn->fbd);
 	phylink_suspend(fbn->phylink, fbnic_bmc_present(fbn->fbd));
 
-	fbnic_down(fbn);
-
 	fbnic_time_stop(fbn);
 	fbnic_fw_xmit_ownership_msg(fbn->fbd, false);
 
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
index ad234bb0f75d02..09ae797b1f0dc6 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
@@ -181,10 +181,15 @@ static int fbnic_fw_config_after_crash(struct fbnic_dev *fbd)
 		return -1;
 	}
 
+	/* The rx mode work rewrites the same shadow under the instance lock
+	 * alone, and this runs from the service task under RTNL only.
+	 */
+	netdev_lock(fbd->netdev);
 	fbnic_rpc_reset_valid_entries(fbd);
 	netif_addr_lock_bh(fbd->netdev);
 	__fbnic_set_rx_mode(fbd, &fbd->netdev->uc, &fbd->netdev->mc);
 	netif_addr_unlock_bh(fbd->netdev);
+	netdev_unlock(fbd->netdev);
 
 	return 0;
 }
@@ -229,18 +234,25 @@ static void fbnic_service_task(struct work_struct *work)
 
 	fbnic_fw_check_heartbeat(fbd);
 
-	fbnic_health_check(fbd);
-
-	fbnic_bmc_rpc_check(fbd);
-
 	if (netif_carrier_ok(fbd->netdev)) {
 		netdev_lock(fbd->netdev);
 		fbnic_napi_depletion_check(fbd->netdev);
 		netdev_unlock(fbd->netdev);
 	}
 
-	if (netif_running(netdev))
+	/* fbnic_service_task_stop() does not wait for a pass that is already
+	 * blocked on RTNL, so one can run after ndo_stop. Leave host state
+	 * alone in that case, and do not re-arm; __fbnic_open() reclaims and
+	 * rebuilds it. The PM path calls ndo_stop with the device detached but
+	 * still running; fbnic_up() starts the task again on resume.
+	 */
+	if (netif_running(netdev) && netif_device_present(netdev)) {
+		fbnic_health_check(fbd);
+
+		fbnic_bmc_rpc_check(fbd);
+
 		schedule_delayed_work(&fbd->service_task, HZ);
+	}
 
 	rtnl_unlock();
 }
@@ -453,6 +465,12 @@ static int fbnic_pm_suspend(struct device *dev)
 	netdev_unlock(netdev);
 	rtnl_unlock();
 
+	/* ndo_stop could not wait for a pass already blocked on RTNL. That
+	 * pass no longer re-arms, but wait for it to finish before the
+	 * mailbox, IRQs and MMIO go away.
+	 */
+	cancel_delayed_work_sync(&fbd->service_task);
+
 null_uc_addr:
 	fbnic_fw_log_disable(fbd);
 
@@ -553,19 +571,26 @@ static void __fbnic_pm_attach(struct device *dev)
 	struct net_device *netdev = fbd->netdev;
 	struct fbnic_net *fbn;
 
-	rtnl_lock();
-	fbnic_reset_hw_stats(fbd);
-	rtnl_unlock();
-
 	if (fbnic_init_failure(fbd))
 		return;
 
 	fbn = netdev_priv(netdev);
 
+	/* Hold RTNL until the device is attached, so the service task pass
+	 * fbnic_up() schedules cannot run until it will see it present.
+	 */
+	rtnl_lock();
+	netdev_lock(netdev);
+
+	fbnic_reset_hw_stats(fbd);
+
 	if (netif_running(netdev))
 		fbnic_up(fbn);
 
 	netif_device_attach(netdev);
+
+	netdev_unlock(netdev);
+	rtnl_unlock();
 }
 
 static int __maybe_unused fbnic_pm_resume(struct device *dev)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
index 0bcee152d47c39..07d4b2e923627b 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
@@ -2349,15 +2349,19 @@ void fbnic_disable(struct fbnic_net *fbn)
 
 static void fbnic_tx_flush(struct fbnic_dev *fbd)
 {
+	u32 drop_ctrl = FBNIC_TMI_DROP_CTRL_EN | FBNIC_TMI_DROP_CTRL_CMPL_DIS;
+
 	netdev_warn(fbd->netdev, "triggering Tx flush\n");
 
-	fbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, FBNIC_TMI_DROP_CTRL_EN,
-		    FBNIC_TMI_DROP_CTRL_EN);
+	/* Drop packets and retire their PTP completions */
+	fbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, drop_ctrl, drop_ctrl);
 }
 
 static void fbnic_tx_flush_off(struct fbnic_dev *fbd)
 {
-	fbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, FBNIC_TMI_DROP_CTRL_EN, 0);
+	u32 drop_ctrl = FBNIC_TMI_DROP_CTRL_EN | FBNIC_TMI_DROP_CTRL_CMPL_DIS;
+
+	fbnic_rmw32(fbd, FBNIC_TMI_DROP_CTRL, drop_ctrl, 0);
 }
 
 struct fbnic_idle_regs {

gemini-3.8-flash

null

null

							input: 6041
							output: 34
							thoughts: 191
						

**Analyzing this Patch for the Meta fbnic Driver**

Okay, let's dive into this. The first thing I always do is look at the affected files. We have changes touching `drivers/net/ethernet/meta/fbnic/fbnic_csr.h`, `fbnic_fw.c`, `fbnic_netdev.c`, `fbnic_pci.c`, and `fbnic_txrx.c`. Those file paths immediately tell me we're dealing with the Meta fbnic driver, which I recognize as a network interface driver under the `drivers/net/ethernet/meta` directory. Now, I need to confirm my initial assumption that this driver is for physical hardware, specifically Meta's custom ASIC or NIC. The directory structure certainly suggests that it is, but I always want to be precise, so I'll check the Kconfig file within that directory to confirm what hardware the driver supports.

{
  "Expression": "config FBNIC",
  "PathPrefixes": [
    "drivers/net/ethernet/meta/"
  ]
}

{
  "Output": "drivers/net/ethernet/meta/Kconfig=18=if NET_VENDOR_META\ndrivers/net/ethernet/meta/Kconfig-19-\ndrivers/net/ethernet/meta/Kconfig:20:config FBNIC\ndrivers/net/ethernet/meta/Kconfig-21-\ttristate \"Meta Platforms Host Network Interface\"\n"
}

gemini-3.8-flash

null

null

							input: 6560
							output: 37
							thoughts: 17
						

Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person:

**Diving into `drivers/net/ethernet/meta/Kconfig`**

Alright, let's get down to brass tacks. I need to take a look at the `drivers/net/ethernet/meta/Kconfig` file. I'm expecting this to be the central configuration file for a *meta* driver, which suggests it likely handles the overarching options and dependencies related to a family or architecture of Ethernet drivers. My initial hunch is that it won't contain the nitty-gritty details of individual PHY or MAC registers, but rather the high-level framework: the `CONFIG_` symbols that enable or disable a particular Ethernet family, maybe define common features like VLAN support, or manage dependencies on underlying hardware abstraction layers (HALs).

I'll be looking for the typical Kconfig constructs: `config` blocks defining configuration options, `menuconfig` blocks to group related options logically, `depends on` statements to understand conditional dependencies on hardware or other software components, and `select` statements that automatically enable dependent options. I'll also be scanning for `default` values that help set reasonable defaults.

My first questions will be:

*   What are the top-level configuration symbols? Are they very broad or focused?
*   What does the dependency structure look like? What other modules or drivers does this meta-driver rely upon?
*   How are different Ethernet controllers or device families distinguished? Are there separate configuration sections for each, or is it done more abstractly?
*   Are there any interesting defaults or 'tricks' in the configuration that I should be aware of?

Essentially, I'm trying to quickly establish the *scope* and *structure* of this Ethernet meta-driver configuration and how it interacts with the rest of the network stack. I'm looking for clues about how to extend or customize it and the design principles at play.

{
  "File": "drivers/net/ethernet/meta/Kconfig",
  "FirstLine": 1,
  "LineCount": 40
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t#\n   3:\t# Meta Platforms network device configuration\n   4:\t#\n   5:\t\n   6:\tconfig NET_VENDOR_META\n   7:\t\tbool \"Meta Platforms devices\"\n   8:\t\tdefault y\n   9:\t\thelp\n  10:\t\t  If you have a network (Ethernet) card designed by Meta, say Y.\n  11:\t\t  That's Meta as in the parent company of Facebook.\n  12:\t\n  13:\t\t  Note that the answer to this question doesn't directly affect the\n  14:\t\t  kernel: saying N will just cause the configurator to skip all\n  15:\t\t  the questions about Meta cards. If you say Y, you will be asked for\n  16:\t\t  your specific card in the following questions.\n  17:\t\n  18:\tif NET_VENDOR_META\n  19:\t\n  20:\tconfig FBNIC\n  21:\t\ttristate \"Meta Platforms Host Network Interface\"\n  22:\t\tdepends on 64BIT || COMPILE_TEST\n  23:\t\tdepends on !S390\n  24:\t\tdepends on MAX_SKB_FRAGS \u003c 22\n  25:\t\tdepends on PCI_MSI\n  26:\t\tdepends on PTP_1588_CLOCK_OPTIONAL\n  27:\t\tselect NET_DEVLINK\n  28:\t\tselect PAGE_POOL\n  29:\t\tselect PCS_XPCS\n  30:\t\tselect PHYLINK\n  31:\t\tselect PLDMFW\n  32:\t\thelp\n  33:\t\t  This driver supports Meta Platforms Host Network Interface.\n  34:\t\n  35:\t\t  To compile this driver as a module, choose M here. The module\n  36:\t\t  will be called fbnic.  MSI-X interrupt support is required.\n  37:\t\n  38:\tconfig MPNIC\n  39:\t\ttristate \"Meta Platforms Network Interface Controller\"\n  40:\t\tdepends on 64BIT || COMPILE_TEST\n"
}

gemini-3.8-flash

null

null

							input: 7560
							output: 40
							thoughts: 143
						

**My Assessment of the fbnic Driver's Emulation Status**

Okay, let's see, the instructions highlight "Structurally unreachable hardware" – that's my focus here. Section 2 mentions vendor-specific PCIe switches, SmartNICs, and GPU drivers. Right, that makes sense. Now, the key question: is `fbnic` one of *those*? Does `fbnic`, that Meta NIC, require physical ASIC/PCIe cards that aren't emulated in the standard QEMU environment?

Let me investigate. I need to understand whether `fbnic` has the same constraints as those specific examples. Time to dive into the details. I will quickly check if QEMU offers any emulation support. And then I will try to identify PCI device IDs, or some other identifier to determine the exact hardware in question. So, `fbnic` is Meta's custom ASIC NIC, the Meta Platforms Host Network Interface. Let's see what the PCI device IDs tell me.

{
  "Expression": "fbnic_pci_tbl",
  "PathPrefixes": [
    "drivers/net/ethernet/meta/fbnic/"
  ]
}

{
  "Output": "drivers/net/ethernet/meta/fbnic/fbnic_pci.c=26=static const struct fbnic_info *fbnic_info_tbl[] = {\n--\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-29-\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c:30:static const struct pci_device_id fbnic_pci_tbl[] = {\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-31-\t{ PCI_DEVICE_DATA(META, FBNIC_ASIC, fbnic_board_asic) },\n--\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-34-};\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c:35:MODULE_DEVICE_TABLE(pci, fbnic_pci_tbl);\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-36-\n--\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c=219=static void fbnic_service_task(struct work_struct *work)\n--\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-262- * @pdev: PCI device information struct\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c:263: * @ent: entry in fbnic_pci_tbl\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-264- *\n--\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c=659=static struct pci_driver fbnic_driver = {\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-660-\t.name\t\t= fbnic_driver_name,\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c:661:\t.id_table\t= fbnic_pci_tbl,\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-662-\t.probe\t\t= fbnic_probe,\n"
}

gemini-3.8-flash

null

null

							input: 8510
							output: 38
							thoughts: 613
						

**WorthFuzzing=False: fbnic Driver Analysis**

Okay, let's break this down. That `{ PCI_DEVICE_DATA(META, FBNIC_ASIC, fbnic_board_asic) }` is the key. Meta's `0x1d9b` vendor ID, and `fbnic` is their in-house, proprietary ASIC. No standard emulation, not in QEMU or GCE. These environments focus on emulating established NICs like e1000, virtio-net, the usual suspects. They don't touch something like `fbnic`.

Now, let's hit the triage philosophy from the prompt. Reachability is the core. Fuzzing's only going to hit code that's *actually* going to execute in a standard virtual environment. If it's unreachable, it's a no-go for fuzzing, assertion or complexity be damned.

Looking at the "WHEN TO RETURN WorthFuzzing=false" negative criteria, it's pretty clear cut. Structurally unreachable hardware, things like vendor-specific PCIe switches, SmartNICs, GPU drivers (mlxsw, qed, and so on) that demand the physical ASIC/PCIe cards that *aren't* emulated in standard QEMU. That is exactly what this `fbnic` is.

This is vendor-specific NIC, requiring Meta's physical ASIC/PCIe, which is *not* emulated in QEMU or GCE.

The modified files listed: `drivers/net/ethernet/meta/fbnic/fbnic_csr.h`, `drivers/net/ethernet/meta/fbnic/fbnic_fw.c`, `drivers/net/ethernet/meta/fbnic/fbnic_netdev.c`, `drivers/net/ethernet/meta/fbnic/fbnic_pci.c`, `drivers/net/ethernet/meta/fbnic/fbnic_txrx.c`. Every single one is squarely inside `drivers/net/ethernet/meta/fbnic/`.

Since *all* modified code falls under that "structurally unreachable hardware" category, that seals it.

Just to be absolutely certain, I'm doing a quick sweep for any simulation, mock, or virtual interfaces within `fbnic`, searching for keywords like "sim", "mock", or "virtual", just to be absolutely certain there are no escape hatches for fuzzer use. I see none. **WorthFuzzing=false.**

{
  "Expression": "PCI_DEVICE_DATA",
  "PathPrefixes": [
    "drivers/net/ethernet/meta/fbnic/"
  ]
}

{
  "Output": "drivers/net/ethernet/meta/fbnic/fbnic_pci.c=30=static const struct pci_device_id fbnic_pci_tbl[] = {\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c:31:\t{ PCI_DEVICE_DATA(META, FBNIC_ASIC, fbnic_board_asic) },\ndrivers/net/ethernet/meta/fbnic/fbnic_pci.c-32-\t/* Required last entry */\n"
}

gemini-3.8-flash

null

null

							input: 9837
							output: 91
							thoughts: 142
						

**My Assessment of the Fuzzing Suitability**

Okay, so I've examined this patch, and here's the bottom line. It's targeting the `fbnic` driver, which is specifically designed to work with Meta Platforms' ASIC hardware – that's the key. I can see the single PCI ID is `{ PCI_DEVICE_DATA(META, FBNIC_ASIC, fbnic_board_asic) }`, which confirms this hardware dependency.

The driver, as far as I can tell from this snippet, absolutely requires that specific Meta ASIC. Since these types of ASICs aren't emulated within our standard virtualization environments, like QEMU or Google Compute Engine, the modified code in `drivers/net/ethernet/meta/fbnic/` is effectively unreachable for any fuzzing attempts within those platforms.

Therefore, my assessment is:

*   `WorthFuzzing`: false. It's not worth the effort in our current setup.
*   `EnableConfigs`: Empty. No configurations are required, as it won't be applicable.
*   `FocusSymbols`: Empty. No specific symbols jump out as relevant for fuzzing within the context of the infrastructure.

I'm confident in this evaluation, so it's time to set these results and move on to the next one.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The changes only affect the fbnic driver (drivers/net/ethernet/meta/fbnic/), which is for Meta's proprietary PCIe NIC hardware. This hardware is not emulated in standard QEMU or GCE virtualized environments, making the modified code structurally unreachable for fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The changes only affect the fbnic driver (drivers/net/ethernet/meta/fbnic/), which is for Meta's proprietary PCIe NIC hardware. This hardware is not emulated in standard QEMU or GCE virtualized environments, making the modified code structurally unreachable for fuzzing.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null