[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YlbDeNh7D+BHRscg@shredder>
Date: Wed, 13 Apr 2022 15:35:04 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Nikolay Aleksandrov <razor@...ckwall.org>
Cc: netdev@...r.kernel.org, dsahern@...nel.org, roopa@...dia.com,
kuba@...nel.org, davem@...emloft.net,
bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v4 07/12] net: rtnetlink: add NLM_F_BULK support
to rtnl_fdb_del
On Wed, Apr 13, 2022 at 03:21:54PM +0300, Nikolay Aleksandrov wrote:
> On 13/04/2022 15:20, Ido Schimmel wrote:
> > On Wed, Apr 13, 2022 at 01:51:57PM +0300, Nikolay Aleksandrov wrote:
> >> When NLM_F_BULK is specified in a fdb del message we need to handle it
> >> differently. First since this is a new call we can strictly validate the
> >> passed attributes, at first only ifindex and vlan are allowed as these
> >> will be the initially supported filter attributes, any other attribute
> >> is rejected. The mac address is no longer mandatory, but we use it
> >> to error out in older kernels because it cannot be specified with bulk
> >> request (the attribute is not allowed) and then we have to dispatch
> >> the call to ndo_fdb_del_bulk if the device supports it. The del bulk
> >> callback can do further validation of the attributes if necessary.
> >>
> >> Signed-off-by: Nikolay Aleksandrov <razor@...ckwall.org>
> >> ---
> >> v4: mark PF_BRIDGE/RTM_DELNEIGH with RTNL_FLAG_BULK_DEL_SUPPORTED
> >>
> >> net/core/rtnetlink.c | 67 +++++++++++++++++++++++++++++++-------------
> >> 1 file changed, 48 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> >> index 63c7df52a667..520d50fcaaea 100644
> >> --- a/net/core/rtnetlink.c
> >> +++ b/net/core/rtnetlink.c
> >> @@ -4169,22 +4169,34 @@ int ndo_dflt_fdb_del(struct ndmsg *ndm,
> >> }
> >> EXPORT_SYMBOL(ndo_dflt_fdb_del);
> >>
> >> +static const struct nla_policy fdb_del_bulk_policy[NDA_MAX + 1] = {
> >> + [NDA_VLAN] = { .type = NLA_U16 },
> >
> > In earlier versions br_vlan_valid_id() was used to validate the VLAN,
> > but I don't see it anymore. Maybe use
> >
> > NLA_POLICY_RANGE(1, VLAN_N_VID - 2)
> >
> > ?
> >
> > I realize that invalid values won't do anything, but I think it's better
> > to only allow valid ranges.
> >
>
> It's already validated below, see fdb_vid_parse().
Sorry, missed it :)
Powered by blists - more mailing lists