All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Lamparter <equinox@diac24.net>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	David Ahern <dsahern@kernel.org>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next v2] net: ip6mr: add RTM_GETROUTE netlink op
Date: Mon, 4 Jul 2022 12:38:54 +0200	[thread overview]
Message-ID: <YsLDPnuC6dlROlj3@eidolon.nox.tf> (raw)
In-Reply-To: <80dd41cc-5ff2-f27f-3764-841acf008237@blackwall.org>

On Mon, Jul 04, 2022 at 01:22:36PM +0300, Nikolay Aleksandrov wrote:
> On 04/07/2022 12:58, David Lamparter wrote:
> > +const struct nla_policy rtm_ipv6_mr_policy[RTA_MAX + 1] = {
> > +	[RTA_UNSPEC]		= { .strict_start_type = RTA_UNSPEC },
> 
> I don't think you need to add RTA_UNSPEC, nlmsg_parse() would reject
> it due to NL_VALIDATE_STRICT

Will remove it.

> > +	if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*rtm))) {
> > +		NL_SET_ERR_MSG(extack, "ipv6: Invalid header for multicast route get request");
> > +		return -EINVAL;
> > +	}
> 
> I think you can drop this check if you...
> 
> > +
> > +	rtm = nlmsg_data(nlh);
> > +	if ((rtm->rtm_src_len && rtm->rtm_src_len != 128) ||
> > +	    (rtm->rtm_dst_len && rtm->rtm_dst_len != 128) ||
> > +	    rtm->rtm_tos || rtm->rtm_table || rtm->rtm_protocol ||
> > +	    rtm->rtm_scope || rtm->rtm_type || rtm->rtm_flags) {
> > +		NL_SET_ERR_MSG(extack,
> > +			       "ipv6: Invalid values in header for multicast route get request");
> > +		return -EINVAL;
> > +	}
> 
> ...move these after nlmsg_parse() because it already does the hdrlen
> check for you

Indeed it does.  Moving it down.

[...]
> > +	/* rtm_ipv6_mr_policy does not list other attributes right now, but
> > +	 * future changes may reuse rtm_ipv6_mr_policy with adding further
> > +	 * attrs.  Enforce the subset.
> > +	 */
> > +	for (i = 0; i <= RTA_MAX; i++) {
> > +		if (!tb[i])
> > +			continue;
> > +
> > +		switch (i) {
> > +		case RTA_SRC:
> > +		case RTA_DST:
> > +		case RTA_TABLE:
> > +			break;
> > +		default:
> > +			NL_SET_ERR_MSG_ATTR(extack, tb[i],
> > +					    "ipv6: Unsupported attribute in multicast route get request");
> > +			return -EINVAL;
> > +		}
> > +	}
> 
> I think you can skip this loop as well, nlmsg_parse() shouldn't allow attributes that
> don't have policy defined when policy is provided (i.e. they should show up as NLA_UNSPEC
> and you should get "Error: Unknown attribute type.").

I left it in with the comment above:

> > +	/* rtm_ipv6_mr_policy does not list other attributes right now, but
> > +	 * future changes may reuse rtm_ipv6_mr_policy with adding further
> > +	 * attrs.  Enforce the subset.
> > +	 */

... to try and avoid silently starting to accept more attributes if/when
future patches add other netlink operations reusing the same policy but
with adding new attributes.

But I don't feel particularly about this - shall I remove it?  (just
confirming with the rationale above)

> > +	struct net *net = sock_net(in_skb->sk);
> > +	struct nlattr *tb[RTA_MAX + 1];
> > +	struct sk_buff *skb = NULL;
> > +	struct mfc6_cache *cache;
> > +	struct mr_table *mrt;
> > +	struct in6_addr src = {}, grp = {};
> 
> reverse xmas tree order

Ah.  Wasn't aware of that coding style aspect.  Fixing.

Thanks for the review!


-David/equi

  reply	other threads:[~2022-07-04 10:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 13:30 [PATCH net-next 0/2] ip6mr: implement RTM_GETROUTE for single entry David Lamparter
2022-06-30 13:30 ` [PATCH 1/2] ipv6: make rtm_ipv6_policy available David Lamparter
2022-06-30 13:30 ` [PATCH 2/2] net: ip6mr: add RTM_GETROUTE netlink op David Lamparter
2022-07-01  3:27 ` [PATCH net-next 0/2] ip6mr: implement RTM_GETROUTE for single entry Jakub Kicinski
2022-07-01  7:58   ` [PATCH resend " David Lamparter
2022-07-01  7:58     ` [PATCH net-next 1/2] ipv6: make rtm_ipv6_policy available David Lamparter
2022-07-01  7:58     ` [PATCH net-next 2/2] net: ip6mr: add RTM_GETROUTE netlink op David Lamparter
2022-07-03 19:07       ` David Ahern
2022-07-04  8:35         ` David Lamparter
2022-07-04  9:58   ` [PATCH net-next v2] " David Lamparter
2022-07-04 10:22     ` Nikolay Aleksandrov
2022-07-04 10:38       ` David Lamparter [this message]
2022-07-04 10:44         ` Nikolay Aleksandrov
2022-07-04 10:52           ` [PATCH net-next v3] " David Lamparter
2022-07-05  2:50             ` Jakub Kicinski
2022-07-06  9:52               ` David Lamparter
2022-07-05  3:38     ` [PATCH net-next v2] " 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=YsLDPnuC6dlROlj3@eidolon.nox.tf \
    --to=equinox@diac24.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=razor@blackwall.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.