Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] The patch fixes a real, user-visible defect in a shipped netlink
spec — `Documentation/netlink/specs/rt-addr.yaml` declared `addr-…
--
netlink: specs: rt-addr: fix the type of target-netnsid
This changes the target-netnsid attribute in the addr-attrs set of
rt-addr.yaml from binary to s32, matching what the kernel policy
declares. No Link: tags are present in the commit header.
> diff --git a/Documentation/netlink/specs/rt-addr.yaml
> b/Documentation/netlink/specs/rt-addr.yaml
> index 0ecbd24c890c6..17ead22034515 100644
> --- a/Documentation/netlink/specs/rt-addr.yaml
> +++ b/Documentation/netlink/specs/rt-addr.yaml
> @@ -119,7 +119,7 @@ attribute-sets:
> type: u32
> -
> name: target-netnsid
> - type: binary
> + type: s32
[Severity: Low]
This isn't a bug in the change itself, but should this carry a Fixes: tag?
The spec has been shipped with the wrong type, and the generated ynl code and
the Python decoder have been treating the netns ID as an opaque byte blob,
with the request path rejecting an integer for a binary attribute. The
kernel side has always declared it signed 32-bit:
net/ipv4/devinet.c:ifa_ipv4_policy:
[IFA_TARGET_NETNSID] = { .type = NLA_S32 },
with nla_put_s32() on the emit side and nla_get_s32() on the parse side in
net/ipv6/addrconf.c.
git blame on the pre-patch tree attributes the type: binary line in
Documentation/netlink/specs/rt-addr.yaml to:
dfb0f7d9d97956 ("doc/netlink: Add spec for rt addr messages")
so would adding
Fixes: dfb0f7d9d979 ("doc/netlink: Add spec for rt addr messages")
help backport tooling and users identify which releases carry the wrong
type?
--
Sashiko AI review ·
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260921235951.3214-1-sigefriedhyy%40gmail.com
