Re: [net-next,v7,3/5] doc/netlink: nftables: Update attribute sets

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
doc/netlink: nftables: Update attribute sets

This commit adds new attribute sets (log-attrs, numgen-attrs, range-attrs,
compat-target-attrs, compat-match-attrs, compat-attrs), adds missing
attributes and checks, and fixes byte-order annotations for the nftables
netlink specification.

> diff --git a/Documentation/netlink/specs/nftables.yaml b/Documentation/netlink/specs/nftables.yaml
> index f15f825cb3a1..2ddf89c70124 100644
> --- a/Documentation/netlink/specs/nftables.yaml
> +++ b/Documentation/netlink/specs/nftables.yaml

[ ... ]

> +  -
> +    name: range-attrs
> +    attributes:
> +      # Mentioned in net/netfilter/nft_range.c
> +      -
> +        name: sreg
> +        doc: source register of data to compare
> +        type: u32
> +        byte-order: big-endian
> +        enum: registers
> +      -
> +        name: op
> +        doc: cmp operation
> +        type: u32
> +        byte-order: big-endian
> +        enum: range-ops
> +        checks:
> +          max: 256

Should this be max: 255? Looking at nft_range_init() in net/netfilter/nft_range.c,
the kernel uses nft_parse_u32_check(tb[NFTA_RANGE_OP], U8_MAX, &op), where U8_MAX
is 255. This spec would allow 256 which the kernel rejects with -ERANGE.

[ ... ]

> +  -
> +    name: compat-target-attrs
> +    header: linux/netfilter/nf_tables_compat.h
> +    attributes:
> +      -
> +        name: name
> +        type: string
> +        checks:
> +          max-len: 32
> +      -
> +        name: rev
> +        type: u32
> +        byte-order: big-endian
> +      -
> +        name: info
> +        type: binary
> +  -
> +    name: compat-match-attrs
> +    header: linux/netfilter/nf_tables_compat.h
> +    attributes:
> +      -
> +        name: name
> +        type: string
> +        checks:
> +          max-len: 32
> +      -
> +        name: rev
> +        type: u32
> +        byte-order: big-endian
> +        checks:
> +          max: 255

Should compat-target-attrs also have checks: max: 255 for its rev field? The
kernel's nft_target_policy uses NLA_POLICY_MAX(NLA_BE32, 255) for NFTA_TARGET_REV,
same as compat-match-attrs, but compat-target-attrs rev field above is missing
this check.
-- 
pw-bot: cr