31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

28 Apr, 2019

2 commits

  • We currently have two levels of strict validation:

    1) liberal (default)
    - undefined (type >= max) & NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted
    - garbage at end of message accepted
    2) strict (opt-in)
    - NLA_UNSPEC attributes accepted
    - attribute length >= expected accepted

    Split out parsing strictness into four different options:
    * TRAILING - check that there's no trailing data after parsing
    attributes (in message or nested)
    * MAXTYPE - reject attrs > max known type
    * UNSPEC - reject attributes with NLA_UNSPEC policy entries
    * STRICT_ATTRS - strictly validate attribute size

    The default for future things should be *everything*.
    The current *_strict() is a combination of TRAILING and MAXTYPE,
    and is renamed to _deprecated_strict().
    The current regular parsing has none of this, and is renamed to
    *_parse_deprecated().

    Additionally it allows us to selectively set one of the new flags
    even on old policies. Notably, the UNSPEC flag could be useful in
    this case, since it can be arranged (by filling in the policy) to
    not be an incompatible userspace ABI change, but would then going
    forward prevent forgetting attribute entries. Similar can apply
    to the POLICY flag.

    We end up with the following renames:
    * nla_parse -> nla_parse_deprecated
    * nla_parse_strict -> nla_parse_deprecated_strict
    * nlmsg_parse -> nlmsg_parse_deprecated
    * nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
    * nla_parse_nested -> nla_parse_nested_deprecated
    * nla_validate_nested -> nla_validate_nested_deprecated

    Using spatch, of course:
    @@
    expression TB, MAX, HEAD, LEN, POL, EXT;
    @@
    -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
    +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, TB, MAX, POL, EXT;
    @@
    -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
    +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)

    @@
    expression TB, MAX, NLA, POL, EXT;
    @@
    -nla_parse_nested(TB, MAX, NLA, POL, EXT)
    +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)

    @@
    expression START, MAX, POL, EXT;
    @@
    -nla_validate_nested(START, MAX, POL, EXT)
    +nla_validate_nested_deprecated(START, MAX, POL, EXT)

    @@
    expression NLH, HDRLEN, MAX, POL, EXT;
    @@
    -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
    +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)

    For this patch, don't actually add the strict, non-renamed versions
    yet so that it breaks compile if I get it wrong.

    Also, while at it, make nla_validate and nla_parse go down to a
    common __nla_validate_parse() function to avoid code duplication.

    Ultimately, this allows us to have very strict validation for every
    new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
    next patch, while existing things will continue to work as is.

    In effect then, this adds fully strict validation for any new command.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
    netlink based interfaces (including recently added ones) are still not
    setting it in kernel generated messages. Without the flag, message parsers
    not aware of attribute semantics (e.g. wireshark dissector or libmnl's
    mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
    the structure of their contents.

    Unfortunately we cannot just add the flag everywhere as there may be
    userspace applications which check nlattr::nla_type directly rather than
    through a helper masking out the flags. Therefore the patch renames
    nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
    as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
    are rewritten to use nla_nest_start().

    Except for changes in include/net/netlink.h, the patch was generated using
    this semantic patch:

    @@ expression E1, E2; @@
    -nla_nest_start(E1, E2)
    +nla_nest_start_noflag(E1, E2)

    @@ expression E1, E2; @@
    -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
    +nla_nest_start(E1, E2)

    Signed-off-by: Michal Kubecek
    Acked-by: Jiri Pirko
    Acked-by: David Ahern
    Signed-off-by: David S. Miller

    Michal Kubecek
     

29 Oct, 2017

1 commit

  • Before this patch we had cases that either sent notifications when there
    were in fact no changes (e.g. non-existent vlan delete) or didn't send
    notifications when there were changes (e.g. vlan add range with an error in
    the middle, port flags change + vlan update error). This patch sends down
    a boolean to the functions setlink/dellink use and if there is even a
    single configuration change (port flag, vlan add/del, port state) then
    we always send a notification. This is all done to keep backwards
    compatibility with the opportunistic vlan delete, where one could
    specify a vlan range that has missing vlans inside and still everything
    in that range will be cleared, this is mostly used to clear the whole
    vlan config with a single call, i.e. range 1-4094.

    Signed-off-by: Nikolay Aleksandrov
    Acked-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Nikolay Aleksandrov
     

14 Apr, 2017

1 commit


09 Feb, 2017

1 commit

  • This fixes a bug and cleans up tunnelid range size
    calculation code by using consistent variable names
    and checks in size calculation and fill functions.

    tested for a few cases of vlan-vni range mappings:
    (output from patched iproute2):
    $bridge vlan showtunnel
    port vid tunid
    vxlan0 100-105 1000-1005
    200 2000
    210 2100
    211-213 2100-2102
    214 2104
    216-217 2108-2109
    219 2119

    Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
    Reported-by: Colin Ian King
    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu
     

08 Feb, 2017

2 commits

  • vtbegin should not be NULL in this function, Its already checked by the
    caller.

    this should silence the below smatch complaint:
    net/bridge/br_netlink_tunnel.c:144 br_fill_vlan_tinfo_range()
    error: we previously assumed 'vtbegin' could be null (see line 130)

    net/bridge/br_netlink_tunnel.c
    129
    130 if (vtbegin && vtend && (vtend->vid - vtbegin->vid) > 0) {
    ^^^^^^^
    Check for NULL.

    Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
    Reported-By: Dan Carpenter
    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu
     
  • These checks should go after the attributes have been parsed otherwise
    we're using tb uninitialized.

    Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
    Reported-by: Colin Ian King
    Signed-off-by: Nikolay Aleksandrov
    Signed-off-by: David S. Miller

    Nikolay Aleksandrov
     

04 Feb, 2017

1 commit

  • This patch adds support to attach per vlan tunnel info dst
    metadata. This enables bridge driver to map vlan to tunnel_info
    at ingress and egress. It uses the kernel dst_metadata infrastructure.

    The initial use case is vlan to vni bridging, but the api is generic
    to extend to any tunnel_info in the future:
    - Uapi to configure/unconfigure/dump per vlan tunnel data
    - netlink functions to configure vlan and tunnel_info mapping
    - Introduces bridge port flag BR_LWT_VLAN to enable attach/detach
    dst_metadata to bridged packets on ports. off by default.
    - changes to existing code is mainly refactor some existing vlan
    handling netlink code + hooks for new vlan tunnel code
    - I have kept the vlan tunnel code isolated in separate files.
    - most of the netlink vlan tunnel code is handling of vlan-tunid
    ranges (follows the vlan range handling code). To conserve space
    vlan-tunid by default are always dumped in ranges if applicable.

    Use case:
    example use for this is a vxlan bridging gateway or vtep
    which maps vlans to vn-segments (or vnis).

    iproute2 example (patched and pruned iproute2 output to just show
    relevant fdb entries):
    example shows same host mac learnt on two vni's and
    vlan 100 maps to vni 1000, vlan 101 maps to vni 1001

    before (netdev per vni):
    $bridge fdb show | grep "00:02:00:00:00:03"
    00:02:00:00:00:03 dev vxlan1001 vlan 101 master bridge
    00:02:00:00:00:03 dev vxlan1001 dst 12.0.0.8 self
    00:02:00:00:00:03 dev vxlan1000 vlan 100 master bridge
    00:02:00:00:00:03 dev vxlan1000 dst 12.0.0.8 self

    after this patch with collect metdata in bridged mode (single netdev):
    $bridge fdb show | grep "00:02:00:00:00:03"
    00:02:00:00:00:03 dev vxlan0 vlan 101 master bridge
    00:02:00:00:00:03 dev vxlan0 src_vni 1001 dst 12.0.0.8 self
    00:02:00:00:00:03 dev vxlan0 vlan 100 master bridge
    00:02:00:00:00:03 dev vxlan0 src_vni 1000 dst 12.0.0.8 self

    CC: Nikolay Aleksandrov
    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu