[PATCH net-next 1/2] netlink: specs: nlctrl: fix the policy attribute numbering

[PATCH net-next 1/2] netlink: specs: nlctrl: fix the policy attribute numbering

[Jakub Kicinski]

mask and pad are declared the wrong way round, giving mask 11 and
pad 12, while enum netlink_policy_type_attr has
NL_POLICY_TYPE_ATTR_PAD at 11 and NL_POLICY_TYPE_ATTR_MASK at 12.

The kernel emits the mask for every NLA_POLICY_MASK() attribute, so a
Python YNL client parsing a policy dump maps it onto pad and throws it
away - 30 of them in ethtool's policy alone.  In the other direction the
64-bit alignment padding, which the kernel does emit on architectures
without efficient unaligned access, is decoded as a u64 mask and blows
up the whole dump. But those architectures are rare.

The generated C parser is not affected, it keys the attributes off the
uAPI symbol names rather than off the values the spec derives.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/nlctrl.yaml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/netlink/specs/nlctrl.yaml b/Documentation/netlink/specs/nlctrl.yaml
index 7e7c158e3e73..6acac4aeab03 100644
--- a/Documentation/netlink/specs/nlctrl.yaml
+++ b/Documentation/netlink/specs/nlctrl.yaml
@@ -156,12 +156,12 @@ doc: |
       -
         name: bitfield32-mask
         type: u32
-      -
-        name: mask
-        type: u64
       -
         name: pad
         type: pad
+      -
+        name: mask
+        type: u64
       -
         name: byte-order
         doc: Byte order of the attribute, absent means host byte order.
-- 
2.55.0

[PATCH net-next 2/2] netlink: specs: nlctrl: let getfamily take a family id

[Jakub Kicinski]

ctrl_policy_family[] accepts CTRL_ATTR_FAMILY_ID and ctrl_getfamily()
looks the family up by it, but the spec lists only family-name in the
request.  C YNL generates struct members and setters from that list, so
struct nlctrl_getfamily_req has no way to carry an id and resolving a
family id - the one a client gets handed in nlmsg_type - back to a name
needs a full dump.

Python YNL happens to encode any attribute of the op's attribute set,
which is why this went unnoticed.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/nlctrl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/netlink/specs/nlctrl.yaml b/Documentation/netlink/specs/nlctrl.yaml
index 6acac4aeab03..a400365cdbeb 100644
--- a/Documentation/netlink/specs/nlctrl.yaml
+++ b/Documentation/netlink/specs/nlctrl.yaml
@@ -191,6 +191,7 @@ doc: |
         request:
           value: 3
           attributes:
+            - family-id
             - family-name
         reply: &all-attrs
           value: 1
-- 
2.55.0

Re: [PATCH net-next 1/2] netlink: specs: nlctrl: fix the policy attribute numbering

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> mask and pad are declared the wrong way round, giving mask 11 and
> pad 12, while enum netlink_policy_type_attr has
> NL_POLICY_TYPE_ATTR_PAD at 11 and NL_POLICY_TYPE_ATTR_MASK at 12.
>
> The kernel emits the mask for every NLA_POLICY_MASK() attribute, so a
> Python YNL client parsing a policy dump maps it onto pad and throws it
> away - 30 of them in ethtool's policy alone.  In the other direction the
> 64-bit alignment padding, which the kernel does emit on architectures
> without efficient unaligned access, is decoded as a u64 mask and blows
> up the whole dump. But those architectures are rare.
>
> The generated C parser is not affected, it keys the attributes off the
> uAPI symbol names rather than off the values the spec derives.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

Re: [PATCH net-next 2/2] netlink: specs: nlctrl: let getfamily take a family id

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> ctrl_policy_family[] accepts CTRL_ATTR_FAMILY_ID and ctrl_getfamily()
> looks the family up by it, but the spec lists only family-name in the
> request.  C YNL generates struct members and setters from that list, so
> struct nlctrl_getfamily_req has no way to carry an id and resolving a
> family id - the one a client gets handed in nlmsg_type - back to a name
> needs a full dump.
>
> Python YNL happens to encode any attribute of the op's attribute set,
> which is why this went unnoticed.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

Re: [PATCH net-next 1/2] netlink: specs: nlctrl: fix the policy attribute numbering

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 15 Sep 2026 19:15:15 -0700 you wrote:
> mask and pad are declared the wrong way round, giving mask 11 and
> pad 12, while enum netlink_policy_type_attr has
> NL_POLICY_TYPE_ATTR_PAD at 11 and NL_POLICY_TYPE_ATTR_MASK at 12.
> 
> The kernel emits the mask for every NLA_POLICY_MASK() attribute, so a
> Python YNL client parsing a policy dump maps it onto pad and throws it
> away - 30 of them in ethtool's policy alone.  In the other direction the
> 64-bit alignment padding, which the kernel does emit on architectures
> without efficient unaligned access, is decoded as a u64 mask and blows
> up the whole dump. But those architectures are rare.
> 
> [...]

Here is the summary with links:
  - [net-next,1/2] netlink: specs: nlctrl: fix the policy attribute numbering
    https://git.kernel.org/netdev/net-next/c/0fa13b71c330
  - [net-next,2/2] netlink: specs: nlctrl: let getfamily take a family id
    https://git.kernel.org/netdev/net-next/c/7c6a3f0a8433

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html