All of lore.kernel.org
 help / color / mirror / Atom feed
From: roopa <roopa@cumulusnetworks.com>
To: Scott Feldman <sfeldma@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
	shemminger@vyatta.com,
	"vyasevic@redhat.com" <vyasevic@redhat.com>,
	Wilson kok <wkok@cumulusnetworks.com>
Subject: Re: [PATCH 3/6] bridge: modify IFLA_AF_SPEC parser to parse IFLA_BRIDGE_VLAN_RANGE_INFO
Date: Mon, 29 Dec 2014 15:19:57 -0800	[thread overview]
Message-ID: <54A1E19D.8080200@cumulusnetworks.com> (raw)
In-Reply-To: <CAE4R7bA5ZhwX=agK-BOPWoJ1sctQuVcJ92z78Rrtp-=pBWi4jg@mail.gmail.com>

On 12/29/14, 2:04 PM, Scott Feldman wrote:
> On Mon, Dec 29, 2014 at 1:05 PM,  <roopa@cumulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This patch modifies br_afspec to parse incoming IFLA_BRIDGE_VLAN_RANGE_INFO
>>
>> Signed-off-by: Wilson kok <wkok@cumulusnetworks.com>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>>   net/bridge/br_netlink.c |   70 +++++++++++++++++++++++++++++++++--------------
>>   1 file changed, 49 insertions(+), 21 deletions(-)
>>
>> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>> index e7d1fc0..4c47ba0 100644
>> --- a/net/bridge/br_netlink.c
>> +++ b/net/bridge/br_netlink.c
>> @@ -227,48 +227,76 @@ static const struct nla_policy ifla_br_policy[IFLA_MAX+1] = {
>>                           .len = sizeof(struct bridge_vlan_range_info), },
>>   };
>>
>> +static int br_afspec_vlan_add(struct net_bridge *br,
>> +                             struct net_bridge_port *p,
>> +                             u16 vid, u16 flags)
>> +{
>> +       int err = 0;
>> +
>> +       if (p) {
>> +               err = nbp_vlan_add(p, vid, flags);
>> +               if (err)
>> +                       return err;
>> +
>> +               if (flags & BRIDGE_VLAN_INFO_MASTER)
>> +                       err = br_vlan_add(p->br, vid, flags);
>> +       } else {
>> +               err = br_vlan_add(br, vid, flags);
>> +       }
>> +
>> +       return err;
>> +}
>> +
>> +static void br_afspec_vlan_del(struct net_bridge *br,
>> +                              struct net_bridge_port *p,
>> +                              u16 vid, u16 flags)
>> +{
>> +       if (p) {
>> +               nbp_vlan_delete(p, vid);
>> +               if (flags & BRIDGE_VLAN_INFO_MASTER)
>> +                       br_vlan_delete(p->br, vid);
>> +       } else {
>> +               br_vlan_delete(br, vid);
>> +       }
>> +}
>> +
>>   static int br_afspec(struct net_bridge *br,
>>                       struct net_bridge_port *p,
>>                       struct nlattr *af_spec,
>>                       int cmd)
>>   {
>> -       struct bridge_vlan_info *vinfo;
>> -       int err = 0;
>> +       struct bridge_vlan_range_info *vinfo;
>>          struct nlattr *attr;
>>          int err = 0;
>>          int rem;
>>          u16 vid;
>>
>>          nla_for_each_nested(attr, af_spec, rem) {
>> -               if (nla_type(attr) != IFLA_BRIDGE_VLAN_INFO)
>> +               if (nla_type(attr) != IFLA_BRIDGE_VLAN_INFO &&
>> +                   nla_type(attr) != IFLA_BRIDGE_VLAN_RANGE_INFO)
>>                          continue;
>> -
>>                  vinfo = nla_data(attr);
> Check attr size.
>
>> -               if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
>> +
>> +               if (nla_type(attr) == IFLA_BRIDGE_VLAN_INFO)
>> +                       vinfo->vid_end = vinfo->vid;
> Maybe a switch(nla_type(attr)) would be better to explicitly handle
> each case?  Then the size check can be done for each case, as well as
> this fix-up for vid_end.

sure, i can do that.
>
>> +
>> +               if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK ||
>> +                   vinfo->vid_end >= VLAN_VID_MASK ||
>> +                   vinfo->vid > vinfo->vid_end)
>>                          return -EINVAL;
>>
>>                  switch (cmd) {
>>                  case RTM_SETLINK:
>> -                       if (p) {
>> -                               err = nbp_vlan_add(p, vinfo->vid, vinfo->flags);
>> +                       for (vid = vinfo->vid; vid <= vinfo->vid_end; vid++) {
>> +                               err = br_afspec_vlan_add(br, p, vid,
>> +                                                        vinfo->flags);
>>                                  if (err)
> Do you want to unwind on failure?  Seems it should be an
> all-or-nothing operation.

I could, but looking at other link operations, I don't seen anybody 
unwinding.  An AF_UNSPEC link netlink request can contain multiple link 
attributes and not all maybe applied AFAICS. But i don't have a strong 
opinion here.  I can unwind if needed.
>>                                          break;
>> -
>> -                               if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
>> -                                       err = br_vlan_add(p->br, vinfo->vid,
>> -                                                         vinfo->flags);
>> -                       } else
>> -                               err = br_vlan_add(br, vinfo->vid, vinfo->flags);
>> -
>> +                       }
>>                          break;
>> -
>>                  case RTM_DELLINK:
>> -                       if (p) {
>> -                               nbp_vlan_delete(p, vinfo->vid);
>> -                               if (vinfo->flags & BRIDGE_VLAN_INFO_MASTER)
>> -                                       br_vlan_delete(p->br, vinfo->vid);
>> -                       } else
>> -                               br_vlan_delete(br, vinfo->vid);
>> +                       for (vid = vinfo->vid; vid <= vinfo->vid_end; vid++)
>> +                               br_afspec_vlan_del(br, p, vid, vinfo->flags);
>>                          break;
>>                  }
>>          }
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-12-29 23:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-29 21:05 [PATCH 3/6] bridge: modify IFLA_AF_SPEC parser to parse IFLA_BRIDGE_VLAN_RANGE_INFO roopa
2014-12-29 22:04 ` Scott Feldman
2014-12-29 23:19   ` roopa [this message]
2014-12-30  8:40 ` Arad, Ronen
2014-12-30 14:17   ` roopa
2014-12-30 19:23     ` Arad, Ronen

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=54A1E19D.8080200@cumulusnetworks.com \
    --to=roopa@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=sfeldma@gmail.com \
    --cc=shemminger@vyatta.com \
    --cc=vyasevic@redhat.com \
    --cc=wkok@cumulusnetworks.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 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.