AI Trajectory

null

{
  "EnableConfigs": [
    "VXLAN",
    "INET",
    "IPV6"
  ],
  "FocusSymbols": [
    "vxlan_xmit",
    "vxlan_xmit_one"
  ],
  "KMSANReasoning": "The patch performs a minor refactoring in `vxlan_na_create()` within `drivers/net/vxlan/vxlan_core.c`. It caches `LL_RESERVED_SPACE(dev)` in a local variable `headroom` and reuses it for both the allocation size calculation and `skb_reserve(reply, headroom)`. Because `dev` is initialized as `request-\u003edev`, this change introduces no change in runtime values, memory layout, buffer allocations, or data copying. There are no uninitialized variables, structure padding leaks, or uninitialized memory reads introduced or exposed. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch fixes the headroom calculation and reservation in vxlan_na_create() when constructing IPv6 Neighbor Advertisement packets in the VXLAN driver. This virtual networking code path is reachable in standard virtualized environments with VXLAN proxy mode enabled.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit a7737988d73d5570e13e87601d4454f660a5fbb6\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 31 06:37:31 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c\nindex 459f19f7071e5..e5a92d30113c6 100644\n--- a/drivers/net/vxlan/vxlan_core.c\n+++ b/drivers/net/vxlan/vxlan_core.c\n@@ -1947,13 +1947,15 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,\n \tstruct ipv6hdr *pip6;\n \tu8 *daddr;\n \tint na_olen = 8; /* opt hdr + ETH_ALEN for target */\n+\tint headroom;\n \tint ns_olen;\n \tint i, len;\n \n \tif (dev == NULL || !pskb_may_pull(request, request-\u003elen))\n \t\treturn NULL;\n \n-\tlen = LL_RESERVED_SPACE(dev) + sizeof(struct ipv6hdr) +\n+\theadroom = LL_RESERVED_SPACE(dev);\n+\tlen = headroom + sizeof(struct ipv6hdr) +\n \t\tsizeof(*na) + na_olen + dev-\u003eneeded_tailroom;\n \treply = alloc_skb(len, GFP_ATOMIC);\n \tif (reply == NULL)\n@@ -1961,7 +1963,7 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,\n \n \treply-\u003eprotocol = htons(ETH_P_IPV6);\n \treply-\u003edev = dev;\n-\tskb_reserve(reply, LL_RESERVED_SPACE(request-\u003edev));\n+\tskb_reserve(reply, headroom);\n \tskb_push(reply, sizeof(struct ethhdr));\n \tskb_reset_mac_header(reply);\n \n"
}

core

null

{
  "EnableConfigs": [
    "VXLAN",
    "INET",
    "IPV6"
  ],
  "FocusSymbols": [
    "vxlan_xmit",
    "vxlan_xmit_one"
  ],
  "Reasoning": "The patch fixes the headroom calculation and reservation in vxlan_na_create() when constructing IPv6 Neighbor Advertisement packets in the VXLAN driver. This virtual networking code path is reachable in standard virtualized environments with VXLAN proxy mode enabled.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a '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.

For your convenience, here is the diff of the changes:
commit a7737988d73d5570e13e87601d4454f660a5fbb6
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 31 06:37:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 459f19f7071e5..e5a92d30113c6 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -1947,13 +1947,15 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,
 	struct ipv6hdr *pip6;
 	u8 *daddr;
 	int na_olen = 8; /* opt hdr + ETH_ALEN for target */
+	int headroom;
 	int ns_olen;
 	int i, len;
 
 	if (dev == NULL || !pskb_may_pull(request, request->len))
 		return NULL;
 
-	len = LL_RESERVED_SPACE(dev) + sizeof(struct ipv6hdr) +
+	headroom = LL_RESERVED_SPACE(dev);
+	len = headroom + sizeof(struct ipv6hdr) +
 		sizeof(*na) + na_olen + dev->needed_tailroom;
 	reply = alloc_skb(len, GFP_ATOMIC);
 	if (reply == NULL)
@@ -1961,7 +1963,7 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,
 
 	reply->protocol = htons(ETH_P_IPV6);
 	reply->dev = dev;
-	skb_reserve(reply, LL_RESERVED_SPACE(request->dev));
+	skb_reserve(reply, headroom);
 	skb_push(reply, sizeof(struct ethhdr));
 	skb_reset_mac_header(reply);
 

gemini-3.7-flash

null

null

							input: 2343
							output: 42
							thoughts: 527
						

**Analyzing the VXLAN Neighbor Advertisement Creation**

Alright, let's dive into this patch. I'm looking at `vxlan_na_create` within `vxlan_core.c` – seems like we're optimizing the creation of Neighbor Advertisement (NA) packets within the VXLAN driver. The diff itself is relatively focused, so I think I can understand it fairly quickly.

The core change revolves around how the `sk_buff` is allocated for the NA reply. Specifically, it seems like we're adjusting the calculation of `len` passed into `alloc_skb()`. The original code appears to have had a slightly off calculation for the buffer size, and this patch aims to correct it by explicitly calculating `headroom`. The code now explicitly calculates and sets the `headroom` required using `LL_RESERVED_SPACE(dev)`, which is then used when allocating and reserving the `skb`. That should fix the issue! The updated `len` also incorporates the IPv6 header, NA structure, option headers, Ethernet address and tailroom, all critical to the packet's format.

It's a good practice to double-check these calculations, especially when dealing with buffer allocation in network drivers. Incorrect buffer sizing can lead to all sorts of nasty issues, from buffer overflows to packet corruption and performance degradation. So, I see the change and am in agreement with it. Looks like a solid fix to address a subtle potential issue.

{
  "File": "drivers/net/vxlan/vxlan_core.c",
  "FirstLine": 1930,
  "LineCount": 80
}

{
  "Contents": "1930:\t\t\t};\n1931:\t\n1932:\t\t\tvxlan_ip_miss(dev, \u0026ipa);\n1933:\t\t}\n1934:\tout:\n1935:\t\tconsume_skb(skb);\n1936:\t\treturn NETDEV_TX_OK;\n1937:\t}\n1938:\t\n1939:\t#if IS_ENABLED(CONFIG_IPV6)\n1940:\tstatic struct sk_buff *vxlan_na_create(struct sk_buff *request,\n1941:\t\t\t\t\t       struct neighbour *n, u8 *ha,\n1942:\t\t\t\t\t       bool isrouter)\n1943:\t{\n1944:\t\tstruct net_device *dev = request-\u003edev;\n1945:\t\tstruct sk_buff *reply;\n1946:\t\tstruct nd_msg *ns, *na;\n1947:\t\tstruct ipv6hdr *pip6;\n1948:\t\tu8 *daddr;\n1949:\t\tint na_olen = 8; /* opt hdr + ETH_ALEN for target */\n1950:\t\tint headroom;\n1951:\t\tint ns_olen;\n1952:\t\tint i, len;\n1953:\t\n1954:\t\tif (dev == NULL || !pskb_may_pull(request, request-\u003elen))\n1955:\t\t\treturn NULL;\n1956:\t\n1957:\t\theadroom = LL_RESERVED_SPACE(dev);\n1958:\t\tlen = headroom + sizeof(struct ipv6hdr) +\n1959:\t\t\tsizeof(*na) + na_olen + dev-\u003eneeded_tailroom;\n1960:\t\treply = alloc_skb(len, GFP_ATOMIC);\n1961:\t\tif (reply == NULL)\n1962:\t\t\treturn NULL;\n1963:\t\n1964:\t\treply-\u003eprotocol = htons(ETH_P_IPV6);\n1965:\t\treply-\u003edev = dev;\n1966:\t\tskb_reserve(reply, headroom);\n1967:\t\tskb_push(reply, sizeof(struct ethhdr));\n1968:\t\tskb_reset_mac_header(reply);\n1969:\t\n1970:\t\tns = (struct nd_msg *)(ipv6_hdr(request) + 1);\n1971:\t\n1972:\t\tdaddr = eth_hdr(request)-\u003eh_source;\n1973:\t\tns_olen = request-\u003elen - skb_network_offset(request) -\n1974:\t\t\tsizeof(struct ipv6hdr) - sizeof(*ns);\n1975:\t\tfor (i = 0; i \u003c ns_olen-1; i += (ns-\u003eopt[i+1]\u003c\u003c3)) {\n1976:\t\t\tif (!ns-\u003eopt[i + 1] || i + (ns-\u003eopt[i + 1] \u003c\u003c 3) \u003e ns_olen) {\n1977:\t\t\t\tkfree_skb(reply);\n1978:\t\t\t\treturn NULL;\n1979:\t\t\t}\n1980:\t\t\tif (ns-\u003eopt[i] == ND_OPT_SOURCE_LL_ADDR) {\n1981:\t\t\t\tif ((ns-\u003eopt[i + 1] \u003c\u003c 3) \u003e=\n1982:\t\t\t\t    sizeof(struct nd_opt_hdr) + ETH_ALEN)\n1983:\t\t\t\t\tdaddr = ns-\u003eopt + i + sizeof(struct nd_opt_hdr);\n1984:\t\t\t\tbreak;\n1985:\t\t\t}\n1986:\t\t}\n1987:\t\n1988:\t\t/* Ethernet header */\n1989:\t\tether_addr_copy(eth_hdr(reply)-\u003eh_dest, daddr);\n1990:\t\tether_addr_copy(eth_hdr(reply)-\u003eh_source, ha);\n1991:\t\teth_hdr(reply)-\u003eh_proto = htons(ETH_P_IPV6);\n1992:\t\treply-\u003eprotocol = htons(ETH_P_IPV6);\n1993:\t\n1994:\t\tskb_pull(reply, sizeof(struct ethhdr));\n1995:\t\tskb_reset_network_header(reply);\n1996:\t\tskb_put(reply, sizeof(struct ipv6hdr));\n1997:\t\n1998:\t\t/* IPv6 header */\n1999:\t\n2000:\t\tpip6 = ipv6_hdr(reply);\n2001:\t\tmemset(pip6, 0, sizeof(struct ipv6hdr));\n2002:\t\tpip6-\u003eversion = 6;\n2003:\t\tpip6-\u003epriority = ipv6_hdr(request)-\u003epriority;\n2004:\t\tpip6-\u003enexthdr = IPPROTO_ICMPV6;\n2005:\t\tpip6-\u003ehop_limit = 255;\n2006:\t\tpip6-\u003edaddr = ipv6_hdr(request)-\u003esaddr;\n2007:\t\tpip6-\u003esaddr = *(struct in6_addr *)n-\u003eprimary_key;\n2008:\t\n2009:\t\tskb_pull(reply, sizeof(struct ipv6hdr));\n"
}

gemini-3.7-flash

null

null

							input: 4533
							output: 33
							thoughts: 30
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing `vxlan_na_create` and Related Functions**

Alright, let's dive into this `vxlan_core.c` code. My first instinct is to understand the context of `vxlan_na_create`. I need to figure out the calling hierarchy and how it interacts with other core vxlan functions. I'm going to quickly search for all the call sites of `vxlan_na_create` to get the big picture of how it fits within the overall vxlan data plane setup. Beyond that, I need to look for functions closely related to the operation, and their relationship to this particular piece of the code. This will shed light on what dependencies it has, what data structures it manipulates, and the overall data flow. I'm looking for the key entry points and exit paths, so I can start to reason about its behavior in the overall control path. I'll focus on functions that allocate, configure, or deallocate resources that are used by this function to see how the overall process works.

{
  "Expression": "vxlan_na_create",
  "PathPrefix": "drivers/net/vxlan/"
}

{
  "Output": "drivers/net/vxlan/vxlan_core.c=1842=static int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-1939-#if IS_ENABLED(CONFIG_IPV6)\ndrivers/net/vxlan/vxlan_core.c:1940:static struct sk_buff *vxlan_na_create(struct sk_buff *request,\ndrivers/net/vxlan/vxlan_core.c-1941-\t\t\t\t       struct neighbour *n, u8 *ha,\n--\ndrivers/net/vxlan/vxlan_core.c=2036=static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-2078-\ndrivers/net/vxlan/vxlan_core.c:2079:\t\treply = vxlan_na_create(skb, n, ha,\ndrivers/net/vxlan/vxlan_core.c-2080-\t\t\t\t\t!!(f ? f-\u003eflags \u0026 NTF_ROUTER : 0));\n"
}

gemini-3.7-flash

null

null

							input: 5140
							output: 30
							thoughts: 16
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing `neigh_reduce` and VXLAN Function Calls**

Okay, so I need to quickly get a handle on the interaction between `neigh_reduce` and VXLAN. My immediate thought is to trace the function calls to understand the flow. Specifically, I want to identify the direct callers and, if possible, the broader context of how VXLAN is involved in those calls. Are we talking about packet handling, control plane interactions, or something else entirely? A simple call graph would be ideal here, but I’ll need to figure out the right tools or methods to generate that if it's not readily available. From that, I can quickly form a hypothesis regarding where to focus my attention.

{
  "Expression": "neigh_reduce",
  "PathPrefix": "drivers/net/vxlan/"
}

{
  "Output": "drivers/net/vxlan/vxlan_core.c=1940=static struct sk_buff *vxlan_na_create(struct sk_buff *request,\n--\ndrivers/net/vxlan/vxlan_core.c-2035-\ndrivers/net/vxlan/vxlan_core.c:2036:static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\ndrivers/net/vxlan/vxlan_core.c-2037-{\n--\ndrivers/net/vxlan/vxlan_core.c=2739=static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)\n--\ndrivers/net/vxlan/vxlan_core.c-2780-\t\t\t    m-\u003eicmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION)\ndrivers/net/vxlan/vxlan_core.c:2781:\t\t\t\treturn neigh_reduce(dev, skb, vni);\ndrivers/net/vxlan/vxlan_core.c-2782-\t\t}\n"
}

gemini-3.7-flash

null

null

							input: 5642
							output: 26
							thoughts: 16
						

Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:

**Diving into the VXLAN Kconfig**

Okay, time to take a look at the `drivers/net/vxlan/Kconfig`. I need to understand what configuration options are available and how they are structured. My goal here is likely to get a clear picture of what features are being exposed, the dependencies between them, and potentially the default configurations. I'm going to quickly scan for the main symbols, checking for things like:

*   The base VXLAN driver itself (`CONFIG_VXLAN`) – is it enabled by default, and what's its status?
*   Any options for different encapsulation types or tunneling protocols besides UDP VXLAN.
*   Feature flags: Are there controls for checksum offloading, TSO, GRO/GSO, or other performance-related options? I'll need to know which ones are exposed so I can evaluate the implementation's capabilities.
*   Hardware-specific configurations, such as NIC-specific offloads or any potential dependencies on certain hardware features or platforms.
*   Debugging or tracing options, since I might be looking into tracing a fault and debugging.

I will also be on the lookout for any dependencies. I should be able to quickly spot if any other kernel modules or options are required for the VXLAN functionality to be enabled and working correctly. My mind is already racing, looking at the hierarchy and thinking about how those options might affect the build process, the size of the kernel image, and, ultimately, the performance and behavior of VXLAN in a real-world scenario.

{
  "Expression": "VXLAN",
  "PathPrefix": "drivers/net/"
}

{
  "Output": "\nFull output is too long, showing 500 out of 4622 lines.\nUse more precise expression if possible.\n\ndrivers/net/Kconfig=216=config IPVTAP\n--\ndrivers/net/Kconfig-229-\ndrivers/net/Kconfig:230:config VXLAN\ndrivers/net/Kconfig:231:\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\ndrivers/net/Kconfig-232-\tdepends on INET\n--\ndrivers/net/Kconfig-236-\t  This allows one to create vxlan virtual interfaces that provide\ndrivers/net/Kconfig:237:\t  Layer 2 Networks over Layer 3 Networks. VXLAN is often used\ndrivers/net/Kconfig-238-\t  to tunnel virtual network infrastructure in virtualized environments.\n--\ndrivers/net/Makefile=35=obj-$(CONFIG_VIRTIO_NET) += virtio_net.o\ndrivers/net/Makefile:36:obj-$(CONFIG_VXLAN) += vxlan/\ndrivers/net/Makefile-37-obj-$(CONFIG_GENEVE) += geneve.o\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h-1167-#define TX_PACKET_ATTRIBUTES_PTP_WIDTH\t\t1\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h:1168:#define TX_PACKET_ATTRIBUTES_VXLAN_INDEX\t4\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h:1169:#define TX_PACKET_ATTRIBUTES_VXLAN_WIDTH\t1\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h-1170-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h-1213-#define TX_NORMAL_DESC2_VLAN_INSERT\t\t0x2\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h:1214:#define TX_NORMAL_DESC3_VXLAN_PACKET\t\t0x3\ndrivers/net/ethernet/amd/xgbe/xgbe-common.h-1215-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c=390=static void xgbe_set_vxlan_id(struct xgbe_prv_data *pdata)\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-391-{\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:392:\t/* Program the VXLAN port */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-393-\tXGMAC_IOWRITE_BITS(pdata, MAC_TIR, TNID, pdata-\u003evxlan_port);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-394-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:395:\tnetif_dbg(pdata, drv, pdata-\u003enetdev, \"VXLAN tunnel id set to %hx\\n\",\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-396-\t\t  pdata-\u003evxlan_port);\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c=399=static void xgbe_enable_vxlan(struct xgbe_prv_data *pdata)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-403-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:404:\t/* Program the VXLAN port */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-405-\txgbe_set_vxlan_id(pdata);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-406-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:407:\t/* Allow for IPv6/UDP zero-checksum VXLAN packets */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-408-\tXGMAC_IOWRITE_BITS(pdata, MAC_PFR, VUCC, 1);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-409-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:410:\t/* Enable VXLAN tunneling mode */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-411-\tXGMAC_IOWRITE_BITS(pdata, MAC_TCR, VNM, 0);\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-413-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:414:\tnetif_dbg(pdata, drv, pdata-\u003enetdev, \"VXLAN acceleration enabled\\n\");\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-415-}\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c=417=static void xgbe_disable_vxlan(struct xgbe_prv_data *pdata)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-424-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:425:\t/* Clear IPv6/UDP zero-checksum VXLAN packets setting */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-426-\tXGMAC_IOWRITE_BITS(pdata, MAC_PFR, VUCC, 0);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-427-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:428:\t/* Clear the VXLAN port */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-429-\tXGMAC_IOWRITE_BITS(pdata, MAC_TIR, TNID, 0);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-430-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:431:\tnetif_dbg(pdata, drv, pdata-\u003enetdev, \"VXLAN acceleration disabled\\n\");\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-432-}\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c=1615=static void xgbe_dev_xmit(struct xgbe_channel *channel)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-1641-\tvxlan = XGMAC_GET_BITS(packet-\u003eattributes, TX_PACKET_ATTRIBUTES,\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:1642:\t\t\t       VXLAN);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-1643-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-1775-\t\tXGMAC_SET_BITS_LE(rdesc-\u003edesc3, TX_NORMAL_DESC3, VNP,\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:1776:\t\t\t\t  TX_NORMAL_DESC3_VXLAN_PACKET);\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-1777-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c=3571=void xgbe_init_function_ptrs_dev(struct xgbe_hw_if *hw_if)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-3669-\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c:3670:\t/* For VXLAN */\ndrivers/net/ethernet/amd/xgbe/xgbe-dev.c-3671-\thw_if-\u003eenable_vxlan = xgbe_enable_vxlan;\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c=690=void xgbe_get_all_hw_features(struct xgbe_prv_data *pdata)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-838-\t\t\thw_feat-\u003esa_vlan_ins ? \"yes\" : \"no\");\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c:839:\t\tdev_dbg(pdata-\u003edev, \"  VXLAN/NVGRE support       : %s\\n\",\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-840-\t\t\thw_feat-\u003evxn ? \"yes\" : \"no\");\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c=906=static const struct udp_tunnel_nic_info xgbe_udp_tunnels = {\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-910-\t.tables\t\t= {\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c:911:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN, },\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-912-\t},\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c=1440=static int xgbe_prep_tso(struct sk_buff *skb, struct xgbe_packet_data *packet)\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1451-\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c:1452:\tif (XGMAC_GET_BITS(packet-\u003eattributes, TX_PACKET_ATTRIBUTES, VXLAN)) {\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1453-\t\tpacket-\u003eheader_len = skb_inner_tcp_all_headers(skb);\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c=1521=static void xgbe_packet_info(struct xgbe_prv_data *pdata,\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1557-\t\tXGMAC_SET_BITS(packet-\u003eattributes, TX_PACKET_ATTRIBUTES,\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c:1558:\t\t\t       VXLAN, 1);\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1559-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c=1935=static netdev_features_t xgbe_fix_features(struct net_device *netdev,\n--\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1945-\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c:1946:\t/* VXLAN CSUM requires VXLAN base */\ndrivers/net/ethernet/amd/xgbe/xgbe-drv.c-1947-\tif ((features \u0026 NETIF_F_GSO_UDP_TUNNEL_CSUM) \u0026\u0026\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h=704=struct xgbe_hw_if {\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h-800-\ndrivers/net/ethernet/amd/xgbe/xgbe.h:801:\t/* For VXLAN */\ndrivers/net/ethernet/amd/xgbe/xgbe.h-802-\tvoid (*enable_vxlan)(struct xgbe_prv_data *);\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h=932=struct xgbe_hw_features {\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h-950-\tunsigned int sa_vlan_ins;\t/* Source Address or VLAN Insertion */\ndrivers/net/ethernet/amd/xgbe/xgbe.h:951:\tunsigned int vxn;\t\t/* VXLAN/NVGRE */\ndrivers/net/ethernet/amd/xgbe/xgbe.h-952-\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h=993=struct xgbe_prv_data {\n--\ndrivers/net/ethernet/amd/xgbe/xgbe.h-1141-\ndrivers/net/ethernet/amd/xgbe/xgbe.h:1142:\t/* VXLAN settings */\ndrivers/net/ethernet/amd/xgbe/xgbe.h-1143-\tu16 vxlan_port;\n--\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h-50-#define HW_ATL_A0_TXD_CTL_CMD_WB      BIT(27)\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h:51:#define HW_ATL_A0_TXD_CTL_CMD_VXLAN   BIT(28)\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h-52-\n--\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0_internal.h-55-#define HW_ATL_B0_TXD_CTL_CMD_WB      BIT(27)\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0_internal.h:56:#define HW_ATL_B0_TXD_CTL_CMD_VXLAN   BIT(28)\ndrivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0_internal.h-57-\n--\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c=1436=static void bnge_hwrm_vnic_update_tunl_tpa(struct bnge_dev *bd,\n--\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c-1445-\tif (bn-\u003evxlan_port)\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c:1446:\t\ttunl_tpa_bmap |= VNIC_TPA_CFG_REQ_TNL_TPA_EN_BITMAP_VXLAN;\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c-1447-\tif (bn-\u003evxlan_gpe_port)\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c:1448:\t\ttunl_tpa_bmap |= VNIC_TPA_CFG_REQ_TNL_TPA_EN_BITMAP_VXLAN_GPE;\ndrivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c-1449-\tif (bn-\u003enge_port)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h=1339=enum bnx2x_udp_port_type {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h:1340:\tBNX2X_UDP_PORT_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h-1341-\tBNX2X_UDP_PORT_GENEVE,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c=2080=int bnx2x_rss(struct bnx2x *bp, struct bnx2x_rss_config_obj *rss_obj,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-2109-\t\tif (!CHIP_IS_E1x(bp)) {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:2110:\t\t\t/* valid only for TUNN_MODE_VXLAN tunnel mode */\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:2111:\t\t\t__set_bit(BNX2X_RSS_IPV4_VXLAN, \u0026params.rss_flags);\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:2112:\t\t\t__set_bit(BNX2X_RSS_IPV6_VXLAN, \u0026params.rss_flags);\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-2113-\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c=3362=static u32 bnx2x_xmit_type(struct bnx2x *bp, struct sk_buff *skb)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-3408-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:3409:/* VXLAN: 4 = 1 (for linear data BD) + 3 (2 for PBD and last BD) */\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:3410:#define BNX2X_NUM_VXLAN_TSO_WIN_SUB_BDS         4\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-3411-\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c=3419=static int bnx2x_pkt_req_lin(struct bnx2x *bp, struct sk_buff *skb,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-3425-\tif (xmit_type \u0026 XMIT_GSO_ENC)\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:3426:\t\tnum_tso_win_sub = BNX2X_NUM_VXLAN_TSO_WIN_SUB_BDS;\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c-3427-\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h=921=static inline int bnx2x_func_start(struct bnx2x *bp)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h-962-\t\tstart_params-\u003enetwork_cos_mode = FW_WRR;\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h:963:\tif (bp-\u003eudp_tunnel_ports[BNX2X_UDP_PORT_VXLAN]) {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h:964:\t\tport = bp-\u003eudp_tunnel_ports[BNX2X_UDP_PORT_VXLAN];\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h-965-\t\tstart_params-\u003evxlan_dst_port = port;\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h=3885=struct eth_classify_vlan_cmd {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-3893-/*\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:3894: * Command for adding/removing a VXLAN classification rule\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-3895- */\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h=4238=struct eth_rss_update_ramrod_data {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4247-#define ETH_RSS_UPDATE_RAMROD_DATA_IPV4_UDP_CAPABILITY_SHIFT 2\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:4248:#define ETH_RSS_UPDATE_RAMROD_DATA_IPV4_VXLAN_CAPABILITY (0x1\u003c\u003c3)\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:4249:#define ETH_RSS_UPDATE_RAMROD_DATA_IPV4_VXLAN_CAPABILITY_SHIFT 3\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4250-#define ETH_RSS_UPDATE_RAMROD_DATA_IPV6_CAPABILITY (0x1\u003c\u003c4)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4255-#define ETH_RSS_UPDATE_RAMROD_DATA_IPV6_UDP_CAPABILITY_SHIFT 6\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:4256:#define ETH_RSS_UPDATE_RAMROD_DATA_IPV6_VXLAN_CAPABILITY (0x1\u003c\u003c7)\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:4257:#define ETH_RSS_UPDATE_RAMROD_DATA_IPV6_VXLAN_CAPABILITY_SHIFT 7\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4258-#define ETH_RSS_UPDATE_RAMROD_DATA_TUNN_INNER_HDRS_CAPABILITY (0x1\u003c\u003c8)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h=4448=enum eth_tunn_type {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4449-\tTUNN_TYPE_NONE,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h:4450:\tTUNN_TYPE_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h-4451-\tTUNN_TYPE_L2_GRE,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c=10165=static int bnx2x_udp_port_update(struct bnx2x *bp)\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-10189-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10190:\tif (bp-\u003eudp_tunnel_ports[BNX2X_UDP_PORT_VXLAN]) {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10191:\t\tvxlan_port = bp-\u003eudp_tunnel_ports[BNX2X_UDP_PORT_VXLAN];\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-10192-\t\tswitch_update_params-\u003evxlan_dst_port = vxlan_port;\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c=10222=static const struct udp_tunnel_nic_info bnx2x_udp_tunnels = {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-10225-\t.tables\t\t= {\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10226:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN,  },\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c-10227-\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_GENEVE, },\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c=4483=static int bnx2x_setup_rss(struct bnx2x *bp,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c-4530-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4531:\tif (test_bit(BNX2X_RSS_IPV4_VXLAN, \u0026p-\u003erss_flags))\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4532:\t\tcaps |= ETH_RSS_UPDATE_RAMROD_DATA_IPV4_VXLAN_CAPABILITY;\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c-4533-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4534:\tif (test_bit(BNX2X_RSS_IPV6_VXLAN, \u0026p-\u003erss_flags))\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4535:\t\tcaps |= ETH_RSS_UPDATE_RAMROD_DATA_IPV6_VXLAN_CAPABILITY;\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c-4536-\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c=6199=static inline int bnx2x_func_send_switch_update(struct bnx2x *bp,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c-6249-\t\t\trdata-\u003einner_clss_l2gre = 1;\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:6250:\t\tif (test_bit(BNX2X_F_UPDATE_TUNNEL_INNER_CLSS_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c-6251-\t\t\t     \u0026switch_update_params-\u003echanges))\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h=715=enum {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-728-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h:729:\tBNX2X_RSS_IPV4_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h:730:\tBNX2X_RSS_IPV6_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-731-\tBNX2X_RSS_TUNN_INNER_HDRS,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h=1117=enum {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-1125-\tBNX2X_F_UPDATE_TUNNEL_INNER_CLSS_L2GRE,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h:1126:\tBNX2X_F_UPDATE_TUNNEL_INNER_CLSS_VXLAN,\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-1127-\tBNX2X_F_UPDATE_TUNNEL_INNER_CLSS_L2GENEVE,\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h=1179=struct bnx2x_func_start_params {\n--\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-1192-\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h:1193:\t/* UDP dest port for VXLAN */\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h-1194-\tu16 vxlan_dst_port;\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=5906=static int bnxt_hwrm_tunnel_dst_port_free(struct bnxt *bp, u8 tunnel_type)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5910-\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:5911:\tif (tunnel_type == TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN \u0026\u0026\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5912-\t    bp-\u003evxlan_fw_dst_port_id == INVALID_HW_RING_ID)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5924-\tswitch (tunnel_type) {\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:5925:\tcase TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN:\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5926-\t\treq-\u003etunnel_dst_port_id = cpu_to_le16(bp-\u003evxlan_fw_dst_port_id);\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5934-\t\tbreak;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:5935:\tcase TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN_GPE:\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5936-\t\treq-\u003etunnel_dst_port_id = cpu_to_le16(bp-\u003evxlan_gpe_fw_dst_port_id);\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=5953=static int bnxt_hwrm_tunnel_dst_port_alloc(struct bnxt *bp, __be16 port,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5975-\tswitch (tunnel_type) {\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:5976:\tcase TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN:\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5977-\t\tbp-\u003evxlan_port = port;\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5984-\t\tbreak;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:5985:\tcase TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN_GPE:\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-5986-\t\tbp-\u003evxlan_gpe_port = port;\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=6529=static void bnxt_hwrm_vnic_update_tunl_tpa(struct bnxt *bp,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-6537-\tif (bp-\u003evxlan_port)\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:6538:\t\ttunl_tpa_bmap |= VNIC_TPA_CFG_REQ_TNL_TPA_EN_BITMAP_VXLAN;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-6539-\tif (bp-\u003evxlan_gpe_port)\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:6540:\t\ttunl_tpa_bmap |= VNIC_TPA_CFG_REQ_TNL_TPA_EN_BITMAP_VXLAN_GPE;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-6541-\tif (bp-\u003enge_port)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=10744=static void bnxt_hwrm_free_tunnel_ports(struct bnxt *bp)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-10746-\tbnxt_hwrm_tunnel_dst_port_free(bp,\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:10747:\t\tTUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN);\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-10748-\tbnxt_hwrm_tunnel_dst_port_free(bp,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=16060=static int bnxt_udp_tunnel_set_port(struct net_device *netdev, unsigned int table,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16065-\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16066:\tif (ti-\u003etype == UDP_TUNNEL_TYPE_VXLAN)\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16067:\t\tcmd = TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16068-\telse if (ti-\u003etype == UDP_TUNNEL_TYPE_GENEVE)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16070-\telse\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16071:\t\tcmd = TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN_GPE;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16072-\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=16076=static int bnxt_udp_tunnel_unset_port(struct net_device *netdev, unsigned int table,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16081-\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16082:\tif (ti-\u003etype == UDP_TUNNEL_TYPE_VXLAN)\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16083:\t\tcmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16084-\telse if (ti-\u003etype == UDP_TUNNEL_TYPE_GENEVE)\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16086-\telse\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16087:\t\tcmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN_GPE;\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16088-\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c=16092=static const struct udp_tunnel_nic_info bnxt_udp_tunnels = {\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16096-\t.tables\t\t= {\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16097:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN,  },\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16098-\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_GENEVE, },\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16104-\t.tables\t\t= {\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16105:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN,  },\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16106-\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_GENEVE, },\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c:16107:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN_GPE, },\ndrivers/net/ethernet/broadcom/bnxt/bnxt.c-16108-\t},\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c=793=static int hwrm_cfa_decap_filter_alloc(struct bnxt *bp,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-811-\t\t   CFA_DECAP_FILTER_ALLOC_REQ_ENABLES_IP_PROTOCOL;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:812:\treq-\u003etunnel_type = CFA_DECAP_FILTER_ALLOC_REQ_TUNNEL_TYPE_VXLAN;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-813-\treq-\u003eip_protocol = CFA_DECAP_FILTER_ALLOC_REQ_IP_PROTOCOL_UDP;\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c=883=static int hwrm_cfa_encap_record_alloc(struct bnxt *bp,\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-898-\tencap = (struct hwrm_cfa_encap_data_vxlan *)\u0026req-\u003eencap_data;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:899:\treq-\u003eencap_type = CFA_ENCAP_RECORD_ALLOC_REQ_ENCAP_TYPE_VXLAN;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-900-\tether_addr_copy(encap-\u003edst_mac_addr, l2_info-\u003edmac);\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-908-\tencap_ipv4 = (struct hwrm_vxlan_ipv4_hdr *)encap-\u003el3;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:909:\tencap_ipv4-\u003ever_hlen = 4 \u003c\u003c VXLAN_IPV4_HDR_VER_HLEN_VERSION_SFT;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:910:\tencap_ipv4-\u003ever_hlen |= 5 \u003c\u003c VXLAN_IPV4_HDR_VER_HLEN_HEADER_LENGTH_SFT;\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.c-911-\tencap_ipv4-\u003ettl = encap_key-\u003ettl;\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.h=71=struct bnxt_tc_actions {\n--\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.h-73-#define BNXT_TC_ACTION_FLAG_FWD\t\t\tBIT(0)\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.h:74:#define BNXT_TC_ACTION_FLAG_FWD_VXLAN\t\tBIT(1)\ndrivers/net/ethernet/broadcom/bnxt/bnxt_tc.h-75-#define BNXT_TC_ACTION_FLAG_PUSH_VLAN\t\tBIT(3)\n--\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c-33-/* Change the value of SLI Packet Input Jabber Register to allow\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:34: * VXLAN TSO packets which can be 64424 bytes, exceeding the\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c-35- * MAX_GSO_SIZE we supplied to the kernel\n--\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c=395=static int cn23xx_setup_pf_device_regs(struct octeon_device *oct)\n--\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c-412-\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:413:\t/* Set SLI_PKT_IN_JABBER to handle large VXLAN packets */\ndrivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c-414-\tocteon_write_csr64(oct, CN23XX_SLI_PKT_IN_JABBER, CN23XX_INPUT_JABBER);\n--\ndrivers/net/ethernet/cavium/liquidio/lio_core.c=256=void liquidio_link_ctrl_cmd_completion(void *nctrl_ptr)\n--\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-372-\ndrivers/net/ethernet/cavium/liquidio/lio_core.c:373:\t\t/* Case to handle \"OCTNET_CMD_VXLAN_PORT_CONFIG\"\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-374-\t\t * Command passed by NIC driver\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-375-\t\t */\ndrivers/net/ethernet/cavium/liquidio/lio_core.c:376:\tcase OCTNET_CMD_VXLAN_PORT_CONFIG:\ndrivers/net/ethernet/cavium/liquidio/lio_core.c:377:\t\tif (nctrl-\u003encmd.s.more == OCTNET_CMD_VXLAN_PORT_ADD) {\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-378-\t\t\tnetif_info(lio, probe, lio-\u003enetdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-381-\t\t} else if (nctrl-\u003encmd.s.more ==\ndrivers/net/ethernet/cavium/liquidio/lio_core.c:382:\t\t\t   OCTNET_CMD_VXLAN_PORT_DEL) {\ndrivers/net/ethernet/cavium/liquidio/lio_core.c-383-\t\t\tnetif_info(lio, probe, lio-\u003enetdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c=2609=static int liquidio_set_rxcsum_command(struct net_device *netdev, int command,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2639- * @netdev:                pointer to network device\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2640: * @command:               OCTNET_CMD_VXLAN_PORT_CONFIG\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2641- * @vxlan_port:            VxLAN port to be added or deleted\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2642: * @vxlan_cmd_bit:         OCTNET_CMD_VXLAN_PORT_ADD,\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2643: *                              OCTNET_CMD_VXLAN_PORT_DEL\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2644- * Return:                     SUCCESS or FAILURE\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c=2675=static int liquidio_udp_tunnel_set_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2679-\treturn liquidio_vxlan_port_command(netdev,\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2680:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_CONFIG,\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2681-\t\t\t\t\t   htons(ti-\u003eport),\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2682:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_ADD);\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2683-}\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c=2685=static int liquidio_udp_tunnel_unset_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2690-\treturn liquidio_vxlan_port_command(netdev,\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2691:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_CONFIG,\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2692-\t\t\t\t\t   htons(ti-\u003eport),\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2693:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_DEL);\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2694-}\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c=2696=static const struct udp_tunnel_nic_info liquidio_udp_tunnels = {\n--\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2699-\t.tables\t\t= {\ndrivers/net/ethernet/cavium/liquidio/lio_main.c:2700:\t\t{ .n_entries = 1024, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN, },\ndrivers/net/ethernet/cavium/liquidio/lio_main.c-2701-\t},\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c=1698=static int liquidio_set_rxcsum_command(struct net_device *netdev, int command,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1726- * @param netdev                pointer to network device\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1727: * @param command               OCTNET_CMD_VXLAN_PORT_CONFIG\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1728- * @param vxlan_port            VxLAN port to be added or deleted\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1729: * @param vxlan_cmd_bit         OCTNET_CMD_VXLAN_PORT_ADD,\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1730: *                              OCTNET_CMD_VXLAN_PORT_DEL\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1731- * @returns                     SUCCESS or FAILURE\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c=1762=static int liquidio_udp_tunnel_set_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1766-\treturn liquidio_vxlan_port_command(netdev,\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1767:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_CONFIG,\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1768-\t\t\t\t\t   htons(ti-\u003eport),\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1769:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_ADD);\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1770-}\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c=1772=static int liquidio_udp_tunnel_unset_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1777-\treturn liquidio_vxlan_port_command(netdev,\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1778:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_CONFIG,\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1779-\t\t\t\t\t   htons(ti-\u003eport),\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1780:\t\t\t\t\t   OCTNET_CMD_VXLAN_PORT_DEL);\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1781-}\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c=1783=static const struct udp_tunnel_nic_info liquidio_udp_tunnels = {\n--\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1786-\t.tables\t\t= {\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c:1787:\t\t{ .n_entries = 1024, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN, },\ndrivers/net/ethernet/cavium/liquidio/lio_vf_main.c-1788-\t},\n--\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h=173=static inline void add_sg_size(struct octeon_sg_entry *sg_entry,\n--\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h-232-#define   OCTNET_CMD_DEL_VLAN_FILTER  0x18\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h:233:#define   OCTNET_CMD_VXLAN_PORT_CONFIG 0x19\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h-234-\n--\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h-245-\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h:246:#define   OCTNET_CMD_VXLAN_PORT_ADD    0x0\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h:247:#define   OCTNET_CMD_VXLAN_PORT_DEL    0x1\ndrivers/net/ethernet/cavium/liquidio/liquidio_common.h-248-#define   OCTNET_CMD_RXCSUM_ENABLE     0x0\n--\ndrivers/net/ethernet/cavium/thunder/nic_main.c=827=static void nic_enable_tunnel_parsing(struct nicpf *nic, int vf)\n--\ndrivers/net/ethernet/cavium/thunder/nic_main.c-839-\t\t      ((7ULL \u003c\u003c 61) | prot_def));\ndrivers/net/ethernet/cavium/thunder/nic_main.c:840:\tnic_reg_write(nic, NIC_PF_RX_VXLAN_DEF_0_1,\ndrivers/net/ethernet/cavium/thunder/nic_main.c:841:\t\t      ((1ULL \u003c\u003c 63) | UDP_VXLAN_PORT_NUM));\ndrivers/net/ethernet/cavium/thunder/nic_main.c:842:\tnic_reg_write(nic, NIC_PF_RX_VXLAN_PROT_DEF,\ndrivers/net/ethernet/cavium/thunder/nic_main.c-843-\t\t      ((0xfULL \u003c\u003c 60) | vxlan_prot_def));\n--\ndrivers/net/ethernet/cavium/thunder/nic_reg.h-42-#define   NIC_PF_RX_NVGRE_PROT_DEF\t\t(0x0598)\ndrivers/net/ethernet/cavium/thunder/nic_reg.h:43:#define   NIC_PF_RX_VXLAN_DEF_0_1\t\t(0x05A0)\ndrivers/net/ethernet/cavium/thunder/nic_reg.h:44:#define    UDP_VXLAN_PORT_NUM\t\t\t\t0x12B5\ndrivers/net/ethernet/cavium/thunder/nic_reg.h:45:#define   NIC_PF_RX_VXLAN_PROT_DEF\t\t(0x05B0)\ndrivers/net/ethernet/cavium/thunder/nic_reg.h-46-#define    IPV6_PROT_DEF\t\t\t\t0x2ULL\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c=3727=static int cxgb_udp_tunnel_unset_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3736-\tswitch (ti-\u003etype) {\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3737:\tcase UDP_TUNNEL_TYPE_VXLAN:\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3738-\t\tadapter-\u003evxlan_port = 0;\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3739:\t\tt4_write_reg(adapter, MPS_RX_VXLAN_TYPE_A, 0);\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3740-\t\tbreak;\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c=3770=static int cxgb_udp_tunnel_set_port(struct net_device *netdev,\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3779-\tswitch (ti-\u003etype) {\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3780:\tcase UDP_TUNNEL_TYPE_VXLAN:\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3781-\t\tadapter-\u003evxlan_port = ti-\u003eport;\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3782:\t\tt4_write_reg(adapter, MPS_RX_VXLAN_TYPE_A,\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3783:\t\t\t     VXLAN_V(be16_to_cpu(ti-\u003eport)) | VXLAN_EN_F);\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3784-\t\tbreak;\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c=3818=static const struct udp_tunnel_nic_info cxgb_udp_tunnels = {\n--\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3821-\t.tables\t\t= {\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3822:\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_VXLAN,  },\ndrivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c-3823-\t\t{ .n_entries = 1, .tunnel_types = UDP_TUNNEL_TYPE_GENEVE, },\n--\ndrivers/net/ethernet/chelsio/cxgb4/sge.c=1267=enum cpl_tx_tnl_lso_type cxgb_encap_offload_supported(struct sk_buff *skb)\n--\ndrivers/net/ethernet/chelsio/cxgb4/sge.c-1291-\t\tif (adapter-\u003evxlan_port == udp_hdr(skb)-\u003edest)\ndrivers/net/ethernet/chelsio/cxgb4/sge.c:1292:\t\t\ttnl_type = TX_TNL_TYPE_VXLAN;\ndrivers/net/ethernet/chelsio/cxgb4/sge.c-1293-\t\telse if (adapter-\u003egeneve_port == udp_hdr(skb)-\u003edest)\n--\ndrivers/net/ethernet/chelsio/cxgb4/sge.c=1303=static inline void t6_fill_tnl_lso(struct sk_buff *skb,\n--\ndrivers/net/ethernet/chelsio/cxgb4/sge.c-1332-\tswitch (tnl_type) {\ndrivers/net/ethernet/chelsio/cxgb4/sge.c:1333:\tcase TX_TNL_TYPE_VXLAN:\ndrivers/net/ethernet/chelsio/cxgb4/sge.c-1334-\tcase TX_TNL_TYPE_GENEVE:\n--\ndrivers/net/ethernet/chelsio/cxgb4/t4_msg.h=1578=enum cpl_tx_tnl_lso_type {\n--\ndrivers/net/ethernet/chelsio/cxgb4/t4_msg.h-1580-\tTX_TNL_TYPE_NVGRE,\ndrivers/net/ethernet/chelsio/cxgb4/t4_msg.h:1581:\tTX_TNL_TYPE_VXLAN,\ndrivers/net/ethernet/chelsio/cxgb4/t4_msg.h-1582-\tTX_TNL_TYPE_GENEVE,\n--\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h-2571-\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2572:#define MPS_RX_VXLAN_TYPE_A 0x11234\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h-2573-\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2574:#define VXLAN_EN_S    16\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2575:#define VXLAN_EN_V(x) ((x) \u003c\u003c VXLAN_EN_S)\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2576:#define VXLAN_EN_F    VXLAN_EN_V(1U)\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h-2577-\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2578:#define VXLAN_S    0\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2579:#define VXLAN_M    0xffffU\ndrivers/net/ethernet/chelsio/cxgb4/t4_regs.h:2580:#define VXLAN_V(x) ((x) \u003c\u003c VXLAN_S)\n\n"
}

gemini-3.7-flash

null

null

							input: 21486
							output: 34
							thoughts: 33
						

Okay, let's dive into this. I need to refresh my memory on the specifics of the VXLAN configuration within the kernel. The obvious starting points are the `drivers/net/vxlan/Makefile` and `drivers/net/Kconfig` files. These are the usual suspects for understanding how VXLAN support is compiled, what build options are available, and what Kconfig symbols control the feature's inclusion. I'll need to confirm the exact configuration options for the VXLAN module to check the build process. I want to ensure I understand every aspect of its construction and possible dependencies. Once I have the layout of the Kconfig options, I can further debug build issues if any arise.

{
  "File": "drivers/net/vxlan/Makefile",
  "FirstLine": 1,
  "LineCount": 20
}

{
  "Contents": "   1:\t#\n   2:\t# Makefile for the vxlan driver\n   3:\t#\n   4:\t\n   5:\tobj-$(CONFIG_VXLAN) += vxlan.o\n   6:\t\n   7:\tvxlan-objs := vxlan_core.o vxlan_multicast.o vxlan_vnifilter.o vxlan_mdb.o\n"
}

gemini-3.7-flash

null

null

							input: 21800
							output: 34
							thoughts: 19
						

Here's a summary of my thought process, as requested:

**Kconfig Dive**

Okay, time to dig in. Based on the task at hand (which I'm not privy to, but I'll assume involves a network driver, given the context), my initial thought is to navigate to the `drivers/net/Kconfig` file. Specifically, I'm going to zoom in around line 230. That location often holds the key to configuration options or dependencies related to network device drivers. It's a good starting point to understand how things are configured, what the existing options are, and if something relevant to my task is defined there. Let's see what gems we can unearth!

{
  "File": "drivers/net/Kconfig",
  "FirstLine": 225,
  "LineCount": 30
}

{
  "Contents": " 225:\t\t  ipvtap', and then be accessed through the tap user space interface.\n 226:\t\n 227:\t\t  To compile this driver as a module, choose M here: the module\n 228:\t\t  will be called ipvtap.\n 229:\t\n 230:\tconfig VXLAN\n 231:\t\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\n 232:\t\tdepends on INET\n 233:\t\tselect NET_UDP_TUNNEL\n 234:\t\tselect GRO_CELLS\n 235:\t\thelp\n 236:\t\t  This allows one to create vxlan virtual interfaces that provide\n 237:\t\t  Layer 2 Networks over Layer 3 Networks. VXLAN is often used\n 238:\t\t  to tunnel virtual network infrastructure in virtualized environments.\n 239:\t\t  For more information see:\n 240:\t\t    http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02\n 241:\t\n 242:\t\t  To compile this driver as a module, choose M here: the module\n 243:\t\t  will be called vxlan.\n 244:\t\n 245:\tconfig GENEVE\n 246:\t\ttristate \"Generic Network Virtualization Encapsulation\"\n 247:\t\tdepends on INET\n 248:\t\tselect NET_UDP_TUNNEL\n 249:\t\tselect GRO_CELLS\n 250:\t\thelp\n 251:\t\t  This allows one to create geneve virtual interfaces that provide\n 252:\t\t  Layer 2 Networks over Layer 3 Networks. GENEVE is often used\n 253:\t\t  to tunnel virtual network infrastructure in virtualized environments.\n 254:\t\t  For more information see:\n"
}

gemini-3.7-flash

null

null

							input: 22475
							output: 42
							thoughts: 415
						

**Analyzing the `vxlan_na_create` Fix**

Okay, let's dive into this `vxlan_na_create` function and understand the rationale behind this code change. First, let's isolate the bug that was addressed. I see that the original code:

```c
-	skb_reserve(reply, LL_RESERVED_SPACE(request->dev));
+	skb_reserve(reply, headroom);
```

used `LL_RESERVED_SPACE(request->dev)` for the `skb_reserve` call, while calculating `len` used `LL_RESERVED_SPACE(dev)`. The fix has replaced it with `headroom` which is `LL_RESERVED_SPACE(dev)`. I see that `dev` is assigned to `request->dev` so there may not have been a functional bug, but this makes the code consistent. The original calculation of the length was correct but there was a potential for a mismatch, or at least a redundant calculation if `request->dev` had changed. Using a local variable `headroom` makes the intention clear and the code cleaner.

Alright, let's step back and consider the context. This `vxlan_na_create` function is guarded by `#if IS_ENABLED(CONFIG_IPV6)`. That's important; it's specific to IPv6. Now, I need to understand if this function is used elsewhere within the VXLAN module, particularly around neighbor discovery or transmission. I'll need to check the broader codebase of `vxlan_core.c` and also look at entry points to functions like `neigh_reduce` or `vxlan_xmit` to get a full understanding.

I should also examine the rest of the `vxlan_na_create` function to check for any other related issues and then consider what's happening inside `neigh_reduce` for context.

{
  "File": "drivers/net/vxlan/vxlan_core.c",
  "FirstLine": 2010,
  "LineCount": 80
}

{
  "Contents": "2010:\t\tskb_reset_transport_header(reply);\n2011:\t\n2012:\t\t/* Neighbor Advertisement */\n2013:\t\tna = skb_put_zero(reply, sizeof(*na) + na_olen);\n2014:\t\tna-\u003eicmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;\n2015:\t\tna-\u003eicmph.icmp6_router = isrouter;\n2016:\t\tna-\u003eicmph.icmp6_override = 1;\n2017:\t\tna-\u003eicmph.icmp6_solicited = 1;\n2018:\t\tna-\u003etarget = ns-\u003etarget;\n2019:\t\tether_addr_copy(\u0026na-\u003eopt[2], ha);\n2020:\t\tna-\u003eopt[0] = ND_OPT_TARGET_LL_ADDR;\n2021:\t\tna-\u003eopt[1] = na_olen \u003e\u003e 3;\n2022:\t\n2023:\t\tna-\u003eicmph.icmp6_cksum = csum_ipv6_magic(\u0026pip6-\u003esaddr,\n2024:\t\t\t\u0026pip6-\u003edaddr, sizeof(*na)+na_olen, IPPROTO_ICMPV6,\n2025:\t\t\tcsum_partial(na, sizeof(*na)+na_olen, 0));\n2026:\t\n2027:\t\tpip6-\u003epayload_len = htons(sizeof(*na)+na_olen);\n2028:\t\n2029:\t\tskb_push(reply, sizeof(struct ipv6hdr));\n2030:\t\n2031:\t\treply-\u003eip_summed = CHECKSUM_UNNECESSARY;\n2032:\t\n2033:\t\treturn reply;\n2034:\t}\n2035:\t\n2036:\tstatic int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n2037:\t{\n2038:\t\tstruct vxlan_dev *vxlan = netdev_priv(dev);\n2039:\t\tconst struct in6_addr *daddr;\n2040:\t\tconst struct ipv6hdr *iphdr;\n2041:\t\tstruct neighbour *n;\n2042:\t\tstruct nd_msg *msg;\n2043:\t\n2044:\t\trcu_read_lock();\n2045:\t\tif (unlikely(!ipv6_mod_enabled()))\n2046:\t\t\tgoto out;\n2047:\t\n2048:\t\tiphdr = ipv6_hdr(skb);\n2049:\t\tdaddr = \u0026iphdr-\u003edaddr;\n2050:\t\tmsg = (struct nd_msg *)(iphdr + 1);\n2051:\t\n2052:\t\tif (ipv6_addr_loopback(daddr) ||\n2053:\t\t    ipv6_addr_is_multicast(\u0026msg-\u003etarget))\n2054:\t\t\tgoto out;\n2055:\t\n2056:\t\tn = neigh_lookup(\u0026nd_tbl, \u0026msg-\u003etarget, dev);\n2057:\t\n2058:\t\tif (n) {\n2059:\t\t\tstruct vxlan_rdst *rdst = NULL;\n2060:\t\t\tu8 ha[ETH_ALEN] __aligned(2);\n2061:\t\t\tstruct vxlan_fdb *f;\n2062:\t\t\tstruct sk_buff *reply;\n2063:\t\n2064:\t\t\tif (!(READ_ONCE(n-\u003enud_state) \u0026 NUD_CONNECTED)) {\n2065:\t\t\t\tneigh_release(n);\n2066:\t\t\t\tgoto out;\n2067:\t\t\t}\n2068:\t\n2069:\t\t\tneigh_ha_snapshot(ha, n, n-\u003edev);\n2070:\t\t\tf = vxlan_find_mac_tx(vxlan, ha, vni);\n2071:\t\t\tif (f)\n2072:\t\t\t\trdst = first_remote_rcu(f);\n2073:\t\t\tif (rdst \u0026\u0026 vxlan_addr_any(\u0026rdst-\u003eremote_ip)) {\n2074:\t\t\t\t/* bridge-local neighbor */\n2075:\t\t\t\tneigh_release(n);\n2076:\t\t\t\tgoto out;\n2077:\t\t\t}\n2078:\t\n2079:\t\t\treply = vxlan_na_create(skb, n, ha,\n2080:\t\t\t\t\t\t!!(f ? f-\u003eflags \u0026 NTF_ROUTER : 0));\n2081:\t\n2082:\t\t\tneigh_release(n);\n2083:\t\n2084:\t\t\tif (reply == NULL)\n2085:\t\t\t\tgoto out;\n2086:\t\n2087:\t\t\tif (netif_rx(reply) == NET_RX_DROP) {\n2088:\t\t\t\tdev_dstats_rx_dropped(dev);\n2089:\t\t\t\tvxlan_vnifilter_count(vxlan, vni, NULL,\n"
}

gemini-3.7-flash

null

null

							input: 24619
							output: 42
							thoughts: 20
						

Here's a breakdown of my thought process regarding `vxlan_xmit` and `neigh_reduce`:

**Diving into the VXLAN Transmission Path and Neighbor Discovery**

Okay, so I'm focusing in on the VXLAN transmit function (`vxlan_xmit`) and specifically, the point where `neigh_reduce` gets called. This means I'm looking at how the kernel handles sending VXLAN encapsulated traffic. The fact that `neigh_reduce` is involved tells me the system is likely dealing with a neighbor discovery and resolution scenario. It's a key part of how the system figures out the Layer 2 (MAC) address needed to reach the destination VXLAN tunnel endpoint (VTEP).

I need to understand *why* `neigh_reduce` is happening at this point. Is it because the ARP/ND cache entry for the destination VTEP is stale or missing? Or is the system actively probing to confirm connectivity? I'll probably need to trace the execution path from `vxlan_xmit` to `neigh_reduce` to nail down the specifics of the situation. Are we dealing with a multicast setup where the neighbor cache entry may be dynamic? 

I suspect this involves some form of ARP/ND solicitation or gratuitous ARP, but I need to analyze how the system decides *when* to invoke `neigh_reduce` in the `vxlan_xmit` code path. Is there a timer involved? What are the conditions that trigger the neighbor cache to be considered stale? Understanding the context is critical. I'll need to remember that VXLAN adds an outer IP/UDP header, so regular ARP/ND needs to be adapted.

I'll check the associated variables to confirm. Is there any buffering happening before neighbor resolution? Does this have implications for the packet delivery latency? Any potential for packet drops during the neighbor resolution process? I have to look for any optimizations or workarounds for this critical step.

{
  "File": "drivers/net/vxlan/vxlan_core.c",
  "FirstLine": 2750,
  "LineCount": 50
}

{
  "Contents": "2750:\t\tinfo = skb_tunnel_info(skb);\n2751:\t\n2752:\t\tskb_reset_mac_header(skb);\n2753:\t\n2754:\t\tif (vxlan-\u003ecfg.flags \u0026 VXLAN_F_COLLECT_METADATA) {\n2755:\t\t\tif (info \u0026\u0026 info-\u003emode \u0026 IP_TUNNEL_INFO_BRIDGE \u0026\u0026\n2756:\t\t\t    info-\u003emode \u0026 IP_TUNNEL_INFO_TX) {\n2757:\t\t\t\tvni = tunnel_id_to_key32(info-\u003ekey.tun_id);\n2758:\t\t\t\tnhid = info-\u003ekey.nhid;\n2759:\t\t\t} else {\n2760:\t\t\t\tif (info \u0026\u0026 info-\u003emode \u0026 IP_TUNNEL_INFO_TX)\n2761:\t\t\t\t\tvxlan_xmit_one(skb, dev, vni, NULL, false);\n2762:\t\t\t\telse\n2763:\t\t\t\t\tkfree_skb_reason(skb, SKB_DROP_REASON_TUNNEL_TXINFO);\n2764:\t\t\t\treturn NETDEV_TX_OK;\n2765:\t\t\t}\n2766:\t\t}\n2767:\t\n2768:\t\tif (vxlan-\u003ecfg.flags \u0026 VXLAN_F_PROXY) {\n2769:\t\t\teth = eth_hdr(skb);\n2770:\t\t\tif (ntohs(eth-\u003eh_proto) == ETH_P_ARP)\n2771:\t\t\t\treturn arp_reduce(dev, skb, vni);\n2772:\t#if IS_ENABLED(CONFIG_IPV6)\n2773:\t\t\telse if (ntohs(eth-\u003eh_proto) == ETH_P_IPV6 \u0026\u0026\n2774:\t\t\t\t pskb_network_may_pull(skb, sizeof(struct ipv6hdr) +\n2775:\t\t\t\t\t\t\t    sizeof(struct nd_msg)) \u0026\u0026\n2776:\t\t\t\t ipv6_hdr(skb)-\u003enexthdr == IPPROTO_ICMPV6) {\n2777:\t\t\t\tstruct nd_msg *m = (struct nd_msg *)(ipv6_hdr(skb) + 1);\n2778:\t\n2779:\t\t\t\tif (m-\u003eicmph.icmp6_code == 0 \u0026\u0026\n2780:\t\t\t\t    m-\u003eicmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION)\n2781:\t\t\t\t\treturn neigh_reduce(dev, skb, vni);\n2782:\t\t\t}\n2783:\t#endif\n2784:\t\t}\n2785:\t\n2786:\t\tif (nhid)\n2787:\t\t\treturn vxlan_xmit_nhid(skb, dev, nhid, vni);\n2788:\t\n2789:\t\tif (vxlan-\u003ecfg.flags \u0026 VXLAN_F_MDB) {\n2790:\t\t\tstruct vxlan_mdb_entry *mdb_entry;\n2791:\t\n2792:\t\t\trcu_read_lock();\n2793:\t\t\tmdb_entry = vxlan_mdb_entry_skb_get(vxlan, skb, vni);\n2794:\t\t\tif (mdb_entry) {\n2795:\t\t\t\tnetdev_tx_t ret;\n2796:\t\n2797:\t\t\t\tret = vxlan_mdb_xmit(vxlan, mdb_entry, skb);\n2798:\t\t\t\trcu_read_unlock();\n2799:\t\t\t\treturn ret;\n"
}

gemini-3.7-flash

null

null

							input: 25990
							output: 23
							thoughts: 543
						

**Analyzing a VXLAN Patch**

Okay, let's dive into this patch. It looks like we're touching `vxlan_na_create` within `drivers/net/vxlan/vxlan_core.c`. The core of the change is around how we allocate and prepare the SKB. I see the original code and the updated code side-by-side.

Initially, I'm thinking, "Is this a functional change? Or just some refactoring?" The original code directly computed the length and then allocated the SKB, while the new code introduces a `headroom` variable. It looks like it computes the length the exact same way.

Let's trace it through: `dev` is assigned to `request->dev` on line 1944. Ah, it's clear now. `LL_RESERVED_SPACE(dev)` and `LL_RESERVED_SPACE(request->dev)` are equivalent because `dev` is literally `request->dev`. This looks like some minor clean-up, maybe to improve readability or prepare for future changes.

To be absolutely sure, I should really check the definition of `LL_RESERVED_SPACE`. It would be good to confirm that this is just a variable assignment.

{
  "Expression": "#define LL_RESERVED_SPACE"
}

{
  "Output": "include/linux/netdevice.h=282=struct hh_cache {\n--\ninclude/linux/netdevice.h-302- */\ninclude/linux/netdevice.h:303:#define LL_RESERVED_SPACE_EX(dev, hlen) \\\ninclude/linux/netdevice.h-304-\t((((hlen) + READ_ONCE((dev)-\u003eneeded_headroom)) \\\ninclude/linux/netdevice.h-305-\t  \u0026 ~(HH_DATA_MOD - 1)) + HH_DATA_MOD)\ninclude/linux/netdevice.h:306:#define LL_RESERVED_SPACE(dev) \\\ninclude/linux/netdevice.h-307-\tLL_RESERVED_SPACE_EX(dev, (dev)-\u003ehard_header_len)\ninclude/linux/netdevice.h:308:#define LL_RESERVED_SPACE_EXTRA(dev,extra) \\\ninclude/linux/netdevice.h-309-\t((((dev)-\u003ehard_header_len + READ_ONCE((dev)-\u003eneeded_headroom) + (extra)) \\\n"
}

gemini-3.7-flash

null

null

							input: 27104
							output: 28
							thoughts: 154
						

**Analyzing Potential Data Races in Network Buffer Allocation**

Okay, so I'm looking at this `LL_RESERVED_SPACE(dev)` macro, specifically how it uses `READ_ONCE((dev)->needed_headroom)`. The red flag is immediate: if `dev->needed_headroom` is read in two places, and *especially* if that happens around the time we're setting up a network buffer (`skb`), then we could have a classic Time-of-Check-to-Time-of-Use (TOCTOU) data race. I see `needed_headroom` being read for calculating the overall length (`len = LL_RESERVED_SPACE(dev) + ...`) and again when we actually reserve space in the buffer (`skb_reserve(reply, LL_RESERVED_SPACE(request->dev));`). My concern is, if `needed_headroom` is modified concurrently, the calculated `len` and the reserved space in the SKB will be inconsistent. This could lead to all sorts of nasty buffer overflows or underflows, and I'm very keen to avoid that.

But, hold on. This *could* be a straightforward refactoring. Maybe I'm being too paranoid. I better verify this using other areas, like `arp_reduce` or `arp_create`. Let me compare those implementations and see how similar situations are handled there. That'll give me a clearer picture.

{
  "Expression": "arp_create",
  "PathPrefix": "net/ipv4/"
}

{
  "Output": "net/ipv4/arp.c-63- *\t\tArnaldo C. Melo :\tconvert /proc/net/arp to seq_file\nnet/ipv4/arp.c:64: *\t\tShmulik Hen:\t\tSplit arp_send to arp_create and\nnet/ipv4/arp.c-65- *\t\t\t\t\tarp_xmit so intermediate drivers like\n--\nnet/ipv4/arp.c=301=static void arp_send_dst(int type, int ptype, __be32 dest_ip,\n--\nnet/ipv4/arp.c-313-\nnet/ipv4/arp.c:314:\tskb = arp_create(type, ptype, dest_ip, dev, src_ip,\nnet/ipv4/arp.c-315-\t\t\t dest_hw, src_hw, target_hw);\n--\nnet/ipv4/arp.c=519=static inline int arp_fwd_pvlan(struct in_device *in_dev,\n--\nnet/ipv4/arp.c-544- */\nnet/ipv4/arp.c:545:struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,\nnet/ipv4/arp.c-546-\t\t\t   struct net_device *dev, __be32 src_ip,\n--\nnet/ipv4/arp.c-650-}\nnet/ipv4/arp.c:651:EXPORT_SYMBOL(arp_create);\nnet/ipv4/arp.c-652-\n"
}

gemini-3.7-flash

null

null

							input: 27985
							output: 36
							thoughts: 20
						

Here's my summary, as though I'm processing the code:

**Diving into `arp_create`**

Alright, let's get down to brass tacks. I'm looking at `arp_create` in `net/ipv4/arp.c`. This is where the magic of Address Resolution Protocol gets baked into the kernel's IPv4 stack. I know this function is crucial; it's the gatekeeper, deciding whether a new ARP entry gets created or if we need to do some detective work. I need to understand the conditions, the checks, the data structures it's manipulating. Essentially, I'm peeling back the layers on how the kernel builds and manages its ARP cache for IPv4. I'm keen to see if there are any potential race conditions, locking strategies, or even optimizations that could affect performance. This looks like an interesting starting point. Let's see what we find inside.

{
  "File": "net/ipv4/arp.c",
  "FirstLine": 545,
  "LineCount": 40
}

{
  "Contents": " 545:\tstruct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,\n 546:\t\t\t\t   struct net_device *dev, __be32 src_ip,\n 547:\t\t\t\t   const unsigned char *dest_hw,\n 548:\t\t\t\t   const unsigned char *src_hw,\n 549:\t\t\t\t   const unsigned char *target_hw)\n 550:\t{\n 551:\t\tstruct sk_buff *skb;\n 552:\t\tstruct arphdr *arp;\n 553:\t\tunsigned char *arp_ptr;\n 554:\t\tint hlen = LL_RESERVED_SPACE(dev);\n 555:\t\tint tlen = dev-\u003eneeded_tailroom;\n 556:\t\n 557:\t\t/*\n 558:\t\t *\tAllocate a buffer\n 559:\t\t */\n 560:\t\n 561:\t\tskb = alloc_skb(arp_hdr_len(dev) + hlen + tlen, GFP_ATOMIC);\n 562:\t\tif (!skb)\n 563:\t\t\treturn NULL;\n 564:\t\n 565:\t\tskb_reserve(skb, hlen);\n 566:\t\tskb_reset_network_header(skb);\n 567:\t\tskb_put(skb, arp_hdr_len(dev));\n 568:\t\tskb-\u003edev = dev;\n 569:\t\tskb-\u003eprotocol = htons(ETH_P_ARP);\n 570:\t\tif (!src_hw)\n 571:\t\t\tsrc_hw = dev-\u003edev_addr;\n 572:\t\tif (!dest_hw)\n 573:\t\t\tdest_hw = dev-\u003ebroadcast;\n 574:\t\n 575:\t\t/* Fill the device header for the ARP frame.\n 576:\t\t * Note: skb-\u003ehead can be changed.\n 577:\t\t */\n 578:\t\tif (dev_hard_header(skb, dev, ptype, dest_hw, src_hw, skb-\u003elen) \u003c 0)\n 579:\t\t\tgoto out;\n 580:\t\n 581:\t\tarp = arp_hdr(skb);\n 582:\t\t/*\n 583:\t\t * Fill out the arp protocol part.\n 584:\t\t *\n"
}

gemini-3.7-flash

null

null

							input: 28853
							output: 42
							thoughts: 15
						

Here's a summary of my thoughts, as though I'm processing the prompt:

**Analyzing `arp_reduce` in the Context of VXLAN**

Alright, let's dive into this. The prompt is asking me to think through the implications of `arp_reduce` in a VXLAN environment. My immediate focus is on how ARP (Address Resolution Protocol) traffic is handled in this overlay network, and how this particular function is meant to optimize it. I'm already formulating questions in my head: What specific problem is `arp_reduce` trying to solve? Is it related to broadcast domain limitations inherent in VXLAN? Is it about reducing ARP floods within the underlay network? What strategies does it employ? Does it involve ARP proxying, suppression, caching, or something else entirely? The nuances of how this function interacts with VTEPs (VXLAN Tunnel Endpoints) and the control plane, if any, are key. I'll need to consider performance implications, potential trade-offs in terms of convergence time, and any security considerations that might arise from modifying the standard ARP behavior. I will need to delve deeper to find the exact mechanism used by this function. I'm assuming that this is an existing function and not something new, so looking for references to documentation that describes it will be my next step.

{
  "File": "drivers/net/vxlan/vxlan_core.c",
  "FirstLine": 1840,
  "LineCount": 50
}

{
  "Contents": "1840:\t}\n1841:\t\n1842:\tstatic int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n1843:\t{\n1844:\t\tstruct vxlan_dev *vxlan = netdev_priv(dev);\n1845:\t\tstruct arphdr *parp;\n1846:\t\tu8 *arpptr, *sha;\n1847:\t\t__be32 sip, tip;\n1848:\t\tstruct neighbour *n;\n1849:\t\n1850:\t\tif (dev-\u003eflags \u0026 IFF_NOARP)\n1851:\t\t\tgoto out;\n1852:\t\n1853:\t\tif (!pskb_network_may_pull(skb, arp_hdr_len(dev))) {\n1854:\t\t\tdev_dstats_tx_dropped(dev);\n1855:\t\t\tvxlan_vnifilter_count(vxlan, vni, NULL,\n1856:\t\t\t\t\t      VXLAN_VNI_STATS_TX_DROPS, 0);\n1857:\t\t\tgoto out;\n1858:\t\t}\n1859:\t\tparp = arp_hdr(skb);\n1860:\t\n1861:\t\tif ((parp-\u003ear_hrd != htons(ARPHRD_ETHER) \u0026\u0026\n1862:\t\t     parp-\u003ear_hrd != htons(ARPHRD_IEEE802)) ||\n1863:\t\t    parp-\u003ear_pro != htons(ETH_P_IP) ||\n1864:\t\t    parp-\u003ear_op != htons(ARPOP_REQUEST) ||\n1865:\t\t    parp-\u003ear_hln != dev-\u003eaddr_len ||\n1866:\t\t    parp-\u003ear_pln != 4)\n1867:\t\t\tgoto out;\n1868:\t\tarpptr = (u8 *)parp + sizeof(struct arphdr);\n1869:\t\tsha = arpptr;\n1870:\t\tarpptr += dev-\u003eaddr_len;\t/* sha */\n1871:\t\tmemcpy(\u0026sip, arpptr, sizeof(sip));\n1872:\t\tarpptr += sizeof(sip);\n1873:\t\tarpptr += dev-\u003eaddr_len;\t/* tha */\n1874:\t\tmemcpy(\u0026tip, arpptr, sizeof(tip));\n1875:\t\n1876:\t\tif (ipv4_is_loopback(tip) ||\n1877:\t\t    ipv4_is_multicast(tip))\n1878:\t\t\tgoto out;\n1879:\t\n1880:\t\tn = neigh_lookup(\u0026arp_tbl, \u0026tip, dev);\n1881:\t\n1882:\t\tif (n) {\n1883:\t\t\tstruct vxlan_rdst *rdst = NULL;\n1884:\t\t\tu8 ha[ETH_ALEN] __aligned(2);\n1885:\t\t\tstruct vxlan_fdb *f;\n1886:\t\t\tstruct sk_buff\t*reply;\n1887:\t\n1888:\t\t\tif (!(READ_ONCE(n-\u003enud_state) \u0026 NUD_CONNECTED)) {\n1889:\t\t\t\tneigh_release(n);\n"
}

gemini-3.7-flash

null

null

							input: 30023
							output: 32
							thoughts: 486
						

**Worth Fuzzing Analysis: `vxlan_na_create` in VXLAN Proxy Mode**

Okay, let's break this down. My initial assessment is that `vxlan_na_create` is responsible for generating IPv6 Neighbor Advertisement packets within VXLAN, specifically in proxy mode – either through `VXLAN_F_PROXY` or the IPv6 neighbor reduction mechanism. The critical question: is this code path accessible within QEMU?

Given my understanding, VXLAN is a virtual network driver, created using `ip link add type vxlan`. QEMU is perfectly capable of setting up and running VXLAN interfaces, including those with proxy mode enabled. Furthermore, it's straightforward to send IPv6 neighbor solicitation packets, which should trigger `vxlan_na_create`. The change directly touches the core VXLAN driver logic in `drivers/net/vxlan/vxlan_core.c`, so that's definitely a significant area.

Now, let's apply the `WorthFuzzing` criteria.

*   Does it modify reachable core kernel logic, drivers, or architectures? Yes, it's the VXLAN driver, a core networking component.
*   Does the patch consist solely of Documentation/, Kconfig files, or comments? No.
*   Is it purely cosmetic changes like logging or tracepoints? No.
*   Is it merely changes to numerical constants or macros that don't alter execution? No.
*   Is this a code path unreachable in virtualized environments like GCE or QEMU? Absolutely not, VXLAN is a virtual device and is widely used and fuzzed in QEMU.
*   Is it vendor-specific PCIe switch, SmartNIC, or GPU drivers? No.
*   Is it a driver `.remove`, `.shutdown`, or `pci_unregister_driver` teardown callback? No.

Therefore, by process of elimination and expert judgement, this clearly qualifies as `WorthFuzzing = true`.

Next, I need to identify which symbols are modified or are directly calling the modified logic. It looks like `vxlan_na_create` is declared `static`, as is `neigh_reduce`. So I'll need to check the non-static entry points in `vxlan_core.c` and VXLAN's NDO operations to see how this function is actually called.

{
  "Expression": "vxlan_xmit",
  "PathPrefix": "drivers/net/vxlan/"
}

{
  "Output": "drivers/net/vxlan/vxlan_core.c=2319=static int encap_bypass_if_local(struct sk_buff *skb, struct net_device *dev,\n--\ndrivers/net/vxlan/vxlan_core.c-2357-\ndrivers/net/vxlan/vxlan_core.c:2358:void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2359-\t\t    __be32 default_vni, struct vxlan_rdst *rdst, bool did_rsc)\n--\ndrivers/net/vxlan/vxlan_core.c-2663-\ndrivers/net/vxlan/vxlan_core.c:2664:static void vxlan_xmit_nh(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2665-\t\t\t  struct vxlan_fdb *f, __be32 vni, bool did_rsc)\n--\ndrivers/net/vxlan/vxlan_core.c-2680-\tif (likely(do_xmit))\ndrivers/net/vxlan/vxlan_core.c:2681:\t\tvxlan_xmit_one(skb, dev, vni, \u0026nh_rdst, did_rsc);\ndrivers/net/vxlan/vxlan_core.c-2682-\telse\n--\ndrivers/net/vxlan/vxlan_core.c-2693-\ndrivers/net/vxlan/vxlan_core.c:2694:static netdev_tx_t vxlan_xmit_nhid(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2695-\t\t\t\t   u32 nhid, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-2718-\tif (likely(do_xmit))\ndrivers/net/vxlan/vxlan_core.c:2719:\t\tvxlan_xmit_one(skb, dev, vni, \u0026nh_rdst, false);\ndrivers/net/vxlan/vxlan_core.c-2720-\telse\n--\ndrivers/net/vxlan/vxlan_core.c-2738- */\ndrivers/net/vxlan/vxlan_core.c:2739:static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-2740-{\n--\ndrivers/net/vxlan/vxlan_core.c-2760-\t\t\tif (info \u0026\u0026 info-\u003emode \u0026 IP_TUNNEL_INFO_TX)\ndrivers/net/vxlan/vxlan_core.c:2761:\t\t\t\tvxlan_xmit_one(skb, dev, vni, NULL, false);\ndrivers/net/vxlan/vxlan_core.c-2762-\t\t\telse\n--\ndrivers/net/vxlan/vxlan_core.c-2786-\tif (nhid)\ndrivers/net/vxlan/vxlan_core.c:2787:\t\treturn vxlan_xmit_nhid(skb, dev, nhid, vni);\ndrivers/net/vxlan/vxlan_core.c-2788-\n--\ndrivers/net/vxlan/vxlan_core.c-2833-\tif (rcu_access_pointer(f-\u003enh)) {\ndrivers/net/vxlan/vxlan_core.c:2834:\t\tvxlan_xmit_nh(skb, dev, f,\ndrivers/net/vxlan/vxlan_core.c-2835-\t\t\t      (vni ? : vxlan-\u003edefault_dst.remote_vni), did_rsc);\n--\ndrivers/net/vxlan/vxlan_core.c-2845-\t\t\tif (skb1)\ndrivers/net/vxlan/vxlan_core.c:2846:\t\t\t\tvxlan_xmit_one(skb1, dev, vni, rdst, did_rsc);\ndrivers/net/vxlan/vxlan_core.c-2847-\t\t}\ndrivers/net/vxlan/vxlan_core.c-2848-\t\tif (fdst)\ndrivers/net/vxlan/vxlan_core.c:2849:\t\t\tvxlan_xmit_one(skb, dev, vni, fdst, did_rsc);\ndrivers/net/vxlan/vxlan_core.c-2850-\t\telse\n--\ndrivers/net/vxlan/vxlan_core.c=3293=static const struct net_device_ops vxlan_netdev_ether_ops = {\n--\ndrivers/net/vxlan/vxlan_core.c-3297-\t.ndo_stop\t\t= vxlan_stop,\ndrivers/net/vxlan/vxlan_core.c:3298:\t.ndo_start_xmit\t\t= vxlan_xmit,\ndrivers/net/vxlan/vxlan_core.c-3299-\t.ndo_set_rx_mode\t= vxlan_set_multicast_list,\n--\ndrivers/net/vxlan/vxlan_core.c=3316=static const struct net_device_ops vxlan_netdev_raw_ops = {\n--\ndrivers/net/vxlan/vxlan_core.c-3320-\t.ndo_stop\t\t= vxlan_stop,\ndrivers/net/vxlan/vxlan_core.c:3321:\t.ndo_start_xmit\t\t= vxlan_xmit,\ndrivers/net/vxlan/vxlan_core.c-3322-\t.ndo_change_mtu\t\t= vxlan_change_mtu,\n--\ndrivers/net/vxlan/vxlan_mdb.c=1702=netdev_tx_t vxlan_mdb_xmit(struct vxlan_dev *vxlan,\n--\ndrivers/net/vxlan/vxlan_mdb.c-1723-\t\tif (skb1)\ndrivers/net/vxlan/vxlan_mdb.c:1724:\t\t\tvxlan_xmit_one(skb1, vxlan-\u003edev, src_vni,\ndrivers/net/vxlan/vxlan_mdb.c-1725-\t\t\t\t       rcu_dereference(remote-\u003erd), false);\n--\ndrivers/net/vxlan/vxlan_mdb.c-1728-\tif (fremote)\ndrivers/net/vxlan/vxlan_mdb.c:1729:\t\tvxlan_xmit_one(skb, vxlan-\u003edev, src_vni,\ndrivers/net/vxlan/vxlan_mdb.c-1730-\t\t\t       rcu_dereference(fremote-\u003erd), false);\n--\ndrivers/net/vxlan/vxlan_private.h=191=int vxlan_fdb_update(struct vxlan_dev *vxlan,\n--\ndrivers/net/vxlan/vxlan_private.h-196-\t\t     bool swdev_notify, struct netlink_ext_ack *extack);\ndrivers/net/vxlan/vxlan_private.h:197:void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_private.h-198-\t\t    __be32 default_vni, struct vxlan_rdst *rdst, bool did_rsc);\n"
}

gemini-3.7-flash

null

null

							input: 32947
							output: 43
							thoughts: 172
						

**Analyzing VXLAN Neighbor Discovery and Transmission**

Okay, let's dive into this `vxlan_core.c` file. I need to understand the implications of the changes made around `vxlan_na_create` – that's the focal point, isn't it? My primary concern is how these modifications impact neighbor discovery and transmission.

Right, so `neigh_reduce` is calling `vxlan_na_create`. That's the core of the interaction. Also, `vxlan_xmit` appears to be handling ndo_start_xmit, and it also calls `neigh_reduce`. Interesting, interesting. Given the context of the modification, I will check the relationship of the functions with `vxlan_na_create`. 

To get a broader picture, I should probably also zoom out and check which other functions within `vxlan_core.c` are not inlined or static, and therefore possibly more publicly accessible or have a more complex relationship with other parts of the kernel. `vxlan_xmit_one` looks like a good place to start – it's non-static, so there's an external hook there. And then I should consider other potentially significant functions like `vxlan_fdb_update`, `vxlan_fdb_add`, `vxlan_dev_ioctl`, and `vxlan_changelink`, just to be safe. That should give me a good handle on where this change ripples out.

{
  "Expression": "^[a-zA-Z_].*\\(",
  "PathPrefix": "drivers/net/vxlan/vxlan_core.c"
}

{
  "Output": "\nFull output is too long, showing 500 out of 542 lines.\nUse more precise expression if possible.\n\ndrivers/net/vxlan/vxlan_core.c=49=static unsigned short vxlan_port __read_mostly = 8472;\ndrivers/net/vxlan/vxlan_core.c:50:module_param_named(udp_port, vxlan_port, ushort, 0444);\ndrivers/net/vxlan/vxlan_core.c:51:MODULE_PARM_DESC(udp_port, \"Destination UDP port\");\ndrivers/net/vxlan/vxlan_core.c-52-\ndrivers/net/vxlan/vxlan_core.c=53=static bool log_ecn_error = true;\ndrivers/net/vxlan/vxlan_core.c:54:module_param(log_ecn_error, bool, 0644);\ndrivers/net/vxlan/vxlan_core.c:55:MODULE_PARM_DESC(log_ecn_error, \"Log packets received with corrupted ECN\");\ndrivers/net/vxlan/vxlan_core.c-56-\n--\ndrivers/net/vxlan/vxlan_core.c=60=static struct rtnl_link_ops vxlan_link_ops;\ndrivers/net/vxlan/vxlan_core.c-61-\ndrivers/net/vxlan/vxlan_core.c:62:static int vxlan_sock_add(struct vxlan_dev *vxlan);\ndrivers/net/vxlan/vxlan_core.c-63-\ndrivers/net/vxlan/vxlan_core.c:64:static void vxlan_vs_del_dev(struct vxlan_dev *vxlan);\ndrivers/net/vxlan/vxlan_core.c-65-\ndrivers/net/vxlan/vxlan_core.c=66=static const struct rhashtable_params vxlan_fdb_rht_params = {\n--\ndrivers/net/vxlan/vxlan_core.c-72-\ndrivers/net/vxlan/vxlan_core.c:73:static inline bool vxlan_collect_metadata(struct vxlan_sock *vs)\ndrivers/net/vxlan/vxlan_core.c-74-{\n--\ndrivers/net/vxlan/vxlan_core.c-82- */\ndrivers/net/vxlan/vxlan_core.c:83:static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,\ndrivers/net/vxlan/vxlan_core.c-84-\t\t\t\t\t  __be16 port, u32 flags, int ifindex)\n--\ndrivers/net/vxlan/vxlan_core.c-99-\ndrivers/net/vxlan/vxlan_core.c:100:static struct vxlan_dev *vxlan_vs_find_vni(struct vxlan_sock *vs,\ndrivers/net/vxlan/vxlan_core.c-101-\t\t\t\t\t   int ifindex, __be32 vni,\n--\ndrivers/net/vxlan/vxlan_core.c-140-/* Look up VNI in a per net namespace table */\ndrivers/net/vxlan/vxlan_core.c:141:static struct vxlan_dev *vxlan_find_vni(struct net *net, int ifindex,\ndrivers/net/vxlan/vxlan_core.c-142-\t\t\t\t\t__be32 vni, sa_family_t family,\n--\ndrivers/net/vxlan/vxlan_core.c-154-/* Fill in neighbour message in skbuff. */\ndrivers/net/vxlan/vxlan_core.c:155:static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-156-\t\t\t  const struct vxlan_fdb *fdb,\n--\ndrivers/net/vxlan/vxlan_core.c-250-\ndrivers/net/vxlan/vxlan_core.c:251:static inline size_t vxlan_nlmsg_size(void)\ndrivers/net/vxlan/vxlan_core.c-252-{\n--\ndrivers/net/vxlan/vxlan_core.c-262-\ndrivers/net/vxlan/vxlan_core.c:263:static void __vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,\ndrivers/net/vxlan/vxlan_core.c-264-\t\t\t       struct vxlan_rdst *rd, int type)\n--\ndrivers/net/vxlan/vxlan_core.c-287-\ndrivers/net/vxlan/vxlan_core.c:288:static void vxlan_fdb_switchdev_notifier_info(const struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-289-\t\t\t    const struct vxlan_fdb *fdb,\n--\ndrivers/net/vxlan/vxlan_core.c-305-\ndrivers/net/vxlan/vxlan_core.c:306:static int vxlan_fdb_switchdev_call_notifiers(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-307-\t\t\t\t\t      struct vxlan_fdb *fdb,\n--\ndrivers/net/vxlan/vxlan_core.c-326-\ndrivers/net/vxlan/vxlan_core.c:327:static int vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,\ndrivers/net/vxlan/vxlan_core.c-328-\t\t\t    struct vxlan_rdst *rd, int type, bool swdev_notify,\n--\ndrivers/net/vxlan/vxlan_core.c-351-\ndrivers/net/vxlan/vxlan_core.c:352:static void vxlan_ip_miss(struct net_device *dev, union vxlan_addr *ipa)\ndrivers/net/vxlan/vxlan_core.c-353-{\n--\ndrivers/net/vxlan/vxlan_core.c-365-\ndrivers/net/vxlan/vxlan_core.c:366:static void vxlan_fdb_miss(struct vxlan_dev *vxlan, const u8 eth_addr[ETH_ALEN])\ndrivers/net/vxlan/vxlan_core.c-367-{\n--\ndrivers/net/vxlan/vxlan_core.c-378-/* Look up Ethernet address in forwarding table */\ndrivers/net/vxlan/vxlan_core.c:379:static struct vxlan_fdb *vxlan_find_mac_rcu(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-380-\t\t\t\t\t    const u8 *mac, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-394-\ndrivers/net/vxlan/vxlan_core.c:395:static struct vxlan_fdb *vxlan_find_mac_tx(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-396-\t\t\t\t\t   const u8 *mac, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-410-\ndrivers/net/vxlan/vxlan_core.c:411:static struct vxlan_fdb *vxlan_find_mac(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-412-\t\t\t\t\tconst u8 *mac, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-425-/* caller should hold vxlan-\u003ehash_lock */\ndrivers/net/vxlan/vxlan_core.c:426:static struct vxlan_rdst *vxlan_fdb_find_rdst(struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-427-\t\t\t\t\t      union vxlan_addr *ip, __be16 port,\n--\ndrivers/net/vxlan/vxlan_core.c-442-\ndrivers/net/vxlan/vxlan_core.c:443:int vxlan_fdb_find_uc(struct net_device *dev, const u8 *mac, __be32 vni,\ndrivers/net/vxlan/vxlan_core.c-444-\t\t      struct switchdev_notifier_vxlan_fdb_info *fdb_info)\n--\ndrivers/net/vxlan/vxlan_core.c-473-}\ndrivers/net/vxlan/vxlan_core.c:474:EXPORT_SYMBOL_GPL(vxlan_fdb_find_uc);\ndrivers/net/vxlan/vxlan_core.c-475-\ndrivers/net/vxlan/vxlan_core.c:476:static int vxlan_fdb_notify_one(struct notifier_block *nb,\ndrivers/net/vxlan/vxlan_core.c-477-\t\t\t\tconst struct vxlan_dev *vxlan,\n--\ndrivers/net/vxlan/vxlan_core.c-490-\ndrivers/net/vxlan/vxlan_core.c:491:int vxlan_fdb_replay(const struct net_device *dev, __be32 vni,\ndrivers/net/vxlan/vxlan_core.c-492-\t\t     struct notifier_block *nb,\n--\ndrivers/net/vxlan/vxlan_core.c-521-}\ndrivers/net/vxlan/vxlan_core.c:522:EXPORT_SYMBOL_GPL(vxlan_fdb_replay);\ndrivers/net/vxlan/vxlan_core.c-523-\ndrivers/net/vxlan/vxlan_core.c:524:void vxlan_fdb_clear_offload(const struct net_device *dev, __be32 vni)\ndrivers/net/vxlan/vxlan_core.c-525-{\n--\ndrivers/net/vxlan/vxlan_core.c-543-}\ndrivers/net/vxlan/vxlan_core.c:544:EXPORT_SYMBOL_GPL(vxlan_fdb_clear_offload);\ndrivers/net/vxlan/vxlan_core.c-545-\ndrivers/net/vxlan/vxlan_core.c-546-/* Replace destination of unicast mac */\ndrivers/net/vxlan/vxlan_core.c:547:static int vxlan_fdb_replace(struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-548-\t\t\t     union vxlan_addr *ip, __be16 port, __be32 vni,\n--\ndrivers/net/vxlan/vxlan_core.c-571-/* Add/update destinations for multicast */\ndrivers/net/vxlan/vxlan_core.c:572:static int vxlan_fdb_append(struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-573-\t\t\t    union vxlan_addr *ip, __be16 port, __be32 vni,\n--\ndrivers/net/vxlan/vxlan_core.c-602-\ndrivers/net/vxlan/vxlan_core.c:603:static bool vxlan_parse_gpe_proto(const struct vxlanhdr *hdr, __be16 *protocol)\ndrivers/net/vxlan/vxlan_core.c-604-{\n--\ndrivers/net/vxlan/vxlan_core.c-628-\ndrivers/net/vxlan/vxlan_core.c:629:static struct vxlanhdr *vxlan_gro_remcsum(struct sk_buff *skb,\ndrivers/net/vxlan/vxlan_core.c-630-\t\t\t\t\t  unsigned int off,\n--\ndrivers/net/vxlan/vxlan_core.c-654-\ndrivers/net/vxlan/vxlan_core.c:655:static struct vxlanhdr *vxlan_gro_prepare_receive(struct sock *sk,\ndrivers/net/vxlan/vxlan_core.c-656-\t\t\t\t\t\t  struct list_head *head,\n--\ndrivers/net/vxlan/vxlan_core.c-708-\ndrivers/net/vxlan/vxlan_core.c:709:static struct sk_buff *vxlan_gro_receive(struct sock *sk,\ndrivers/net/vxlan/vxlan_core.c-710-\t\t\t\t\t struct list_head *head,\n--\ndrivers/net/vxlan/vxlan_core.c-724-\ndrivers/net/vxlan/vxlan_core.c:725:static struct sk_buff *vxlan_gpe_gro_receive(struct sock *sk,\ndrivers/net/vxlan/vxlan_core.c-726-\t\t\t\t\t     struct list_head *head,\n--\ndrivers/net/vxlan/vxlan_core.c-750-\ndrivers/net/vxlan/vxlan_core.c:751:static int vxlan_gro_complete(struct sock *sk, struct sk_buff *skb, int nhoff)\ndrivers/net/vxlan/vxlan_core.c-752-{\n--\ndrivers/net/vxlan/vxlan_core.c-758-\ndrivers/net/vxlan/vxlan_core.c:759:static int vxlan_gpe_gro_complete(struct sock *sk, struct sk_buff *skb, int nhoff)\ndrivers/net/vxlan/vxlan_core.c-760-{\n--\ndrivers/net/vxlan/vxlan_core.c-773-\ndrivers/net/vxlan/vxlan_core.c:774:static struct vxlan_fdb *vxlan_fdb_alloc(struct vxlan_dev *vxlan, const u8 *mac,\ndrivers/net/vxlan/vxlan_core.c-775-\t\t\t\t\t __u16 state, __be32 src_vni,\n--\ndrivers/net/vxlan/vxlan_core.c-796-\ndrivers/net/vxlan/vxlan_core.c:797:static int vxlan_fdb_nh_update(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,\ndrivers/net/vxlan/vxlan_core.c-798-\t\t\t       u32 nhid, struct netlink_ext_ack *extack)\n--\ndrivers/net/vxlan/vxlan_core.c-858-\ndrivers/net/vxlan/vxlan_core.c:859:int vxlan_fdb_create(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-860-\t\t     const u8 *mac, union vxlan_addr *ip,\n--\ndrivers/net/vxlan/vxlan_core.c-911-\ndrivers/net/vxlan/vxlan_core.c:912:static void __vxlan_fdb_free(struct vxlan_fdb *f)\ndrivers/net/vxlan/vxlan_core.c-913-{\n--\ndrivers/net/vxlan/vxlan_core.c-930-\ndrivers/net/vxlan/vxlan_core.c:931:static void vxlan_fdb_free(struct rcu_head *head)\ndrivers/net/vxlan/vxlan_core.c-932-{\n--\ndrivers/net/vxlan/vxlan_core.c-937-\ndrivers/net/vxlan/vxlan_core.c:938:static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-939-\t\t\t      bool do_notify, bool swdev_notify)\n--\ndrivers/net/vxlan/vxlan_core.c-962-\ndrivers/net/vxlan/vxlan_core.c:963:static void vxlan_dst_free(struct rcu_head *head)\ndrivers/net/vxlan/vxlan_core.c-964-{\n--\ndrivers/net/vxlan/vxlan_core.c-970-\ndrivers/net/vxlan/vxlan_core.c:971:static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-972-\t\t\t\t     union vxlan_addr *ip,\n--\ndrivers/net/vxlan/vxlan_core.c-1069-\ndrivers/net/vxlan/vxlan_core.c:1070:static int vxlan_fdb_update_create(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-1071-\t\t\t\t   const u8 *mac, union vxlan_addr *ip,\n--\ndrivers/net/vxlan/vxlan_core.c-1105-/* Add new entry to forwarding table -- assumes lock held */\ndrivers/net/vxlan/vxlan_core.c:1106:int vxlan_fdb_update(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-1107-\t\t     const u8 *mac, union vxlan_addr *ip,\n--\ndrivers/net/vxlan/vxlan_core.c-1137-\ndrivers/net/vxlan/vxlan_core.c:1138:static void vxlan_fdb_dst_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-1139-\t\t\t\t  struct vxlan_rdst *rd, bool swdev_notify)\n--\ndrivers/net/vxlan/vxlan_core.c-1145-\ndrivers/net/vxlan/vxlan_core.c:1146:static int vxlan_fdb_parse(struct nlattr *tb[], struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-1147-\t\t\t   union vxlan_addr *ip, __be16 *port, __be32 *src_vni,\n--\ndrivers/net/vxlan/vxlan_core.c-1232-/* Add static entry (via netlink) */\ndrivers/net/vxlan/vxlan_core.c:1233:static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],\ndrivers/net/vxlan/vxlan_core.c-1234-\t\t\t struct net_device *dev,\n--\ndrivers/net/vxlan/vxlan_core.c-1275-\ndrivers/net/vxlan/vxlan_core.c:1276:int __vxlan_fdb_delete(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-1277-\t\t       const unsigned char *addr, union vxlan_addr ip,\n--\ndrivers/net/vxlan/vxlan_core.c-1309-/* Delete entry (via netlink) */\ndrivers/net/vxlan/vxlan_core.c:1310:static int vxlan_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],\ndrivers/net/vxlan/vxlan_core.c-1311-\t\t\t    struct net_device *dev,\n--\ndrivers/net/vxlan/vxlan_core.c-1338-/* Dump forwarding table */\ndrivers/net/vxlan/vxlan_core.c:1339:static int vxlan_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,\ndrivers/net/vxlan/vxlan_core.c-1340-\t\t\t  struct net_device *dev,\n--\ndrivers/net/vxlan/vxlan_core.c-1388-\ndrivers/net/vxlan/vxlan_core.c:1389:static int vxlan_fdb_get(struct sk_buff *skb,\ndrivers/net/vxlan/vxlan_core.c-1390-\t\t\t struct nlattr *tb[],\n--\ndrivers/net/vxlan/vxlan_core.c-1424- */\ndrivers/net/vxlan/vxlan_core.c:1425:static enum skb_drop_reason vxlan_snoop(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-1426-\t\t\t\t\tunion vxlan_addr *src_ip,\n--\ndrivers/net/vxlan/vxlan_core.c-1489-\ndrivers/net/vxlan/vxlan_core.c:1490:static bool __vxlan_sock_release_prep(struct vxlan_sock *vs)\ndrivers/net/vxlan/vxlan_core.c-1491-{\n--\ndrivers/net/vxlan/vxlan_core.c-1507-\ndrivers/net/vxlan/vxlan_core.c:1508:static void vxlan_sock_release(struct vxlan_dev *vxlan)\ndrivers/net/vxlan/vxlan_core.c-1509-{\n--\ndrivers/net/vxlan/vxlan_core.c-1536-\ndrivers/net/vxlan/vxlan_core.c:1537:static enum skb_drop_reason vxlan_remcsum(struct sk_buff *skb, u32 vxflags)\ndrivers/net/vxlan/vxlan_core.c-1538-{\n--\ndrivers/net/vxlan/vxlan_core.c-1557-\ndrivers/net/vxlan/vxlan_core.c:1558:static void vxlan_parse_gbp_hdr(struct sk_buff *skb, u32 vxflags,\ndrivers/net/vxlan/vxlan_core.c-1559-\t\t\t\tstruct vxlan_metadata *md)\n--\ndrivers/net/vxlan/vxlan_core.c-1588-\ndrivers/net/vxlan/vxlan_core.c:1589:static enum skb_drop_reason vxlan_set_mac(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-1590-\t\t\t\t\t  struct vxlan_sock *vs,\n--\ndrivers/net/vxlan/vxlan_core.c-1621-\ndrivers/net/vxlan/vxlan_core.c:1622:static bool vxlan_ecn_decapsulate(struct vxlan_sock *vs, void *oiph,\ndrivers/net/vxlan/vxlan_core.c-1623-\t\t\t\t  struct sk_buff *skb)\n--\ndrivers/net/vxlan/vxlan_core.c-1645-\ndrivers/net/vxlan/vxlan_core.c:1646:static int vxlan_rcv(struct sock *sk, struct sk_buff *skb)\ndrivers/net/vxlan/vxlan_core.c-1647-{\n--\ndrivers/net/vxlan/vxlan_core.c-1814-\ndrivers/net/vxlan/vxlan_core.c:1815:static int vxlan_err_lookup(struct sock *sk, struct sk_buff *skb)\ndrivers/net/vxlan/vxlan_core.c-1816-{\n--\ndrivers/net/vxlan/vxlan_core.c-1841-\ndrivers/net/vxlan/vxlan_core.c:1842:static int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\ndrivers/net/vxlan/vxlan_core.c-1843-{\n--\ndrivers/net/vxlan/vxlan_core.c-1939-#if IS_ENABLED(CONFIG_IPV6)\ndrivers/net/vxlan/vxlan_core.c:1940:static struct sk_buff *vxlan_na_create(struct sk_buff *request,\ndrivers/net/vxlan/vxlan_core.c-1941-\t\t\t\t       struct neighbour *n, u8 *ha,\n--\ndrivers/net/vxlan/vxlan_core.c-2035-\ndrivers/net/vxlan/vxlan_core.c:2036:static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\ndrivers/net/vxlan/vxlan_core.c-2037-{\n--\ndrivers/net/vxlan/vxlan_core.c-2107-\ndrivers/net/vxlan/vxlan_core.c:2108:static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)\ndrivers/net/vxlan/vxlan_core.c-2109-{\n--\ndrivers/net/vxlan/vxlan_core.c-2190-\ndrivers/net/vxlan/vxlan_core.c:2191:static int vxlan_build_gpe_hdr(struct vxlanhdr *vxh, __be16 protocol)\ndrivers/net/vxlan/vxlan_core.c-2192-{\n--\ndrivers/net/vxlan/vxlan_core.c-2201-\ndrivers/net/vxlan/vxlan_core.c:2202:static int vxlan_build_skb(struct sk_buff *skb, struct dst_entry *dst,\ndrivers/net/vxlan/vxlan_core.c-2203-\t\t\t   int iphdr_len, __be32 vni,\n--\ndrivers/net/vxlan/vxlan_core.c-2268-/* Bypass encapsulation if the destination is local */\ndrivers/net/vxlan/vxlan_core.c:2269:static void vxlan_encap_bypass(struct sk_buff *skb, struct vxlan_dev *src_vxlan,\ndrivers/net/vxlan/vxlan_core.c-2270-\t\t\t       struct vxlan_dev *dst_vxlan, __be32 vni,\n--\ndrivers/net/vxlan/vxlan_core.c-2318-\ndrivers/net/vxlan/vxlan_core.c:2319:static int encap_bypass_if_local(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2320-\t\t\t\t struct vxlan_dev *vxlan,\n--\ndrivers/net/vxlan/vxlan_core.c-2357-\ndrivers/net/vxlan/vxlan_core.c:2358:void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2359-\t\t    __be32 default_vni, struct vxlan_rdst *rdst, bool did_rsc)\n--\ndrivers/net/vxlan/vxlan_core.c-2663-\ndrivers/net/vxlan/vxlan_core.c:2664:static void vxlan_xmit_nh(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2665-\t\t\t  struct vxlan_fdb *f, __be32 vni, bool did_rsc)\n--\ndrivers/net/vxlan/vxlan_core.c-2693-\ndrivers/net/vxlan/vxlan_core.c:2694:static netdev_tx_t vxlan_xmit_nhid(struct sk_buff *skb, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-2695-\t\t\t\t   u32 nhid, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-2738- */\ndrivers/net/vxlan/vxlan_core.c:2739:static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-2740-{\n--\ndrivers/net/vxlan/vxlan_core.c-2859-/* Walk the forwarding table and purge stale entries */\ndrivers/net/vxlan/vxlan_core.c:2860:static void vxlan_cleanup(struct timer_list *t)\ndrivers/net/vxlan/vxlan_core.c-2861-{\n--\ndrivers/net/vxlan/vxlan_core.c-2897-\ndrivers/net/vxlan/vxlan_core.c:2898:static void vxlan_vs_del_dev(struct vxlan_dev *vxlan)\ndrivers/net/vxlan/vxlan_core.c-2899-{\n--\ndrivers/net/vxlan/vxlan_core.c-2907-\ndrivers/net/vxlan/vxlan_core.c:2908:static void vxlan_vs_add_dev(struct vxlan_sock *vs, struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-2909-\t\t\t     struct vxlan_dev_node *node)\n--\ndrivers/net/vxlan/vxlan_core.c-2919-/* Setup stats when device is created */\ndrivers/net/vxlan/vxlan_core.c:2920:static int vxlan_init(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-2921-{\n--\ndrivers/net/vxlan/vxlan_core.c-2955-\ndrivers/net/vxlan/vxlan_core.c:2956:static void vxlan_uninit(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-2957-{\n--\ndrivers/net/vxlan/vxlan_core.c-2970-/* Start ageing timer and join group when device is brought up */\ndrivers/net/vxlan/vxlan_core.c:2971:static int vxlan_open(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-2972-{\n--\ndrivers/net/vxlan/vxlan_core.c=2992=struct vxlan_fdb_flush_desc {\n--\ndrivers/net/vxlan/vxlan_core.c-3004-\ndrivers/net/vxlan/vxlan_core.c:3005:static bool vxlan_fdb_is_default_entry(const struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-3006-\t\t\t\t       const struct vxlan_dev *vxlan)\n--\ndrivers/net/vxlan/vxlan_core.c-3011-\ndrivers/net/vxlan/vxlan_core.c:3012:static bool vxlan_fdb_nhid_matches(const struct vxlan_fdb *f, u32 nhid)\ndrivers/net/vxlan/vxlan_core.c-3013-{\n--\ndrivers/net/vxlan/vxlan_core.c-3018-\ndrivers/net/vxlan/vxlan_core.c:3019:static bool vxlan_fdb_flush_matches(const struct vxlan_fdb *f,\ndrivers/net/vxlan/vxlan_core.c-3020-\t\t\t\t    const struct vxlan_dev *vxlan,\n--\ndrivers/net/vxlan/vxlan_core.c=3041=static bool\ndrivers/net/vxlan/vxlan_core.c:3042:vxlan_fdb_flush_should_match_remotes(const struct vxlan_fdb_flush_desc *desc)\ndrivers/net/vxlan/vxlan_core.c-3043-{\n--\ndrivers/net/vxlan/vxlan_core.c=3047=static bool\ndrivers/net/vxlan/vxlan_core.c:3048:vxlan_fdb_flush_remote_matches(const struct vxlan_fdb_flush_desc *desc,\ndrivers/net/vxlan/vxlan_core.c-3049-\t\t\t       const struct vxlan_rdst *rd)\n--\ndrivers/net/vxlan/vxlan_core.c=3064=static void\ndrivers/net/vxlan/vxlan_core.c:3065:vxlan_fdb_flush_match_remotes(struct vxlan_fdb *f, struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-3066-\t\t\t      const struct vxlan_fdb_flush_desc *desc,\n--\ndrivers/net/vxlan/vxlan_core.c-3084-/* Purge the forwarding table */\ndrivers/net/vxlan/vxlan_core.c:3085:static void vxlan_flush(struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-3086-\t\t\tconst struct vxlan_fdb_flush_desc *desc)\n--\ndrivers/net/vxlan/vxlan_core.c=3117=static const struct nla_policy vxlan_del_bulk_policy[NDA_MAX + 1] = {\n--\ndrivers/net/vxlan/vxlan_core.c-3132-\ndrivers/net/vxlan/vxlan_core.c:3133:static int vxlan_fdb_delete_bulk(struct nlmsghdr *nlh, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-3134-\t\t\t\t struct netlink_ext_ack *extack)\n--\ndrivers/net/vxlan/vxlan_core.c-3197-/* Cleanup timer and forwarding table on shutdown */\ndrivers/net/vxlan/vxlan_core.c:3198:static int vxlan_stop(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3199-{\n--\ndrivers/net/vxlan/vxlan_core.c-3218-/* Stub, nothing needs to be done. */\ndrivers/net/vxlan/vxlan_core.c:3219:static void vxlan_set_multicast_list(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3220-{\n--\ndrivers/net/vxlan/vxlan_core.c-3222-\ndrivers/net/vxlan/vxlan_core.c:3223:static int vxlan_change_mtu(struct net_device *dev, int new_mtu)\ndrivers/net/vxlan/vxlan_core.c-3224-{\n--\ndrivers/net/vxlan/vxlan_core.c-3242-\ndrivers/net/vxlan/vxlan_core.c:3243:static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)\ndrivers/net/vxlan/vxlan_core.c-3244-{\n--\ndrivers/net/vxlan/vxlan_core.c=3327=static const struct device_type vxlan_type = {\n--\ndrivers/net/vxlan/vxlan_core.c-3334- */\ndrivers/net/vxlan/vxlan_core.c:3335:static void vxlan_offload_rx_ports(struct net_device *dev, bool push)\ndrivers/net/vxlan/vxlan_core.c-3336-{\n--\ndrivers/net/vxlan/vxlan_core.c-3361-/* Initialize the device structure. */\ndrivers/net/vxlan/vxlan_core.c:3362:static void vxlan_setup(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3363-{\n--\ndrivers/net/vxlan/vxlan_core.c-3409-\ndrivers/net/vxlan/vxlan_core.c:3410:static void vxlan_ether_setup(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3411-{\n--\ndrivers/net/vxlan/vxlan_core.c-3416-\ndrivers/net/vxlan/vxlan_core.c:3417:static void vxlan_raw_setup(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3418-{\n--\ndrivers/net/vxlan/vxlan_core.c=3427=static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = {\n--\ndrivers/net/vxlan/vxlan_core.c-3464-\ndrivers/net/vxlan/vxlan_core.c:3465:static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[],\ndrivers/net/vxlan/vxlan_core.c-3466-\t\t\t  struct netlink_ext_ack *extack)\n--\ndrivers/net/vxlan/vxlan_core.c-3531-\ndrivers/net/vxlan/vxlan_core.c:3532:static void vxlan_get_drvinfo(struct net_device *netdev,\ndrivers/net/vxlan/vxlan_core.c-3533-\t\t\t      struct ethtool_drvinfo *drvinfo)\n--\ndrivers/net/vxlan/vxlan_core.c-3538-\ndrivers/net/vxlan/vxlan_core.c:3539:static int vxlan_get_link_ksettings(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-3540-\t\t\t\t    struct ethtool_link_ksettings *cmd)\n--\ndrivers/net/vxlan/vxlan_core.c=3558=static const struct ethtool_ops vxlan_ethtool_ops = {\n--\ndrivers/net/vxlan/vxlan_core.c-3563-\ndrivers/net/vxlan/vxlan_core.c:3564:static struct sock *vxlan_create_sock(struct net *net, bool ipv6,\ndrivers/net/vxlan/vxlan_core.c-3565-\t\t\t\t      __be16 port, u32 flags, int ifindex)\n--\ndrivers/net/vxlan/vxlan_core.c-3594-/* Create new listen socket if needed */\ndrivers/net/vxlan/vxlan_core.c:3595:static struct vxlan_sock *vxlan_socket_create(struct net *net, bool ipv6,\ndrivers/net/vxlan/vxlan_core.c-3596-\t\t\t\t\t      __be16 port, u32 flags,\n--\ndrivers/net/vxlan/vxlan_core.c-3648-\ndrivers/net/vxlan/vxlan_core.c:3649:static int __vxlan_sock_add(struct vxlan_dev *vxlan, bool ipv6)\ndrivers/net/vxlan/vxlan_core.c-3650-{\n--\ndrivers/net/vxlan/vxlan_core.c-3697-\ndrivers/net/vxlan/vxlan_core.c:3698:static int vxlan_sock_add(struct vxlan_dev *vxlan)\ndrivers/net/vxlan/vxlan_core.c-3699-{\n--\ndrivers/net/vxlan/vxlan_core.c-3720-\ndrivers/net/vxlan/vxlan_core.c:3721:int vxlan_vni_in_use(struct net *src_net, struct vxlan_dev *vxlan,\ndrivers/net/vxlan/vxlan_core.c-3722-\t\t     struct vxlan_config *conf, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-3751-\ndrivers/net/vxlan/vxlan_core.c:3752:static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf,\ndrivers/net/vxlan/vxlan_core.c-3753-\t\t\t\t struct net_device **lower,\n--\ndrivers/net/vxlan/vxlan_core.c-3903-\ndrivers/net/vxlan/vxlan_core.c:3904:static void vxlan_config_apply(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-3905-\t\t\t       struct vxlan_config *conf,\n--\ndrivers/net/vxlan/vxlan_core.c-3960-\ndrivers/net/vxlan/vxlan_core.c:3961:static int vxlan_dev_configure(struct net *src_net, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-3962-\t\t\t       struct vxlan_config *conf,\n--\ndrivers/net/vxlan/vxlan_core.c-3977-\ndrivers/net/vxlan/vxlan_core.c:3978:static int vxlan_dev_create(struct net *net, struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-3979-\t\t\t    struct vxlan_config *conf,\n--\ndrivers/net/vxlan/vxlan_core.c-4046-/* Set/clear flags based on attribute */\ndrivers/net/vxlan/vxlan_core.c:4047:static int vxlan_nl2flag(struct vxlan_config *conf, struct nlattr *tb[],\ndrivers/net/vxlan/vxlan_core.c-4048-\t\t\t  int attrtype, unsigned long mask, bool changelink,\n--\ndrivers/net/vxlan/vxlan_core.c-4073-\ndrivers/net/vxlan/vxlan_core.c:4074:static int vxlan_nl2conf(struct nlattr *tb[], struct nlattr *data[],\ndrivers/net/vxlan/vxlan_core.c-4075-\t\t\t struct net_device *dev, struct vxlan_config *conf,\n--\ndrivers/net/vxlan/vxlan_core.c-4413-\ndrivers/net/vxlan/vxlan_core.c:4414:static int vxlan_newlink(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-4415-\t\t\t struct rtnl_newlink_params *params,\n--\ndrivers/net/vxlan/vxlan_core.c-4430-\ndrivers/net/vxlan/vxlan_core.c:4431:static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[],\ndrivers/net/vxlan/vxlan_core.c-4432-\t\t\t    struct nlattr *data[],\n--\ndrivers/net/vxlan/vxlan_core.c-4528-\ndrivers/net/vxlan/vxlan_core.c:4529:static void vxlan_dellink(struct net_device *dev, struct list_head *head)\ndrivers/net/vxlan/vxlan_core.c-4530-{\n--\ndrivers/net/vxlan/vxlan_core.c-4541-\ndrivers/net/vxlan/vxlan_core.c:4542:static size_t vxlan_get_size(const struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-4543-{\n--\ndrivers/net/vxlan/vxlan_core.c-4579-\ndrivers/net/vxlan/vxlan_core.c:4580:static int vxlan_fill_info(struct sk_buff *skb, const struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-4581-{\n--\ndrivers/net/vxlan/vxlan_core.c-4689-\ndrivers/net/vxlan/vxlan_core.c:4690:static struct net *vxlan_get_link_net(const struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-4691-{\n--\ndrivers/net/vxlan/vxlan_core.c=4697=static struct rtnl_link_ops vxlan_link_ops __read_mostly = {\n--\ndrivers/net/vxlan/vxlan_core.c-4711-\ndrivers/net/vxlan/vxlan_core.c:4712:static void vxlan_handle_lowerdev_unregister(struct vxlan_net *vn,\ndrivers/net/vxlan/vxlan_core.c-4713-\t\t\t\t\t     struct net_device *dev)\n--\ndrivers/net/vxlan/vxlan_core.c-4733-\ndrivers/net/vxlan/vxlan_core.c:4734:static int vxlan_netdevice_event(struct notifier_block *unused,\ndrivers/net/vxlan/vxlan_core.c-4735-\t\t\t\t unsigned long event, void *ptr)\n--\ndrivers/net/vxlan/vxlan_core.c=4754=static void\ndrivers/net/vxlan/vxlan_core.c:4755:vxlan_fdb_offloaded_set(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-4756-\t\t\tstruct switchdev_notifier_vxlan_fdb_info *fdb_info)\n--\ndrivers/net/vxlan/vxlan_core.c=4781=static int\ndrivers/net/vxlan/vxlan_core.c:4782:vxlan_fdb_external_learn_add(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-4783-\t\t\t     struct switchdev_notifier_vxlan_fdb_info *fdb_info)\n--\ndrivers/net/vxlan/vxlan_core.c=4806=static int\ndrivers/net/vxlan/vxlan_core.c:4807:vxlan_fdb_external_learn_del(struct net_device *dev,\ndrivers/net/vxlan/vxlan_core.c-4808-\t\t\t     struct switchdev_notifier_vxlan_fdb_info *fdb_info)\n--\ndrivers/net/vxlan/vxlan_core.c-4832-\ndrivers/net/vxlan/vxlan_core.c:4833:static int vxlan_switchdev_event(struct notifier_block *unused,\ndrivers/net/vxlan/vxlan_core.c-4834-\t\t\t\t unsigned long event, void *ptr)\n--\ndrivers/net/vxlan/vxlan_core.c=4869=static struct notifier_block vxlan_switchdev_notifier_block __read_mostly = {\n--\ndrivers/net/vxlan/vxlan_core.c-4872-\ndrivers/net/vxlan/vxlan_core.c:4873:static void vxlan_fdb_nh_flush(struct nexthop *nh)\n\n"
}

gemini-3.7-flash

null

null

							input: 45332
							output: 109
							thoughts: 439
						

**Analyzing VXLAN and IPv6 Configuration Dependencies**

Okay, let's break this down. First, I need to verify the Kconfig dependencies for VXLAN. Looking at `drivers/net/Kconfig`, it's clear that `VXLAN` depends on `INET` and selects both `NET_UDP_TUNNEL` and `GRO_CELLS`. Good, standard stuff.

Now, I see that the `vxlan_na_create` function, critical here, is guarded by `#if IS_ENABLED(CONFIG_IPV6)` in `drivers/net/vxlan/vxlan_core.c`.  Therefore, enabling the IPv6 Neighbor Advertisement creation path requires both `IPV6` and `VXLAN` to be enabled, in addition to `INET`. Yup, `IPV6` is indeed a configuration option, so we're good there.

I need to nail down the affected symbols. I'm focusing on `vxlan_xmit`, because that appears to be the packet transmit handler, and I can see how it routes through `neigh_reduce` and then on to `vxlan_na_create`. Also want to remember `vxlan_xmit_one`. Perhaps I also should note `vxlan_fdb_create`, and `vxlan_rcv`.

Alright, let's quickly double-check the required configurations: `INET`, `IPV6`, and `VXLAN`. Make sure I haven't missed anything obvious. Confirmed. `VXLAN` needs `INET` and selects `NET_UDP_TUNNEL` and `GRO_CELLS`. So that solidifies `VXLAN`, `INET`, and `IPV6`.

Now, I'm ready to craft the `set-results` parameters.

*   `WorthFuzzing`: Definitely true.
*   `Reasoning`: This patch modifies headroom calculations in `vxlan_na_create()` within the VXLAN driver to ensure reserved space matches allocated headroom for IPv6 neighbor advertisements. This is in core virtual networking code, which is reachable in virtualized environments.
*   `EnableConfigs`: `["VXLAN", "INET", "IPV6"]` – that should be comprehensive.
*   `FocusSymbols`: I'll use `["vxlan_xmit", "vxlan_xmit_one"]`. I could also consider adding `vxlan_rcv`, but I'll stick with these for now, and keep the others in mind.

A quick final sanity check... Yup, looks sound. Time to proceed.

{
  "EnableConfigs": [
    "VXLAN",
    "INET",
    "IPV6"
  ],
  "FocusSymbols": [
    "vxlan_xmit",
    "vxlan_xmit_one"
  ],
  "Reasoning": "The patch fixes the headroom calculation and reservation in vxlan_na_create() when constructing IPv6 Neighbor Advertisement packets in the VXLAN driver. This virtual networking code path is reachable in standard virtualized environments with VXLAN proxy mode enabled.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "VXLAN",
    "INET",
    "IPV6"
  ],
  "FocusSymbols": [
    "vxlan_xmit",
    "vxlan_xmit_one"
  ],
  "Reasoning": "The patch fixes the headroom calculation and reservation in vxlan_na_create() when constructing IPv6 Neighbor Advertisement packets in the VXLAN driver. This virtual networking code path is reachable in standard virtualized environments with VXLAN proxy mode enabled.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

core

null

{
  "KMSANReasoning": "The patch performs a minor refactoring in `vxlan_na_create()` within `drivers/net/vxlan/vxlan_core.c`. It caches `LL_RESERVED_SPACE(dev)` in a local variable `headroom` and reuses it for both the allocation size calculation and `skb_reserve(reply, headroom)`. Because `dev` is initialized as `request-\u003edev`, this change introduces no change in runtime values, memory layout, buffer allocations, or data copying. There are no uninitialized variables, structure padding leaks, or uninitialized memory reads introduced or exposed. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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.

For your convenience, here is the diff of the changes:
commit a7737988d73d5570e13e87601d4454f660a5fbb6
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 31 06:37:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 459f19f7071e5..e5a92d30113c6 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -1947,13 +1947,15 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,
 	struct ipv6hdr *pip6;
 	u8 *daddr;
 	int na_olen = 8; /* opt hdr + ETH_ALEN for target */
+	int headroom;
 	int ns_olen;
 	int i, len;
 
 	if (dev == NULL || !pskb_may_pull(request, request->len))
 		return NULL;
 
-	len = LL_RESERVED_SPACE(dev) + sizeof(struct ipv6hdr) +
+	headroom = LL_RESERVED_SPACE(dev);
+	len = headroom + sizeof(struct ipv6hdr) +
 		sizeof(*na) + na_olen + dev->needed_tailroom;
 	reply = alloc_skb(len, GFP_ATOMIC);
 	if (reply == NULL)
@@ -1961,7 +1963,7 @@ static struct sk_buff *vxlan_na_create(struct sk_buff *request,
 
 	reply->protocol = htons(ETH_P_IPV6);
 	reply->dev = dev;
-	skb_reserve(reply, LL_RESERVED_SPACE(request->dev));
+	skb_reserve(reply, headroom);
 	skb_push(reply, sizeof(struct ethhdr));
 	skb_reset_mac_header(reply);
 

gemini-3.7-flash

null

null

							input: 2340
							output: 42
							thoughts: 338
						

**Analyzing the VXLAN NA Creation Patch**

Okay, let's dive into this patch. My immediate thought is to check the diff against `drivers/net/vxlan/vxlan_core.c` and understand the changes within the `vxlan_na_create` function. It looks like we're dealing with a buffer allocation and manipulation, specifically around the Network Address (NA) creation within the VXLAN module.

The core change revolves around how the required buffer length (`len`) is calculated for the reply `sk_buff`. Before, the calculation was a simple addition: `LL_RESERVED_SPACE(dev) + sizeof(struct ipv6hdr) + ...`. Now, we see the introduction of a `headroom` variable:

```c
	headroom = LL_RESERVED_SPACE(dev);
	len = headroom + sizeof(struct ipv6hdr) + ...
```

and the corresponding `skb_reserve` call now uses this `headroom` variable:

```c
	skb_reserve(reply, headroom);
```

My initial hypothesis is that this change is about optimizing or making the headroom reservation more explicit for the `reply` sk_buff.  The previous implicit use of `LL_RESERVED_SPACE(dev)` for both `len` calculation and `skb_reserve` might have been subtle or less clear than assigning it to a separate `headroom` variable.  I need to confirm if `LL_RESERVED_SPACE(dev)` does what I think it does - returns the link layer header length plus any other reserved space for a given device. The change seems to make the code more readable by explicitly showing the `headroom` allocation, which is a good practice. No significant change in the overall size calculation is observed from the patch itself, but I want to ensure this isn't a pre-emptive measure for a larger change.

To fully understand the implications, I need to keep the full context of the function in mind, and also understand exactly how `headroom` and the associated `LL_RESERVED_SPACE` are defined within the device structure, and other functions used. The context of network address creation is also important - why are we using IPv6 in this context? I'll need to dig into the surrounding code and possibly other related functions to confirm the reason and fully validate that this seemingly small change is indeed safe and effective.

{
  "File": "drivers/net/vxlan/vxlan_core.c",
  "FirstLine": 1940,
  "LineCount": 70
}

{
  "Contents": "1940:\tstatic struct sk_buff *vxlan_na_create(struct sk_buff *request,\n1941:\t\t\t\t\t       struct neighbour *n, u8 *ha,\n1942:\t\t\t\t\t       bool isrouter)\n1943:\t{\n1944:\t\tstruct net_device *dev = request-\u003edev;\n1945:\t\tstruct sk_buff *reply;\n1946:\t\tstruct nd_msg *ns, *na;\n1947:\t\tstruct ipv6hdr *pip6;\n1948:\t\tu8 *daddr;\n1949:\t\tint na_olen = 8; /* opt hdr + ETH_ALEN for target */\n1950:\t\tint headroom;\n1951:\t\tint ns_olen;\n1952:\t\tint i, len;\n1953:\t\n1954:\t\tif (dev == NULL || !pskb_may_pull(request, request-\u003elen))\n1955:\t\t\treturn NULL;\n1956:\t\n1957:\t\theadroom = LL_RESERVED_SPACE(dev);\n1958:\t\tlen = headroom + sizeof(struct ipv6hdr) +\n1959:\t\t\tsizeof(*na) + na_olen + dev-\u003eneeded_tailroom;\n1960:\t\treply = alloc_skb(len, GFP_ATOMIC);\n1961:\t\tif (reply == NULL)\n1962:\t\t\treturn NULL;\n1963:\t\n1964:\t\treply-\u003eprotocol = htons(ETH_P_IPV6);\n1965:\t\treply-\u003edev = dev;\n1966:\t\tskb_reserve(reply, headroom);\n1967:\t\tskb_push(reply, sizeof(struct ethhdr));\n1968:\t\tskb_reset_mac_header(reply);\n1969:\t\n1970:\t\tns = (struct nd_msg *)(ipv6_hdr(request) + 1);\n1971:\t\n1972:\t\tdaddr = eth_hdr(request)-\u003eh_source;\n1973:\t\tns_olen = request-\u003elen - skb_network_offset(request) -\n1974:\t\t\tsizeof(struct ipv6hdr) - sizeof(*ns);\n1975:\t\tfor (i = 0; i \u003c ns_olen-1; i += (ns-\u003eopt[i+1]\u003c\u003c3)) {\n1976:\t\t\tif (!ns-\u003eopt[i + 1] || i + (ns-\u003eopt[i + 1] \u003c\u003c 3) \u003e ns_olen) {\n1977:\t\t\t\tkfree_skb(reply);\n1978:\t\t\t\treturn NULL;\n1979:\t\t\t}\n1980:\t\t\tif (ns-\u003eopt[i] == ND_OPT_SOURCE_LL_ADDR) {\n1981:\t\t\t\tif ((ns-\u003eopt[i + 1] \u003c\u003c 3) \u003e=\n1982:\t\t\t\t    sizeof(struct nd_opt_hdr) + ETH_ALEN)\n1983:\t\t\t\t\tdaddr = ns-\u003eopt + i + sizeof(struct nd_opt_hdr);\n1984:\t\t\t\tbreak;\n1985:\t\t\t}\n1986:\t\t}\n1987:\t\n1988:\t\t/* Ethernet header */\n1989:\t\tether_addr_copy(eth_hdr(reply)-\u003eh_dest, daddr);\n1990:\t\tether_addr_copy(eth_hdr(reply)-\u003eh_source, ha);\n1991:\t\teth_hdr(reply)-\u003eh_proto = htons(ETH_P_IPV6);\n1992:\t\treply-\u003eprotocol = htons(ETH_P_IPV6);\n1993:\t\n1994:\t\tskb_pull(reply, sizeof(struct ethhdr));\n1995:\t\tskb_reset_network_header(reply);\n1996:\t\tskb_put(reply, sizeof(struct ipv6hdr));\n1997:\t\n1998:\t\t/* IPv6 header */\n1999:\t\n2000:\t\tpip6 = ipv6_hdr(reply);\n2001:\t\tmemset(pip6, 0, sizeof(struct ipv6hdr));\n2002:\t\tpip6-\u003eversion = 6;\n2003:\t\tpip6-\u003epriority = ipv6_hdr(request)-\u003epriority;\n2004:\t\tpip6-\u003enexthdr = IPPROTO_ICMPV6;\n2005:\t\tpip6-\u003ehop_limit = 255;\n2006:\t\tpip6-\u003edaddr = ipv6_hdr(request)-\u003esaddr;\n2007:\t\tpip6-\u003esaddr = *(struct in6_addr *)n-\u003eprimary_key;\n2008:\t\n2009:\t\tskb_pull(reply, sizeof(struct ipv6hdr));\n"
}

gemini-3.7-flash

null

null

							input: 4434
							output: 33
							thoughts: 90
						

Okay, let's break this down.

**Investigating a Potentially Problematic Code Snippet**

Alright, I need to understand this code's logic. My immediate focus is on a particular line: `struct net_device *dev = request->dev;` Seems straightforward enough at first glance. However, I need to know the origin of the variable `dev`. Where was it initialized? I'm seeing it right here on line 1944. *But* I'm always cautious about assumptions. This direct assignment makes me a little uneasy – is there a chance `dev` isn't what I expect it to be, particularly if its value is altered outside this immediate function?

I need to investigate the caller of `vxlan_na_create` to ensure I'm not overlooking a critical point. Specifically, I need to check how `request->dev` is being passed to see if `dev` could be altered or changed in a way that I should understand. A deeper dive is in order to be sure I understand the context. I'll trace back through the call stack to see if anything is subtly affecting the `dev` value. This is a potential bug or performance issue hotspot, so I need to be thorough.

{
  "Expression": "vxlan_na_create",
  "PathPrefix": "drivers/net/vxlan/"
}

{
  "Output": "drivers/net/vxlan/vxlan_core.c=1842=static int arp_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-1939-#if IS_ENABLED(CONFIG_IPV6)\ndrivers/net/vxlan/vxlan_core.c:1940:static struct sk_buff *vxlan_na_create(struct sk_buff *request,\ndrivers/net/vxlan/vxlan_core.c-1941-\t\t\t\t       struct neighbour *n, u8 *ha,\n--\ndrivers/net/vxlan/vxlan_core.c=2036=static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)\n--\ndrivers/net/vxlan/vxlan_core.c-2078-\ndrivers/net/vxlan/vxlan_core.c:2079:\t\treply = vxlan_na_create(skb, n, ha,\ndrivers/net/vxlan/vxlan_core.c-2080-\t\t\t\t\t!!(f ? f-\u003eflags \u0026 NTF_ROUTER : 0));\n"
}

gemini-3.7-flash

null

null

							input: 5129
							output: 165
							thoughts: 695
						

**Refactoring a Network SKB Headroom Calculation**

Okay, let's break this down. My initial thought is to understand the impact of the code change. Previously, we calculated the length of the skb allocation using `LL_RESERVED_SPACE(dev)` twice: once directly and again through `request->dev`. Now, this redundancy has been cleaned up by storing the value in a temporary variable, `headroom`. This seems like a straightforward refactoring for clarity and possibly performance, avoiding redundant function calls. I need to make sure this doesn't introduce any new issues.

My immediate concern is always uninitialized memory. I'm looking for any case where the refactoring might alter memory access patterns or introduce new uninitialized variables. Let's see... we're calculating `headroom` and then using it consistently throughout the allocation and initialization. The values are the same as before. `reply` is correctly allocated with `alloc_skb`, and the ethernet header, IPv6 header, and ND message are written to it. The key is that `dev` and `request->dev` are the same device, so the calculated headroom is consistent.

Let's do a more thorough check:

*   No structs are copied to user space without proper initialization; we're operating within the kernel.
*   No conditional logic is using uninitialized variables as input.
*   No complex data structures are left uninitialized.
*   No information leaks, and the bounds aren't changed in a way that would introduce any uninitialized bytes.

This seems like a purely cosmetic change, or maybe a minor optimization that is also more readable. No KMSAN risks are involved, as everything is properly initialized. I'm confident that this is a safe refactoring.

Given the instructions, the core of this assessment is to determine if this change introduces or exposes any *uninitialized memory risks that would only be detected by KMSAN*. KASAN, LockDep, and the other standard bug detectors are enough for here. This is not the case.

Therefore, `NeedsKMSAN` is definitely `false`. I can call `set-results` with that, along with a clear explanation that contrasts the role and benefits of KMSAN and KASAN in this particular case.

{
  "KMSANReasoning": "The patch performs a minor refactoring in `vxlan_na_create()` within `drivers/net/vxlan/vxlan_core.c`. It caches `LL_RESERVED_SPACE(dev)` in a local variable `headroom` and reuses it for both the allocation size calculation and `skb_reserve(reply, headroom)`. Because `dev` is initialized as `request-\u003edev`, this change introduces no change in runtime values, memory layout, buffer allocations, or data copying. There are no uninitialized variables, structure padding leaks, or uninitialized memory reads introduced or exposed. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch performs a minor refactoring in `vxlan_na_create()` within `drivers/net/vxlan/vxlan_core.c`. It caches `LL_RESERVED_SPACE(dev)` in a local variable `headroom` and reuses it for both the allocation size calculation and `skb_reserve(reply, headroom)`. Because `dev` is initialized as `request-\u003edev`, this change introduces no change in runtime values, memory layout, buffer allocations, or data copying. There are no uninitialized variables, structure padding leaks, or uninitialized memory reads introduced or exposed. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}