netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: Matt Johnston <matt@codeconstruct.com.au>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next 12/13] net: mctp: add gateway routing support
Date: Fri, 13 Jun 2025 18:11:37 +0100	[thread overview]
Message-ID: <20250613171137.GM414686@horms.kernel.org> (raw)
In-Reply-To: <20250611-dev-forwarding-v1-12-6b69b1feb37f@codeconstruct.com.au>

On Wed, Jun 11, 2025 at 02:30:39PM +0800, Jeremy Kerr wrote:
> This change allows for gateway routing, where a route table entry
> may reference a routable endpoint (by network and EID), instead of
> routing directly to a netdevice.
> 
> We add support for a RTM_GATEWAY attribute for netlink route updates,
> with an attribute format of:
> 
>     struct mctp_fq_addr {
>         unsigned int net;
>         mctp_eid_t eid;
>     }
> 
> - we need the net here to uniquely identify the target EID, as we no
> longer have the device reference directly (which would provide the net
> id in the case of direct routes).
> 
> This makes route lookups recursive, as a route lookup that returns a
> gateway route must be resolved into a direct route (ie, to a device)
> eventually. We provide a limit to the route lookups, to prevent infinite
> loop routing.
> 
> The route lookup populates a new 'nexthop' field in the dst structure,
> which now specifies the key for the neighbour table lookup on device
> output, rather than using the packet destination address directly.
> 
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>

...

> diff --git a/net/mctp/route.c b/net/mctp/route.c

...

> -/* base parsing; common to both _lookup and _populate variants */
> +/* base parsing; common to both _lookup and _populate variants.
> + *
> + * For gateway routes (which have a RTA_GATEWAY, and no RTA_OIF), we populate
> + * *gatweayp. for direct routes (RTA_OIF, no RTA_GATEWAY), we populate *mdev.
> + */
>  static int mctp_route_nlparse_common(struct net *net, struct nlmsghdr *nlh,
>  				     struct netlink_ext_ack *extack,
>  				     struct nlattr **tb, struct rtmsg **rtm,
>  				     struct mctp_dev **mdev,
> +				     struct mctp_fq_addr *gatewayp,
>  				     mctp_eid_t *daddr_start)
>  {
> +	struct mctp_fq_addr *gateway;
> +	unsigned int ifindex = 0;
>  	struct net_device *dev;
> -	unsigned int ifindex;
>  	int rc;
>  
>  	rc = nlmsg_parse(nlh, sizeof(struct rtmsg), tb, RTA_MAX,
> @@ -1321,11 +1372,44 @@ static int mctp_route_nlparse_common(struct net *net, struct nlmsghdr *nlh,
>  	}
>  	*daddr_start = nla_get_u8(tb[RTA_DST]);
>  
> -	if (!tb[RTA_OIF]) {
> -		NL_SET_ERR_MSG(extack, "ifindex missing");
> +	if (tb[RTA_OIF])
> +		ifindex = nla_get_u32(tb[RTA_OIF]);
> +
> +	if (tb[RTA_GATEWAY])
> +		gateway = nla_data(tb[RTA_GATEWAY]);
> +
> +	if (ifindex && gateway) {

Hi Jeremy,

gateway may be uninitialised here...

> +		NL_SET_ERR_MSG(extack,
> +			       "cannot specify both ifindex and gateway");
> +		return -EINVAL;
> +
> +	} else if (ifindex) {
> +		dev = __dev_get_by_index(net, ifindex);
> +		if (!dev) {
> +			NL_SET_ERR_MSG(extack, "bad ifindex");
> +			return -ENODEV;
> +		}
> +		*mdev = mctp_dev_get_rtnl(dev);
> +		if (!*mdev)
> +			return -ENODEV;
> +		gatewayp->eid = 0;
> +
> +	} else if (gateway) {

... and here.

Flagged by Smatch.

> +		if (!mctp_address_unicast(gateway->eid)) {
> +			NL_SET_ERR_MSG(extack, "bad gateway");
> +			return -EINVAL;
> +		}
> +
> +		gatewayp->eid = gateway->eid;
> +		gatewayp->net = gateway->net != MCTP_NET_ANY ?
> +			gateway->net :
> +			READ_ONCE(net->mctp.default_net);
> +		*mdev = NULL;
> +
> +	} else {
> +		NL_SET_ERR_MSG(extack, "no route output provided");
>  		return -EINVAL;
>  	}
> -	ifindex = nla_get_u32(tb[RTA_OIF]);
>  
>  	*rtm = nlmsg_data(nlh);
>  	if ((*rtm)->rtm_family != AF_MCTP) {

...

  reply	other threads:[~2025-06-13 17:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11  6:30 [PATCH net-next 00/13] net: mctp: Add support for gateway routing Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 01/13] net: mctp: don't use source cb data when forwarding, ensure pkt_type is set Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 02/13] net: mctp: separate routing database from routing operations Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 03/13] net: mctp: separate cb from direct-addressing routing Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 04/13] net: mctp: test: Add an addressed device constructor Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 05/13] net: mctp: test: Add extaddr routing output test Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 06/13] net: mctp: test: move functions into utils.[ch] Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 07/13] net: mctp: test: add sock test infrastructure Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 08/13] net: mctp: test: Add initial socket tests Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 09/13] net: mctp: pass net into route creation Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 10/13] net: mctp: remove routes by netid, not by device Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 11/13] net: mctp: allow NL parsing directly into a struct mctp_route Jeremy Kerr
2025-06-11  6:30 ` [PATCH net-next 12/13] net: mctp: add gateway routing support Jeremy Kerr
2025-06-13 17:11   ` Simon Horman [this message]
2025-06-18 17:26   ` Dan Carpenter
2025-06-11  6:30 ` [PATCH net-next 13/13] net: mctp: test: Add tests for gateway routes Jeremy Kerr
2025-06-12  8:56   ` kernel test robot

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=20250613171137.GM414686@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jk@codeconstruct.com.au \
    --cc=kuba@kernel.org \
    --cc=matt@codeconstruct.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).