public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Yuya Kusakabe <yuya.kusakabe@gmail.com>
Cc: dsahern@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH iproute2-next 0/6] seg6: SRv6 Mobile User Plane (RFC 9433)
Date: Sun, 3 May 2026 14:05:47 -0700	[thread overview]
Message-ID: <20260503140547.6d732f4b@phoenix.local> (raw)
In-Reply-To: <20260503153006.900533-1-y-kusakabe@bbsakura.net>

On Mon,  4 May 2026 00:30:00 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:

> From: Yuya Kusakabe <yuya.kusakabe@gmail.com>
> 
> This series adds the iproute2 frontend for the SRv6 Mobile User Plane
> (MUP) endpoint behaviors of RFC 9433.  It is sent in parallel with the
> matching kernel net-next series; each commit here is self-contained
> and brings in the seg6local UAPI bits it needs from the in-progress
> kernel UAPI header (include/uapi/linux/seg6_local.h):
> 
>   Section 6.2  End.MAP
>   Section 6.3  End.M.GTP6.D
>   Section 6.4  End.M.GTP6.D.Di
>   Section 6.5  End.M.GTP6.E
>   Section 6.6  End.M.GTP4.E
>   Section 6.7  H.M.GTP4.D
> 
> The series adds these seg6local CLI keywords:
> 
>   src                  IPv6 source-address template
>   v4_mask_len          length of the IPv4 DA portion of the SID, in
>                        bits (1..32)
>   sr_prefix_len        locator length of the egress End.M.GTP*.E SID,
>                        in bits (1..88, leaving 40 bits for the
>                        Args.Mob.Session field)
>   v6_src_prefix_len    Source UPF Prefix length P in the IPv6 SA
>                        template (1..127, defaults to 64); requires
>                        P + v4_mask_len <= 128
>   pdu_type             GTP-U PDU Session Container PDU Type (3GPP
>                        TS 38.415 Section 5.5.2): downlink|dl|uplink|ul
>                        or 0..15.  When omitted, the egress emits a
>                        short GTPv1-U header (no PDU Session Container)
>                        regardless of the QFI in the SID; 5G N3
>                        deployments must set pdu_type explicitly.
> 
> A small per-action attribute validator (introduced in patch 1 and
> extended by each subsequent behavior) rejects obvious typos in the
> seg6local block at the userspace layer instead of leaving the
> operator with an opaque kernel EINVAL.
> 
> Link: https://datatracker.ietf.org/doc/html/rfc9433
> 
> Yuya Kusakabe (6):
>   seg6: add support for the End.MAP behavior
>   seg6: add support for the End.M.GTP4.E behavior
>   seg6: add support for the End.M.GTP6.E behavior
>   seg6: add support for the End.M.GTP6.D behavior
>   seg6: add support for the End.M.GTP6.D.Di behavior
>   seg6: add support for the H.M.GTP4.D behavior
> 
>  include/uapi/linux/seg6_local.h |  17 +++
>  ip/ip_common.h                  |   2 +-
>  ip/ipnexthop.c                  |   2 +-
>  ip/iproute.c                    |  14 +-
>  ip/iproute_lwtunnel.c           | 263 +++++++++++++++++++++++++++++++-
>  man/man8/ip-route.8.in          | 154 +++++++++++++++++++
>  6 files changed, 442 insertions(+), 10 deletions(-)
> 
> 
> base-commit: 4f5de57e2ff11a5925dacdf3deeeabee7ba9502a

Automated AI review of iproute2 is not setup yet, but manual run showed:

Subject: Re: [PATCH iproute2-next v1 RESEND 1/6] seg6: add support for the End.MAP behavior

On Mon, 4 May 2026, Yuya Kusakabe wrote:

> +static void seg6local_action_check_attrs(int action, int nh6_ok)
> +{
> +	switch (action) {
> +	case SEG6_LOCAL_ACTION_END_MAP:
> +		if (!nh6_ok)
> +			invarg("End.MAP requires \"nh6\"\n", "");
> +		break;
> +	}
> +}

The invarg() helper expects the invalid argument string as its second parameter,
not an empty string. This should be:

			invarg("End.MAP requires \"nh6\"", argv_value);

However, since this is a validation function called after parsing and doesn't have
access to argv, a different error reporting approach is needed. Consider using
fprintf(stderr, ...) directly or restructuring to keep the argv value available.

This same issue appears in all patches in this series whenever invarg() is called
from seg6local_action_check_attrs():
- Patch 1: End.MAP validation
- Patch 2: End.M.GTP4.E validation (multiple instances)
- Patch 3: End.M.GTP6.E validation
- Patch 4: End.M.GTP6.D validation
- Patch 5: End.M.GTP6.D.Di validation
- Patch 6: H.M.GTP4.D validation

The rest of the implementation looks good:
- Correctly uses strcmp() instead of matches() for new argument parsing
- Properly uses print_XXX() helpers with PRINT_ANY for JSON output
- Includes proper documentation updates

Please fix the invarg() usage throughout the series.

  parent reply	other threads:[~2026-05-03 21:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-03 15:30 [PATCH iproute2-next 0/6] seg6: SRv6 Mobile User Plane (RFC 9433) Yuya Kusakabe
2026-05-03 15:30 ` [PATCH iproute2-next 1/6] seg6: add support for the End.MAP behavior Yuya Kusakabe
2026-05-03 15:30   ` [PATCH iproute2-next 2/6] seg6: add support for the End.M.GTP4.E behavior Yuya Kusakabe
2026-05-03 15:30     ` [PATCH iproute2-next 3/6] seg6: add support for the End.M.GTP6.E behavior Yuya Kusakabe
2026-05-03 15:30       ` [PATCH iproute2-next 4/6] seg6: add support for the End.M.GTP6.D behavior Yuya Kusakabe
2026-05-03 15:30         ` [PATCH iproute2-next 5/6] seg6: add support for the End.M.GTP6.D.Di behavior Yuya Kusakabe
2026-05-03 15:30           ` [PATCH iproute2-next 6/6] seg6: add support for the H.M.GTP4.D behavior Yuya Kusakabe
2026-05-03 16:45 ` [PATCH iproute2-next 0/6] seg6: SRv6 Mobile User Plane (RFC 9433) Yuya Kusakabe
2026-05-03 21:05 ` Stephen Hemminger [this message]
2026-05-04  1:19   ` Yuya Kusakabe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260503140547.6d732f4b@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=dsahern@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yuya.kusakabe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox