| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/11 21:48 | flow | patch-triage |
0mArgs:null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"KMSANReasoning": "",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies only YAML specification files under Documentation/netlink/specs/ (devlink.yaml, ethtool.yaml, nl80211.yaml, rt-link.yaml, tc.yaml). These are documentation and specification files used by userspace tooling and do not alter any executable kernel code or affect the compiled kernel image (vmlinux or modules).",
"WorthFuzzing": false
} |
| 1/1 | 2026/09/11 21:48 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 98c6bc4e3790980dbee84ca894be5747cae43a06\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Fri Sep 11 21:48:49 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml\nindex 38b1190f3d269..0b3160e201dad 100644\n--- a/Documentation/netlink/specs/devlink.yaml\n+++ b/Documentation/netlink/specs/devlink.yaml\n@@ -158,7 +158,7 @@ definitions:\n -\n name: entry\n -\n- type: enum\n+ type: flags\n name: resource-scope\n entries:\n -\ndiff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml\nindex 5dd4d1b5d94bb..a66594ad9e739 100644\n--- a/Documentation/netlink/specs/ethtool.yaml\n+++ b/Documentation/netlink/specs/ethtool.yaml\n@@ -47,6 +47,7 @@ definitions:\n -\n name: started\n doc: The firmware flashing process has started.\n+ value: 1\n -\n name: in-progress\n doc: The firmware flashing process is in progress.\n@@ -89,6 +90,7 @@ definitions:\n -\n name: power-not-available\n doc: Group of power_not_available states\n+ value: 8\n -\n name: short-detected\n doc: Group of short_detected states\n@@ -97,7 +99,7 @@ definitions:\n enum-name: phy-upstream\n header: linux/ethtool.h\n type: enum\n- name-prefix: phy-upstream\n+ name-prefix: phy-upstream-\n entries: [mac, phy]\n -\n name: tcp-data-split\ndiff --git a/Documentation/netlink/specs/nl80211.yaml b/Documentation/netlink/specs/nl80211.yaml\nindex d9fdd66b497e2..efc783fb8fdfc 100644\n--- a/Documentation/netlink/specs/nl80211.yaml\n+++ b/Documentation/netlink/specs/nl80211.yaml\n@@ -97,7 +97,7 @@ definitions:\n - unexpected-frame\n - probe-client\n - register-beacons\n- - unexpected-4-addr-frame\n+ - unexpected-4addr-frame\n - set-noack-map\n - ch-switch-notify\n - start-p2p-device\n@@ -202,7 +202,7 @@ definitions:\n - tdls-channel-switch\n - scan-random-mac-addr\n - sched-scan-random-mac-addr\n- - no-random-mac-addr\n+ - nd-random-mac-addr\n -\n name: channel-type\n type: enum\ndiff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml\nindex 5217d0bb4a3a5..9743989ded2b2 100644\n--- a/Documentation/netlink/specs/rt-link.yaml\n+++ b/Documentation/netlink/specs/rt-link.yaml\n@@ -25,17 +25,17 @@ definitions:\n -\n name: loopback\n -\n- name: point-to-point\n+ name: pointopoint\n -\n- name: no-trailers\n+ name: notrailers\n -\n name: running\n -\n- name: no-arp\n+ name: noarp\n -\n name: promisc\n -\n- name: all-multi\n+ name: allmulti\n -\n name: master\n -\n@@ -45,7 +45,7 @@ definitions:\n -\n name: portsel\n -\n- name: auto-media\n+ name: automedia\n -\n name: dynamic\n -\n@@ -309,6 +309,7 @@ definitions:\n entries:\n -\n name: forwarding\n+ value: 1\n -\n name: mc-forwarding\n -\n@@ -531,11 +532,21 @@ definitions:\n -\n name: indelivers\n -\n- name: outforwdatagrams\n+ name: noectpkts\n+ -\n+ name: ect1pkts\n+ -\n+ name: ect0pkts\n+ -\n+ name: cepkts\n+ -\n+ name: outrequests\n -\n name: outpkts\n -\n name: outoctets\n+ -\n+ name: outforwdatagrams\n -\n name: inhdrerrors\n -\n@@ -586,14 +597,6 @@ definitions:\n name: outbcastoctets\n -\n name: csumerrors\n- -\n- name: noectpkts\n- -\n- name: ect1-pkts\n- -\n- name: ect0-pkts\n- -\n- name: cepkts\n -\n name: reasm-overlaps\n - name: br-boolopt-multi\n@@ -809,10 +812,10 @@ definitions:\n enum-name:\n entries:\n -\n- name: forward\n+ name: pass\n value: 0\n -\n- name: blackhole\n+ name: drop\n value: 2\n -\n name: netkit-mode\n@@ -839,7 +842,7 @@ definitions:\n -\n name: ovpn-mode\n enum-name: ovpn-mode\n- name-prefix: ovpn-mode\n+ name-prefix: ovpn-mode-\n type: enum\n entries:\n - p2p\ndiff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml\nindex 2e663333a2798..b6ccc645b0e33 100644\n--- a/Documentation/netlink/specs/tc.yaml\n+++ b/Documentation/netlink/specs/tc.yaml\n@@ -42,7 +42,7 @@ definitions:\n - skip-hw\n - skip-sw\n - in-hw\n- - not-in-nw\n+ - not-in-hw\n - verbose\n -\n name: flower-key-ctrl-flags\n"
} |
| 2/1 | 2026/09/11 21:48 | agent | patch-evaluator |
0mModel:core Args: null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies only YAML specification files under Documentation/netlink/specs/ (devlink.yaml, ethtool.yaml, nl80211.yaml, rt-link.yaml, tc.yaml). These are documentation and specification files used by userspace tooling and do not alter any executable kernel code or affect the compiled kernel image (vmlinux or modules).",
"WorthFuzzing": false
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit 98c6bc4e3790980dbee84ca894be5747cae43a06
Author: syz-cluster <triage@syzkaller.com>
Date: Fri Sep 11 21:48:49 2026 +0000
syz-cluster: applied patch under review
diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
index 38b1190f3d269..0b3160e201dad 100644
--- a/Documentation/netlink/specs/devlink.yaml
+++ b/Documentation/netlink/specs/devlink.yaml
@@ -158,7 +158,7 @@ definitions:
-
name: entry
-
- type: enum
+ type: flags
name: resource-scope
entries:
-
diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 5dd4d1b5d94bb..a66594ad9e739 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -47,6 +47,7 @@ definitions:
-
name: started
doc: The firmware flashing process has started.
+ value: 1
-
name: in-progress
doc: The firmware flashing process is in progress.
@@ -89,6 +90,7 @@ definitions:
-
name: power-not-available
doc: Group of power_not_available states
+ value: 8
-
name: short-detected
doc: Group of short_detected states
@@ -97,7 +99,7 @@ definitions:
enum-name: phy-upstream
header: linux/ethtool.h
type: enum
- name-prefix: phy-upstream
+ name-prefix: phy-upstream-
entries: [mac, phy]
-
name: tcp-data-split
diff --git a/Documentation/netlink/specs/nl80211.yaml b/Documentation/netlink/specs/nl80211.yaml
index d9fdd66b497e2..efc783fb8fdfc 100644
--- a/Documentation/netlink/specs/nl80211.yaml
+++ b/Documentation/netlink/specs/nl80211.yaml
@@ -97,7 +97,7 @@ definitions:
- unexpected-frame
- probe-client
- register-beacons
- - unexpected-4-addr-frame
+ - unexpected-4addr-frame
- set-noack-map
- ch-switch-notify
- start-p2p-device
@@ -202,7 +202,7 @@ definitions:
- tdls-channel-switch
- scan-random-mac-addr
- sched-scan-random-mac-addr
- - no-random-mac-addr
+ - nd-random-mac-addr
-
name: channel-type
type: enum
diff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml
index 5217d0bb4a3a5..9743989ded2b2 100644
--- a/Documentation/netlink/specs/rt-link.yaml
+++ b/Documentation/netlink/specs/rt-link.yaml
@@ -25,17 +25,17 @@ definitions:
-
name: loopback
-
- name: point-to-point
+ name: pointopoint
-
- name: no-trailers
+ name: notrailers
-
name: running
-
- name: no-arp
+ name: noarp
-
name: promisc
-
- name: all-multi
+ name: allmulti
-
name: master
-
@@ -45,7 +45,7 @@ definitions:
-
name: portsel
-
- name: auto-media
+ name: automedia
-
name: dynamic
-
@@ -309,6 +309,7 @@ definitions:
entries:
-
name: forwarding
+ value: 1
-
name: mc-forwarding
-
@@ -531,11 +532,21 @@ definitions:
-
name: indelivers
-
- name: outforwdatagrams
+ name: noectpkts
+ -
+ name: ect1pkts
+ -
+ name: ect0pkts
+ -
+ name: cepkts
+ -
+ name: outrequests
-
name: outpkts
-
name: outoctets
+ -
+ name: outforwdatagrams
-
name: inhdrerrors
-
@@ -586,14 +597,6 @@ definitions:
name: outbcastoctets
-
name: csumerrors
- -
- name: noectpkts
- -
- name: ect1-pkts
- -
- name: ect0-pkts
- -
- name: cepkts
-
name: reasm-overlaps
- name: br-boolopt-multi
@@ -809,10 +812,10 @@ definitions:
enum-name:
entries:
-
- name: forward
+ name: pass
value: 0
-
- name: blackhole
+ name: drop
value: 2
-
name: netkit-mode
@@ -839,7 +842,7 @@ definitions:
-
name: ovpn-mode
enum-name: ovpn-mode
- name-prefix: ovpn-mode
+ name-prefix: ovpn-mode-
type: enum
entries:
- p2p
diff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml
index 2e663333a2798..b6ccc645b0e33 100644
--- a/Documentation/netlink/specs/tc.yaml
+++ b/Documentation/netlink/specs/tc.yaml
@@ -42,7 +42,7 @@ definitions:
- skip-hw
- skip-sw
- in-hw
- - not-in-nw
+ - not-in-hw
- verbose
-
name: flower-key-ctrl-flags
|
| 3/2 | 2026/09/11 21:48 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4302 output: 18 thoughts: 421 Thoughts: **Evaluating This Patch Series** Okay, so I've been asked to assess this patch series. The modifications are all focused on `Documentation/netlink/specs/` – specifically `devlink.yaml`, `ethtool.yaml`, `nl80211.yaml`, `rt-link.yaml`, and `tc.yaml`. My initial instinct is to check the rules for determining if this patch is worth fuzzing. I need to know if all the modified code falls into the "negative criteria" categories. The rule set specifically states that changes to documentation automatically make something not worth fuzzing. But wait a minute... are these `.yaml` files *purely* documentation? Or are they used in the build process in some way? They're in the `Documentation` directory, which *suggests* documentation, but I need to be absolutely sure. I need to confirm whether these files are used to generate any kernel code during the build. Are they used by `tools/net/ynl` or are they documentation only? I need to use `grepper` or check the git history to see where these `Documentation/netlink/specs/` files are actually *used* within the kernel build system. If they're just documentation and don't affect compiled kernel logic, then this patch would be considered not worth fuzzing, and I can move on. Otherwise, it's worth a much deeper look. |
| 4/2 | 2026/09/11 21:48 | tool | grepper |
0mArgs:{
"Expression": "netlink/specs"
}Results: {
"Output": "Documentation/conf.py=45=dyn_exclude_patterns = [\"output\", \"sphinx-includes\"]\nDocumentation/conf.py-46-\nDocumentation/conf.py:47:# Currently, only netlink/specs has a parser for yaml.\nDocumentation/conf.py-48-# Prefer using include patterns if available, as it is faster\nDocumentation/conf.py=49=if has_include_patterns:\nDocumentation/conf.py:50: dyn_include_patterns.append(\"netlink/specs/*.yaml\")\nDocumentation/conf.py-51-else:\n--\nDocumentation/gpu/drm-ras.rst=60=YAML-based Interface\n--\nDocumentation/gpu/drm-ras.rst-62-\nDocumentation/gpu/drm-ras.rst:63:The interface is described in a YAML specification ``Documentation/netlink/specs/drm_ras.yaml``\nDocumentation/gpu/drm-ras.rst-64-\n--\nDocumentation/networking/index.rst=6=Contents:\n--\nDocumentation/networking/index.rst-56- generic_netlink\nDocumentation/networking/index.rst:57: ../netlink/specs/index\nDocumentation/networking/index.rst-58- gen_stats\n--\nDocumentation/networking/mptcp.rst=68=connection. The path managers can be controlled via a Netlink API; see\nDocumentation/networking/mptcp.rst:69:../netlink/specs/mptcp_pm.rst.\nDocumentation/networking/mptcp.rst-70-\n--\nDocumentation/networking/multi-pf-netdev.rst=90=The relation between PF, irq, napi, and queue can be observed via netlink spec::\nDocumentation/networking/multi-pf-netdev.rst-91-\nDocumentation/networking/multi-pf-netdev.rst:92: $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump queue-get --json='{\"ifindex\": 13}'\nDocumentation/networking/multi-pf-netdev.rst-93- [{'id': 0, 'ifindex': 13, 'napi-id': 539, 'type': 'rx'},\n--\nDocumentation/networking/multi-pf-netdev.rst-103-\nDocumentation/networking/multi-pf-netdev.rst:104: $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/netdev.yaml --dump napi-get --json='{\"ifindex\": 13}'\nDocumentation/networking/multi-pf-netdev.rst-105- [{'id': 543, 'ifindex': 13, 'irq': 42},\n--\nDocumentation/networking/napi.rst=205=will reveal each queue's NAPI ID):\n--\nDocumentation/networking/napi.rst-209- $ kernel-source/tools/net/ynl/pyynl/cli.py \\\nDocumentation/networking/napi.rst:210: --spec Documentation/netlink/specs/netdev.yaml \\\nDocumentation/networking/napi.rst-211- --dump queue-get \\\n--\nDocumentation/networking/napi.rst-213-\nDocumentation/networking/napi.rst:214:See ``Documentation/netlink/specs/netdev.yaml`` for more details on\nDocumentation/networking/napi.rst-215-available operations and attributes.\n--\nDocumentation/networking/napi.rst=240=For example, using the script:\n--\nDocumentation/networking/napi.rst-244- $ kernel-source/tools/net/ynl/pyynl/cli.py \\\nDocumentation/networking/napi.rst:245: --spec Documentation/netlink/specs/netdev.yaml \\\nDocumentation/networking/napi.rst-246- --do napi-set \\\n--\nDocumentation/networking/page_pool.rst=47=etc. can be accessed via the netdev genetlink family\nDocumentation/networking/page_pool.rst:48:(see Documentation/netlink/specs/netdev.yaml).\nDocumentation/networking/page_pool.rst-49-\n--\nDocumentation/networking/xdp-rx-metadata.rst=120=netlink. See ``xdp-rx-metadata-features`` attribute set in\nDocumentation/networking/xdp-rx-metadata.rst:121:``Documentation/netlink/specs/netdev.yaml``.\nDocumentation/networking/xdp-rx-metadata.rst-122-\n--\nDocumentation/networking/xsk-tx-metadata.rst=134=Query the ``xsk-features`` attribute in\nDocumentation/networking/xsk-tx-metadata.rst:135:``Documentation/netlink/specs/netdev.yaml``. Its bits are defined by the\nDocumentation/networking/xsk-tx-metadata.rst-136-``xsk-flags`` enum.\n--\nDocumentation/sphinx/parser_yaml.py=29=class YamlParser(Parser):\n--\nDocumentation/sphinx/parser_yaml.py-105- # Handle netlink yaml specs\nDocumentation/sphinx/parser_yaml.py:106: if \"/netlink/specs/\" in fname:\nDocumentation/sphinx/parser_yaml.py-107- msg = self.netlink_parser.parse_yaml_file(fname)\n--\nDocumentation/translations/zh_CN/networking/napi.rst=132=NAPI 实例最常以 1:1:1 映射到中断和队列对(队列对是由一个接收队列和一个发送队列组成的一组\n--\nDocumentation/translations/zh_CN/networking/napi.rst-171- $ kernel-source/tools/net/ynl/pyynl/cli.py \\\nDocumentation/translations/zh_CN/networking/napi.rst:172: --spec Documentation/netlink/specs/netdev.yaml \\\nDocumentation/translations/zh_CN/networking/napi.rst-173- --dump queue-get \\\n--\nDocumentation/translations/zh_CN/networking/napi.rst-175-\nDocumentation/translations/zh_CN/networking/napi.rst:176:有关可用操作和属性的更多详细信息,请参阅 ``Documentation/netlink/specs/netdev.yaml``。\nDocumentation/translations/zh_CN/networking/napi.rst-177-\n--\nDocumentation/translations/zh_CN/networking/napi.rst=189=Netlink 进行配置且是基于每个 NAPI 实例设置时,上述参数使用连字符(-)而非下划线(_)\n--\nDocumentation/translations/zh_CN/networking/napi.rst-199- $ kernel-source/tools/net/ynl/pyynl/cli.py \\\nDocumentation/translations/zh_CN/networking/napi.rst:200: --spec Documentation/netlink/specs/netdev.yaml \\\nDocumentation/translations/zh_CN/networking/napi.rst-201- --do napi-set \\\n--\nDocumentation/userspace-api/netlink/index.rst=19=See also:\nDocumentation/userspace-api/netlink/index.rst-20- - :ref:`Documentation/core-api/netlink.rst \u003ckernel_netlink\u003e`\nDocumentation/userspace-api/netlink/index.rst:21: - :ref:`Documentation/netlink/specs/index.rst \u003cspecs\u003e`\n--\nDocumentation/userspace-api/netlink/intro-specs.rst=19=a handful of arguments, the most important ones are:\n--\nDocumentation/userspace-api/netlink/intro-specs.rst-25-\nDocumentation/userspace-api/netlink/intro-specs.rst:26:YAML specs can be found under ``Documentation/netlink/specs/``.\nDocumentation/userspace-api/netlink/intro-specs.rst-27-\nDocumentation/userspace-api/netlink/intro-specs.rst=28=Example use::\nDocumentation/userspace-api/netlink/intro-specs.rst-29-\nDocumentation/userspace-api/netlink/intro-specs.rst:30: $ ./tools/net/ynl/pyynl/cli.py --spec Documentation/netlink/specs/ethtool.yaml \\\nDocumentation/userspace-api/netlink/intro-specs.rst-31- --do rings-get \\\n--\nDocumentation/userspace-api/netlink/intro-specs.rst=65=tracked by git!) For instance the ``fou_nl.c`` kernel source contains::\nDocumentation/userspace-api/netlink/intro-specs.rst-66-\nDocumentation/userspace-api/netlink/intro-specs.rst:67: /*\tDocumentation/netlink/specs/fou.yaml */\nDocumentation/userspace-api/netlink/intro-specs.rst-68- /* YNL-GEN kernel source */\n--\nDocumentation/userspace-api/netlink/specs.rst=15=Internally kernel uses the YAML specs to generate:\n--\nDocumentation/userspace-api/netlink/specs.rst-17- - the C uAPI header\nDocumentation/userspace-api/netlink/specs.rst:18: - documentation of the protocol as a ReST file - see :ref:`Documentation/netlink/specs/index.rst \u003cspecs\u003e`\nDocumentation/userspace-api/netlink/specs.rst-19- - policy tables for input attribute validation\n--\nDocumentation/userspace-api/netlink/specs.rst-21-\nDocumentation/userspace-api/netlink/specs.rst:22:YAML specifications can be found under ``Documentation/netlink/specs/``\nDocumentation/userspace-api/netlink/specs.rst-23-\n--\nMAINTAINERS=1998=T:\tgit git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git\nMAINTAINERS:1999:F:\tDocumentation/netlink/specs/binder.yaml\nMAINTAINERS-2000-F:\tdrivers/android/\n--\nMAINTAINERS=7921=F:\tDocumentation/driver-api/dpll.rst\nMAINTAINERS:7922:F:\tDocumentation/netlink/specs/dpll.yaml\nMAINTAINERS-7923-F:\tdrivers/dpll/\n--\nMAINTAINERS=9659=S:\tMaintained\nMAINTAINERS:9660:F:\tDocumentation/netlink/specs/dev-energymodel.yaml\nMAINTAINERS-9661-F:\tDocumentation/power/energy-model.rst\n--\nMAINTAINERS=11455=S:\tMaintained\nMAINTAINERS:11456:F:\tDocumentation/netlink/specs/handshake.yaml\nMAINTAINERS-11457-F:\tDocumentation/networking/tls-handshake.rst\n--\nMAINTAINERS=18965=M:\tJakub Kicinski \u003ckuba@kernel.org\u003e\nMAINTAINERS:18966:F:\tDocumentation/netlink/specs/ethtool.yaml\nMAINTAINERS-18967-F:\tDocumentation/networking/ethtool-netlink.rst\n--\nMAINTAINERS=19117=S:\tMaintained\nMAINTAINERS:19118:F:\tDocumentation/netlink/specs/rt-addr.yaml\nMAINTAINERS:19119:F:\tDocumentation/netlink/specs/rt-neigh.yaml\nMAINTAINERS:19120:F:\tDocumentation/netlink/specs/rt-route.yaml\nMAINTAINERS:19121:F:\tDocumentation/netlink/specs/rt-rule.yaml\nMAINTAINERS-19122-F:\tinclude/linux/inetdevice.h\n--\nMAINTAINERS=19206=T:\tgit https://github.com/multipath-tcp/mptcp_net-next.git export\nMAINTAINERS:19207:F:\tDocumentation/netlink/specs/mptcp_pm.yaml\nMAINTAINERS-19208-F:\tDocumentation/networking/mptcp*.rst\n--\nMAINTAINERS=20514=T:\tgit https://github.com/OpenVPN/ovpn-net-next.git\nMAINTAINERS:20515:F:\tDocumentation/netlink/specs/ovpn.yaml\nMAINTAINERS-20516-F:\tdrivers/net/ovpn/\n--\nMAINTAINERS=21920=M:\tWillem de Bruijn \u003cwillemdebruijn.kernel@gmail.com\u003e\nMAINTAINERS:21921:F:\tDocumentation/netlink/specs/psp.yaml\nMAINTAINERS-21922-F:\tDocumentation/networking/psp.rst\n--\nMAINTAINERS=26794=S:\tSupported\nMAINTAINERS:26795:F:\tDocumentation/netlink/specs/team.yaml\nMAINTAINERS-26796-F:\tdrivers/net/team/\n--\nMAINTAINERS=29433=S:\tMaintained\nMAINTAINERS:29434:F:\tDocumentation/netlink/specs/wireguard.yaml\nMAINTAINERS-29435-F:\tdrivers/net/wireguard/\n--\nMAINTAINERS=30070=F:\tDocumentation/userspace-api/netlink/intro-specs.rst\nMAINTAINERS:30071:F:\tDocumentation/userspace-api/netlink/specs.rst\nMAINTAINERS-30072-F:\ttools/net/ynl/\n--\ndrivers/android/binder/netlink.rs-1-// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)\ndrivers/android/binder/netlink.rs:2:/* Based on: Documentation/netlink/specs/binder.yaml */\ndrivers/android/binder/netlink.rs-3-\n--\ndrivers/android/binder_netlink.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/android/binder_netlink.c:3:/*\tDocumentation/netlink/specs/binder.yaml */\ndrivers/android/binder_netlink.c-4-/* YNL-GEN kernel source */\n--\ndrivers/android/binder_netlink.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/android/binder_netlink.h:3:/*\tDocumentation/netlink/specs/binder.yaml */\ndrivers/android/binder_netlink.h-4-/* YNL-GEN kernel header */\n--\ndrivers/dpll/dpll_nl.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/dpll/dpll_nl.c:3:/*\tDocumentation/netlink/specs/dpll.yaml */\ndrivers/dpll/dpll_nl.c-4-/* YNL-GEN kernel source */\n--\ndrivers/dpll/dpll_nl.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/dpll/dpll_nl.h:3:/*\tDocumentation/netlink/specs/dpll.yaml */\ndrivers/dpll/dpll_nl.h-4-/* YNL-GEN kernel header */\n--\ndrivers/gpu/drm/drm_ras_nl.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/gpu/drm/drm_ras_nl.c:3:/*\tDocumentation/netlink/specs/drm_ras.yaml */\ndrivers/gpu/drm/drm_ras_nl.c-4-/* YNL-GEN kernel source */\n--\ndrivers/gpu/drm/drm_ras_nl.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/gpu/drm/drm_ras_nl.h:3:/*\tDocumentation/netlink/specs/drm_ras.yaml */\ndrivers/gpu/drm/drm_ras_nl.h-4-/* YNL-GEN kernel header */\n--\ndrivers/net/ovpn/netlink-gen.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/ovpn/netlink-gen.c:3:/*\tDocumentation/netlink/specs/ovpn.yaml */\ndrivers/net/ovpn/netlink-gen.c-4-/* YNL-GEN kernel source */\n--\ndrivers/net/ovpn/netlink-gen.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/ovpn/netlink-gen.h:3:/*\tDocumentation/netlink/specs/ovpn.yaml */\ndrivers/net/ovpn/netlink-gen.h-4-/* YNL-GEN kernel header */\n--\ndrivers/net/team/team_nl.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/team/team_nl.c:3:/*\tDocumentation/netlink/specs/team.yaml */\ndrivers/net/team/team_nl.c-4-/* YNL-GEN kernel source */\n--\ndrivers/net/team/team_nl.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/team/team_nl.h:3:/*\tDocumentation/netlink/specs/team.yaml */\ndrivers/net/team/team_nl.h-4-/* YNL-GEN kernel header */\n--\ndrivers/net/wireguard/generated/netlink.c-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/wireguard/generated/netlink.c:3:/*\tDocumentation/netlink/specs/wireguard.yaml */\ndrivers/net/wireguard/generated/netlink.c-4-/* YNL-GEN kernel source */\n--\ndrivers/net/wireguard/generated/netlink.h-2-/* Do not edit directly, auto-generated from: */\ndrivers/net/wireguard/generated/netlink.h:3:/*\tDocumentation/netlink/specs/wireguard.yaml */\ndrivers/net/wireguard/generated/netlink.h-4-/* YNL-GEN kernel header */\n--\nfs/lockd/netlink.c-2-/* Do not edit directly, auto-generated from: */\nfs/lockd/netlink.c:3:/*\tDocumentation/netlink/specs/lockd.yaml */\nfs/lockd/netlink.c-4-/* YNL-GEN kernel source */\n--\nfs/lockd/netlink.h-2-/* Do not edit directly, auto-generated from: */\nfs/lockd/netlink.h:3:/*\tDocumentation/netlink/specs/lockd.yaml */\nfs/lockd/netlink.h-4-/* YNL-GEN kernel header */\n--\nfs/nfsd/netlink.c-2-/* Do not edit directly, auto-generated from: */\nfs/nfsd/netlink.c:3:/*\tDocumentation/netlink/specs/nfsd.yaml */\nfs/nfsd/netlink.c-4-/* YNL-GEN kernel source */\n--\nfs/nfsd/netlink.h-2-/* Do not edit directly, auto-generated from: */\nfs/nfsd/netlink.h:3:/*\tDocumentation/netlink/specs/nfsd.yaml */\nfs/nfsd/netlink.h-4-/* YNL-GEN kernel header */\n--\ninclude/net/xdp.h=564=void xdp_attachment_setup(struct xdp_attachment_info *info,\n--\ninclude/net/xdp.h-571- * - xdp_rx_metadata enum\ninclude/net/xdp.h:572: * - netdev netlink enum (Documentation/netlink/specs/netdev.yaml)\ninclude/net/xdp.h-573- * - kfunc name\n--\ninclude/uapi/drm/drm_ras.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/drm/drm_ras.h:3:/*\tDocumentation/netlink/specs/drm_ras.yaml */\ninclude/uapi/drm/drm_ras.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/drm/xe_drm.h=2516=struct drm_xe_exec_queue_set_property {\n--\ninclude/uapi/drm/xe_drm.h-2536- * The enums and strings defined below map to the attributes of the DRM RAS Netlink Interface.\ninclude/uapi/drm/xe_drm.h:2537: * Refer to Documentation/netlink/specs/drm_ras.yaml for complete interface specification.\ninclude/uapi/drm/xe_drm.h-2538- *\n--\ninclude/uapi/linux/android/binder_netlink.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/android/binder_netlink.h:3:/*\tDocumentation/netlink/specs/binder.yaml */\ninclude/uapi/linux/android/binder_netlink.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/dev_energymodel.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/dev_energymodel.h:3:/*\tDocumentation/netlink/specs/dev-energymodel.yaml */\ninclude/uapi/linux/dev_energymodel.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/devlink.h=412=enum devlink_attr {\n--\ninclude/uapi/linux/devlink.h-653-\t/* Add new attributes above here, update the spec in\ninclude/uapi/linux/devlink.h:654:\t * Documentation/netlink/specs/devlink.yaml and re-generate\ninclude/uapi/linux/devlink.h-655-\t * net/devlink/netlink_gen.c.\n--\ninclude/uapi/linux/dpll.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/dpll.h:3:/*\tDocumentation/netlink/specs/dpll.yaml */\ninclude/uapi/linux/dpll.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/ethtool_netlink_generated.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/ethtool_netlink_generated.h:3:/*\tDocumentation/netlink/specs/ethtool.yaml */\ninclude/uapi/linux/ethtool_netlink_generated.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/fou.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/fou.h:3:/*\tDocumentation/netlink/specs/fou.yaml */\ninclude/uapi/linux/fou.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/handshake.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/handshake.h:3:/*\tDocumentation/netlink/specs/handshake.yaml */\ninclude/uapi/linux/handshake.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/if_team.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/if_team.h:3:/*\tDocumentation/netlink/specs/team.yaml */\ninclude/uapi/linux/if_team.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/lockd_netlink.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/lockd_netlink.h:3:/*\tDocumentation/netlink/specs/lockd.yaml */\ninclude/uapi/linux/lockd_netlink.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/mptcp_pm.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/mptcp_pm.h:3:/*\tDocumentation/netlink/specs/mptcp_pm.yaml */\ninclude/uapi/linux/mptcp_pm.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/net_shaper.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/net_shaper.h:3:/*\tDocumentation/netlink/specs/net_shaper.yaml */\ninclude/uapi/linux/net_shaper.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/netdev.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/netdev.h:3:/*\tDocumentation/netlink/specs/netdev.yaml */\ninclude/uapi/linux/netdev.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/nfsd_netlink.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/nfsd_netlink.h:3:/*\tDocumentation/netlink/specs/nfsd.yaml */\ninclude/uapi/linux/nfsd_netlink.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/ovpn.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/ovpn.h:3:/*\tDocumentation/netlink/specs/ovpn.yaml */\ninclude/uapi/linux/ovpn.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/psp.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/psp.h:3:/*\tDocumentation/netlink/specs/psp.yaml */\ninclude/uapi/linux/psp.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/sunrpc_netlink.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/sunrpc_netlink.h:3:/*\tDocumentation/netlink/specs/sunrpc_cache.yaml */\ninclude/uapi/linux/sunrpc_netlink.h-4-/* YNL-GEN uapi header */\n--\ninclude/uapi/linux/wireguard.h-2-/* Do not edit directly, auto-generated from: */\ninclude/uapi/linux/wireguard.h:3:/*\tDocumentation/netlink/specs/wireguard.yaml */\ninclude/uapi/linux/wireguard.h-4-/* YNL-GEN uapi header */\n--\nkernel/power/em_netlink_autogen.c-2-/* Do not edit directly, auto-generated from: */\nkernel/power/em_netlink_autogen.c:3:/*\tDocumentation/netlink/specs/dev-energymodel.yaml */\nkernel/power/em_netlink_autogen.c-4-/* YNL-GEN kernel source */\n--\nkernel/power/em_netlink_autogen.h-2-/* Do not edit directly, auto-generated from: */\nkernel/power/em_netlink_autogen.h:3:/*\tDocumentation/netlink/specs/dev-energymodel.yaml */\nkernel/power/em_netlink_autogen.h-4-/* YNL-GEN kernel header */\n--\nnet/core/netdev-genl-gen.c-2-/* Do not edit directly, auto-generated from: */\nnet/core/netdev-genl-gen.c:3:/*\tDocumentation/netlink/specs/netdev.yaml */\nnet/core/netdev-genl-gen.c-4-/* YNL-GEN kernel source */\n--\nnet/core/netdev-genl-gen.h-2-/* Do not edit directly, auto-generated from: */\nnet/core/netdev-genl-gen.h:3:/*\tDocumentation/netlink/specs/netdev.yaml */\nnet/core/netdev-genl-gen.h-4-/* YNL-GEN kernel header */\n--\nnet/devlink/netlink_gen.c-2-/* Do not edit directly, auto-generated from: */\nnet/devlink/netlink_gen.c:3:/*\tDocumentation/netlink/specs/devlink.yaml */\nnet/devlink/netlink_gen.c-4-/* YNL-GEN kernel source */\n--\nnet/devlink/netlink_gen.h-2-/* Do not edit directly, auto-generated from: */\nnet/devlink/netlink_gen.h:3:/*\tDocumentation/netlink/specs/devlink.yaml */\nnet/devlink/netlink_gen.h-4-/* YNL-GEN kernel header */\n--\nnet/handshake/genl.c-2-/* Do not edit directly, auto-generated from: */\nnet/handshake/genl.c:3:/*\tDocumentation/netlink/specs/handshake.yaml */\nnet/handshake/genl.c-4-/* YNL-GEN kernel source */\n--\nnet/handshake/genl.h-2-/* Do not edit directly, auto-generated from: */\nnet/handshake/genl.h:3:/*\tDocumentation/netlink/specs/handshake.yaml */\nnet/handshake/genl.h-4-/* YNL-GEN kernel header */\n--\nnet/ipv4/fou_nl.c-2-/* Do not edit directly, auto-generated from: */\nnet/ipv4/fou_nl.c:3:/*\tDocumentation/netlink/specs/fou.yaml */\nnet/ipv4/fou_nl.c-4-/* YNL-GEN kernel source */\n--\nnet/ipv4/fou_nl.h-2-/* Do not edit directly, auto-generated from: */\nnet/ipv4/fou_nl.h:3:/*\tDocumentation/netlink/specs/fou.yaml */\nnet/ipv4/fou_nl.h-4-/* YNL-GEN kernel header */\n--\nnet/mptcp/mptcp_pm_gen.c-2-/* Do not edit directly, auto-generated from: */\nnet/mptcp/mptcp_pm_gen.c:3:/*\tDocumentation/netlink/specs/mptcp_pm.yaml */\nnet/mptcp/mptcp_pm_gen.c-4-/* YNL-GEN kernel source */\n--\nnet/mptcp/mptcp_pm_gen.h-2-/* Do not edit directly, auto-generated from: */\nnet/mptcp/mptcp_pm_gen.h:3:/*\tDocumentation/netlink/specs/mptcp_pm.yaml */\nnet/mptcp/mptcp_pm_gen.h-4-/* YNL-GEN kernel header */\n--\nnet/psp/psp-nl-gen.c-2-/* Do not edit directly, auto-generated from: */\nnet/psp/psp-nl-gen.c:3:/*\tDocumentation/netlink/specs/psp.yaml */\nnet/psp/psp-nl-gen.c-4-/* YNL-GEN kernel source */\n--\nnet/psp/psp-nl-gen.h-2-/* Do not edit directly, auto-generated from: */\nnet/psp/psp-nl-gen.h:3:/*\tDocumentation/netlink/specs/psp.yaml */\nnet/psp/psp-nl-gen.h-4-/* YNL-GEN kernel header */\n--\nnet/shaper/shaper_nl_gen.c-2-/* Do not edit directly, auto-generated from: */\nnet/shaper/shaper_nl_gen.c:3:/*\tDocumentation/netlink/specs/net_shaper.yaml */\nnet/shaper/shaper_nl_gen.c-4-/* YNL-GEN kernel source */\n--\nnet/shaper/shaper_nl_gen.h-2-/* Do not edit directly, auto-generated from: */\nnet/shaper/shaper_nl_gen.h:3:/*\tDocumentation/netlink/specs/net_shaper.yaml */\nnet/shaper/shaper_nl_gen.h-4-/* YNL-GEN kernel header */\n--\nnet/sunrpc/netlink.c-2-/* Do not edit directly, auto-generated from: */\nnet/sunrpc/netlink.c:3:/*\tDocumentation/netlink/specs/sunrpc_cache.yaml */\nnet/sunrpc/netlink.c-4-/* YNL-GEN kernel source */\n--\nnet/sunrpc/netlink.h-2-/* Do not edit directly, auto-generated from: */\nnet/sunrpc/netlink.h:3:/*\tDocumentation/netlink/specs/sunrpc_cache.yaml */\nnet/sunrpc/netlink.h-4-/* YNL-GEN kernel header */\n--\ntools/docs/test_doc_build.py=455=async def main():\n--\ntools/docs/test_doc_build.py-477- build_group.add_argument('-a', '--make-args', nargs=\"*\",\ntools/docs/test_doc_build.py:478: help='extra arguments for make, like SPHINXDIRS=netlink/specs',\ntools/docs/test_doc_build.py-479- )\n--\ntools/include/uapi/linux/netdev.h-2-/* Do not edit directly, auto-generated from: */\ntools/include/uapi/linux/netdev.h:3:/*\tDocumentation/netlink/specs/netdev.yaml */\ntools/include/uapi/linux/netdev.h-4-/* YNL-GEN uapi header */\n--\ntools/net/ynl/Makefile=14=includedir ?= $(prefix)/include\ntools/net/ynl/Makefile-15-\ntools/net/ynl/Makefile:16:SPECDIR=../../../Documentation/netlink/specs\ntools/net/ynl/Makefile-17-\n--\ntools/net/ynl/generated/Makefile=23=TOOL_RST:=../pyynl/ynl_gen_rst.py\ntools/net/ynl/generated/Makefile-24-\ntools/net/ynl/generated/Makefile:25:SPECS_DIR:=../../../../Documentation/netlink/specs\ntools/net/ynl/generated/Makefile-26-SPECS_PATHS=$(wildcard $(SPECS_DIR)/*.yaml)\n--\ntools/testing/selftests/net/lib/Makefile=8=TEST_FILES := \\\ntools/testing/selftests/net/lib/Makefile-9-\t../../../../net/ynl \\\ntools/testing/selftests/net/lib/Makefile:10:\t../../../../../Documentation/netlink/specs \\\ntools/testing/selftests/net/lib/Makefile-11-\tksft_setup_loopback.sh \\\n--\ntools/testing/selftests/net/lib/py/ynl.py=9=try:\n--\ntools/testing/selftests/net/lib/py/ynl.py-19- tools_full_path = KSRC / \"tools\"\ntools/testing/selftests/net/lib/py/ynl.py:20: SPEC_PATH = KSRC / \"Documentation/netlink/specs\"\ntools/testing/selftests/net/lib/py/ynl.py-21-\n--\ntools/testing/selftests/net/ynl.mk=13=YNL_SPECS := \\\ntools/testing/selftests/net/ynl.mk:14:\t$(patsubst %,$(top_srcdir)/Documentation/netlink/specs/%.yaml,$(YNL_GENS))\ntools/testing/selftests/net/ynl.mk-15-\n"
} |
| 5/2 | 2026/09/11 21:48 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 13899 output: 26 thoughts: 378 Thoughts: **Analyzing Potential Impacts of a Patch** Okay, so I'm looking at this patch and my initial thought is, "Hmm, this doesn't seem to touch any code, just documentation files." The files listed – `Documentation/netlink/specs/devlink.yaml`, `ethtool.yaml`, `nl80211.yaml`, `rt-link.yaml`, and `tc.yaml` – are all YAML specifications. My immediate concern is whether this directly impacts generated code. The first thing I did was double check that it doesn't modify `net/devlink/netlink_gen.c`, since that file appears auto-generated from YAML specs. It doesn't look like this patch *directly* touches that or any related C/H files. But, I know better than to just assume. So, next, let's look at the commit diff more carefully to confirm. A more complete picture of the patch has now been provided and confirms that only the YAML files are modified, and no C or H files are changed. Given the nature of the YAML files, I need to investigate if there's an automated build step that uses these YAML files to generate C or header files. I know the kernel build system pretty well, so my next step is to search the Makefiles (or Kbuild files) within the kernel source. I'll need to see if there's any invocation of these `.yaml` files during the `make vmlinux` or `make modules` process. That would tell me if the documentation changes indirectly cause a regeneration of code, which would be the only thing that could lead to a change in the running kernel. Ultimately, I want to determine if this patch is purely documentation, or if it triggers some code generation that necessitates a deeper review. |
| 6/2 | 2026/09/11 21:49 | tool | grepper |
0mError:no matches Args: {
"Expression": "ynl.*\\.yaml",
"PathPrefix": "Makefile"
}Results: {
"error": "no matches"
} |
| 7/2 | 2026/09/11 21:49 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 14698 output: 26 thoughts: 36 Thoughts: Here's a first-person summary, tailored for an expert audience, of the provided thoughts: **Investigating the Netlink Build Process** Okay, so I need to understand the build process for `netlink_gen.c`. My initial instinct is to dive straight into the relevant Makefiles. I'll start with `net/devlink/Makefile` and `net/core/Makefile`, and probably others within the networking subsystem. That should illuminate how this generated file is incorporated into the overall build. I'm expecting to find rules that trigger code generation, likely based on some form of input definition file or configuration option. Understanding these build dependencies is crucial for any modifications or deeper understanding of the netlink interface. I'll need to trace the variables, flags, and targets used to confirm this and ensure that I understand the entire generation chain. |
| 8/2 | 2026/09/11 21:49 | tool | grepper |
0mArgs:{
"Expression": "netlink_gen",
"PathPrefix": "net/"
}Results: {
"Output": "net/devlink/Makefile-2-\nnet/devlink/Makefile:3:obj-y := core.o netlink.o netlink_gen.o dev.o port.o sb.o dpipe.o \\\nnet/devlink/Makefile-4-\t resource.o param.o region.o health.o trap.o rate.o linecard.o sh_dev.o\n--\nnet/devlink/devl_internal.h-18-\nnet/devlink/devl_internal.h:19:#include \"netlink_gen.h\"\nnet/devlink/devl_internal.h-20-\n--\nnet/devlink/netlink_gen.c-9-\nnet/devlink/netlink_gen.c:10:#include \"netlink_gen.h\"\nnet/devlink/netlink_gen.c-11-\n"
} |
| 9/2 | 2026/09/11 21:49 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 15155 output: 20 thoughts: 219 Thoughts: **My Initial Thoughts on `netlink_gen.c`** Okay, so `netlink_gen.c` is finally checked into git. Good! Now, what's the typical workflow for regenerating this file? My first instinct is to check `git status`, peek into the file itself, or perhaps dive into `Documentation/userspace-api/netlink/intro-specs.rst` to understand how the code generation works in this specific case. I'm hoping for some clues there. Let's see… in the documentation, I see a reference to "tracked by git!" and an example that looks suspiciously like what we're dealing with now. It mentions a `YNL-GEN` kernel source reference, which is certainly intriguing. And looking into `include/uapi/linux/devlink.h`, the comments are pretty explicit: "Add new attributes above here, update the spec in Documentation/netlink/specs/devlink.yaml and re-generate net/devlink/netlink_gen.c". Okay, this confirms my suspicion. So, it seems developers manually execute a `ynl` generator script, and then, the updated `netlink_gen.c` gets checked into the repository. Interesting that it's a manual process. This suggests that the Kbuild system doesn't automatically trigger the code generation during a regular kernel build. Just to be absolutely sure, I'm going to quickly scan the various Kbuild Makefiles across the tree, just to verify that the generation process is not happening on the fly, as sometimes that can catch you out. |
| 10/2 | 2026/09/11 21:49 | tool | grepper |
0mError:no matches Args: {
"Expression": "ynl-gen-c"
}Results: {
"error": "no matches"
} |
| 11/2 | 2026/09/11 21:49 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 15744 output: 20 thoughts: 20 Thoughts: Here's my take on those thoughts: **Peering into the YNL Code Generation Process** Okay, so I need to understand how we're generating code with `ynl`. It's time to dig into the `tools/net/ynl` directory. I know the general architecture, but I need to see the specifics. I'm going to look at the internals, paying close attention to the mechanisms by which ynl builds and crafts the code it outputs. I'm not just interested in the final product; I want to understand the *process* of getting there. What data structures are they leveraging? What templating or code generation techniques are in play? Are there any clever optimizations or potential bottlenecks to consider? I'm expecting some well-organized and well-commented code, given its importance. Let's see what gems are hidden in there. |
| 12/2 | 2026/09/11 21:49 | tool | grepper |
0mArgs:{
"Expression": "ynl_gen_c"
}Results: {
"Output": "Documentation/gpu/drm-ras.rst=65=This YAML is used to auto-generate user space bindings via\nDocumentation/gpu/drm-ras.rst:66:``tools/net/ynl/pyynl/ynl_gen_c.py``, and drives the structure of netlink\nDocumentation/gpu/drm-ras.rst-67-attributes and operations.\n--\nDocumentation/userspace-api/netlink/intro-specs.rst=76=to see other examples.\nDocumentation/userspace-api/netlink/intro-specs.rst-77-\nDocumentation/userspace-api/netlink/intro-specs.rst:78:The code generation itself is performed by ``tools/net/ynl/pyynl/ynl_gen_c.py``\nDocumentation/userspace-api/netlink/intro-specs.rst-79-but it takes a few arguments so calling it directly for each file\n--\nDocumentation/userspace-api/netlink/intro-specs.rst=82=YNL lib\n--\nDocumentation/userspace-api/netlink/intro-specs.rst-86-(based on libmnl) which integrates with code generated by\nDocumentation/userspace-api/netlink/intro-specs.rst:87:``tools/net/ynl/pyynl/ynl_gen_c.py`` to create easy to use netlink wrappers.\nDocumentation/userspace-api/netlink/intro-specs.rst-88-\n--\ntools/net/ynl/generated/Makefile=19=YNL_GEN_ARG_ethtool:=--user-header linux/ethtool_netlink.h \\\n--\ntools/net/ynl/generated/Makefile-21-\ntools/net/ynl/generated/Makefile:22:TOOL:=../pyynl/ynl_gen_c.py\ntools/net/ynl/generated/Makefile-23-TOOL_RST:=../pyynl/ynl_gen_rst.py\n--\ntools/net/ynl/pyynl/ynl_gen_c.py-10-\"\"\"\ntools/net/ynl/pyynl/ynl_gen_c.py:11:ynl_gen_c\ntools/net/ynl/pyynl/ynl_gen_c.py-12-\n--\ntools/net/ynl/ynl-regen.sh-3-\ntools/net/ynl/ynl-regen.sh:4:TOOL=$(dirname $(realpath $0))/pyynl/ynl_gen_c.py\ntools/net/ynl/ynl-regen.sh-5-\n"
} |
| 13/2 | 2026/09/11 21:49 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16600 output: 39 thoughts: 46 Thoughts: Okay, here's my interpretation of that thought process, as if it were my own: **Verifying the Regeneration Script** Alright, I need to make absolutely sure about something related to the network configuration. My initial assumption is that I know what's going on, but experience has taught me that assumptions are dangerous, especially when it comes to system administration and networking. To ensure complete confidence, I'm going to take a direct approach. The most effective way to confirm my understanding is to thoroughly examine the `tools/net/ynl/ynl-regen.sh` script. I'll read through it line by line. I need to know exactly how it works, what dependencies it has, and what effects it has, and leave no room for doubt about the network regeneration process. That way, I'm certain in the steps that follow. |
| 14/2 | 2026/09/11 21:49 | tool | read-file |
0mArgs:{
"File": "tools/net/ynl/ynl-regen.sh",
"FirstLine": 1,
"LineCount": 50
}Results: {
"Contents": " 1:\t#!/bin/bash\n 2:\t# SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause\n 3:\t\n 4:\tTOOL=$(dirname $(realpath $0))/pyynl/ynl_gen_c.py\n 5:\t\n 6:\tforce=\n 7:\tsearch=\n 8:\t\n 9:\twhile [ ! -z \"$1\" ]; do\n 10:\t case \"$1\" in\n 11:\t -f ) force=yes; shift ;;\n 12:\t -p ) search=$2; shift 2 ;;\n 13:\t * ) echo \"Unrecognized option '$1'\"; exit 1 ;;\n 14:\t esac\n 15:\tdone\n 16:\t\n 17:\tKDIR=$(dirname $(dirname $(dirname $(dirname $(realpath $0)))))\n 18:\tpushd ${search:-$KDIR} \u003e\u003e/dev/null\n 19:\t\n 20:\tfiles=$(git grep --files-with-matches '^/\\* YNL-GEN \\(kernel\\|uapi\\|user\\)')\n 21:\tfor f in $files; do\n 22:\t # params: 0 1 2 3\n 23:\t # $YAML YNL-GEN kernel $mode\n 24:\t params=( $(git grep --no-line-number -B1 -h '/\\* YNL-GEN' $f | sed 's@/\\*\\(.*\\)\\*/@\\1@') )\n 25:\t args=$(sed -n 's@/\\* YNL-ARG \\(.*\\) \\*/@\\1@p' $f)\n 26:\t\n 27:\t if [ $f -nt ${params[0]} -a -z \"$force\" ]; then\n 28:\t\techo -e \"\\tSKIP $f\"\n 29:\t\tcontinue\n 30:\t fi\n 31:\t\n 32:\t echo -e \"\\tGEN ${params[2]}\\t$f\"\n 33:\t $TOOL --cmp-out --mode ${params[2]} --${params[3]} \\\n 34:\t\t --spec $KDIR/${params[0]} $args -o $f\n 35:\tdone\n 36:\t\n 37:\tpopd \u003e\u003e/dev/null\n"
} |
| 15/2 | 2026/09/11 21:49 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 17446 output: 109 thoughts: 431 Thoughts: **WorthFuzzing Analysis - Negative Outcome** Okay, so I'm looking at this patch and it's modifying only documentation files, specifically YAML specifications under `Documentation/netlink/specs/`. The script in question, `ynl-regen.sh`, lives in `tools/net/ynl/`. Now, according to Section 2 of the guidelines, I need to determine if this change warrants fuzzing. The guidelines explicitly state I should return `WorthFuzzing=false` if all the changes fall into certain negative criteria. Let me see, I need to check if the changes are: * Non-kernel and non-executable changes * Modifications to Documentation, comments, or spelling fixes * User-space directories, self-tests, samples, or scripts that do not affect the compiled kernel image (vmlinux) or kernel modules. * Purely decorative logging or tracepoints that do not alter control flow or data structures * Build system or Kconfig changes that do not alter compiled C logic Looking at these files, and knowing they're all YAML specs, it's clear: they're *just* documentation. They're not going to affect the compiled kernel image, and they don't involve any C code, header files, or anything that would get linked into the kernel. It’s pretty clear this is a no-op from a kernel perspective. Therefore, `WorthFuzzing` is definitively `false`. There are no focus symbols, and no configurations to enable. The reasoning is straightforward: only YAML specification files under `Documentation/netlink/specs/` are modified, which does not modify any executable kernel code or affect the compiled kernel image. Alright, time to call `set-results`. |
| 16/2 | 2026/09/11 21:49 | tool | set-results |
0mArgs:{
"EnableConfigs": [],
"FocusSymbols": [],
"Reasoning": "The patch modifies only YAML specification files under Documentation/netlink/specs/ (devlink.yaml, ethtool.yaml, nl80211.yaml, rt-link.yaml, tc.yaml). These are documentation and specification files used by userspace tooling and do not alter any executable kernel code or affect the compiled kernel image (vmlinux or modules).",
"WorthFuzzing": false
}Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies only YAML specification files under Documentation/netlink/specs/ (devlink.yaml, ethtool.yaml, nl80211.yaml, rt-link.yaml, tc.yaml). These are documentation and specification files used by userspace tooling and do not alter any executable kernel code or affect the compiled kernel image (vmlinux or modules).",
"WorthFuzzing": false
} |
| 17/1 | 2026/09/11 21:49 | action | If |
0mArgs:{
"WorthFuzzing": false
}Results: null |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|