17 Dec, 2018

1 commit


13 Sep, 2018

1 commit


02 Nov, 2017

1 commit

  • Many user space API headers are missing licensing information, which
    makes it hard for compliance tools to determine the correct license.

    By default are files without license information under the default
    license of the kernel, which is GPLV2. Marking them GPLV2 would exclude
    them from being included in non GPLV2 code, which is obviously not
    intended. The user space API headers fall under the syscall exception
    which is in the kernels COPYING file:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".

    otherwise syscall usage would not be possible.

    Update the files which contain no license information with an SPDX
    license identifier. The chosen identifier is 'GPL-2.0 WITH
    Linux-syscall-note' which is the officially assigned identifier for the
    Linux syscall exception. SPDX license identifiers are a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne. See the previous patch in this series for the
    methodology of how this patch was researched.

    Reviewed-by: Kate Stewart
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

09 Jun, 2017

1 commit

  • When a new static FDB is added to the bridge a notification is sent to
    the driver for offload. In case of successful offload the driver should
    notify the bridge back, which in turn should mark the FDB as offloaded.

    Currently, externally learned is equivalent for being offloaded which is
    not correct due to the fact that FDBs which are added from user-space are
    also marked as externally learned. In order to specify if an FDB was
    successfully offloaded a new flag is introduced.

    Signed-off-by: Arkadi Sharshevsky
    Reviewed-by: Ido Schimmel
    Reviewed-by: Nikolay Aleksandrov
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Arkadi Sharshevsky
     

04 Feb, 2017

1 commit

  • Vxlan COLLECT_METADATA mode today solves the per-vni netdev
    scalability problem in l3 networks. It expects all forwarding
    information to be present in dst_metadata. This patch series
    enhances collect metadata mode to include the case where only
    vni is present in dst_metadata, and the vxlan driver can then use
    the rest of the forwarding information datbase to make forwarding
    decisions. There is no change to default COLLECT_METADATA
    behaviour. These changes only apply to COLLECT_METADATA when
    used with the bridging use-case with a special dst_metadata
    tunnel info flag (eg: where vxlan device is part of a bridge).
    For all this to work, the vxlan driver will need to now support a
    single fdb table hashed by mac + vni. This series essentially makes
    this happen.

    use-case and workflow:
    vxlan collect metadata device participates in bridging vlan
    to vn-segments. Bridge driver above the vxlan device,
    sends the vni corresponding to the vlan in the dst_metadata.
    vxlan driver will lookup forwarding database with (mac + vni)
    for the required remote destination information to forward the
    packet.

    Changes introduced by this patch:
    - allow learning and forwarding database state in vxlan netdev in
    COLLECT_METADATA mode. Current behaviour is not changed
    by default. tunnel info flag IP_TUNNEL_INFO_BRIDGE is used
    to support the new bridge friendly mode.
    - A single fdb table hashed by (mac, vni) to allow fdb entries with
    multiple vnis in the same fdb table
    - rx path already has the vni
    - tx path expects a vni in the packet with dst_metadata
    - prior to this series, fdb remote_dsts carried remote vni and
    the vxlan device carrying the fdb table represented the
    source vni. With the vxlan device now representing multiple vnis,
    this patch adds a src vni attribute to the fdb entry. The remote
    vni already uses NDA_VNI attribute. This patch introduces
    NDA_SRC_VNI netlink attribute to represent the src vni in a multi
    vni fdb table.

    iproute2 example (patched and pruned iproute2 output to just show
    relevant fdb entries):
    example shows same host mac learnt on two vni's.

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

    after this patch with collect metadata in bridged mode (single netdev):
    $bridge fdb show | grep "00:02:00:00:00:03"
    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 src_vni 1000 dst 12.0.0.8 self

    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu
     

24 Apr, 2016

1 commit


11 Aug, 2015

1 commit

  • Add an explicit neighbour table overflow message (ratelimited) and
    statistic to make diagnosing neighbour table overflows tractable in
    the wild.

    Diagnosing a neighbour table overflow can be quite difficult in the wild
    because there is no explicit dmesg logged. Callers to neighbour code
    seem to use net_dbg_ratelimit when the neighbour call fails which means
    the "base message" is not emitted and the callback suppressed messages
    from the ratelimiting can end-up juxtaposed with unrelated messages.
    Further, a forced garbage collection will increment a stat on each call
    whether it was successful in freeing-up a table entry or not, so that
    statistic is only a hint. So, add a net_info_ratelimited message and
    explicit statistic to the neighbour code.

    Signed-off-by: Rick Jones
    Signed-off-by: David S. Miller

    Rick Jones
     

21 Mar, 2015

1 commit

  • …itations in PROBE state.

    We send unicast neighbor (ARP or NDP) solicitations ucast_probes
    times in PROBE state. Zhu Yanjun reported that some implementation
    does not reply against them and the entry will become FAILED, which
    is undesirable.

    We had been dealt with such nodes by sending multicast probes mcast_
    solicit times after unicast probes in PROBE state. In 2003, I made
    a change not to send them to improve compatibility with IPv6 NDP.

    Let's introduce per-protocol per-interface sysctl knob "mcast_
    reprobe" to configure the number of multicast (re)solicitation for
    reconfirmation in PROBE state. The default is 0, since we have
    been doing so for 10+ years.

    Reported-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
    CC: Ulf Samuelsson <ulf.samuelsson@ericsson.com>
    Signed-off-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

    YOSHIFUJI Hideaki/吉藤英明
     

28 Jan, 2015

1 commit

  • Previous commit is based on a wrong assumption, fdb messages are always sent
    into the netns where the interface stands (see vxlan_fdb_notify()).

    These fdb messages doesn't embed the rtnl attribute IFLA_LINK_NETNSID, thus we
    need to add it (useful to interpret NDA_IFINDEX or NDA_DST for example).

    Note also that vxlan_nlmsg_size() was not updated.

    Fixes: 193523bf9373 ("vxlan: advertise netns of vxlan dev in fdb msg")
    Signed-off-by: Nicolas Dichtel
    Signed-off-by: David S. Miller

    Nicolas Dichtel
     

24 Jan, 2015

1 commit

  • Netlink FDB messages are sent in the link netns. The header of these messages
    contains the ifindex (ndm_ifindex) of the netdevice, but this ifindex is
    unusable in case of x-netns vxlan.
    I named the new attribute NDA_NDM_IFINDEX_NETNSID, to avoid confusion with
    NDA_IFINDEX.

    Signed-off-by: Nicolas Dichtel
    Signed-off-by: David S. Miller

    Nicolas Dichtel
     

03 Dec, 2014

2 commits

  • When the swdev device learns a new mac/vlan on a port, it sends some async
    notification to the driver and the driver installs an FDB in the device.
    To give a holistic system view, the learned mac/vlan should be reflected
    in the bridge's FBD table, so the user, using normal iproute2 cmds, can view
    what is currently learned by the device. This API on the bridge driver gives
    a way for the swdev driver to install an FBD entry in the bridge FBD table.
    (And remove one).

    This is equivalent to the device running these cmds:

    bridge fdb [add|del] dev vid master

    This patch needs some extra eyeballs for review, in paricular around the
    locking and contexts.

    Signed-off-by: Scott Feldman
    Signed-off-by: Jiri Pirko
    Acked-by: Jamal Hadi Salim
    Signed-off-by: David S. Miller

    Scott Feldman
     
  • Suggested-by: Florian Fainelli
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Jiri Pirko
     

03 Jun, 2014

1 commit

  • (This patch was previously posted as RFC at
    http://patchwork.ozlabs.org/patch/352677/)

    This patch adds NDA_MASTER attribute to neighbour attributes enum for
    bridge/master ifindex. And adds NDA_MASTER to bridge fdb notify msgs.

    Today bridge fdb notifications dont contain bridge information.
    Userspace can derive it from the port information in the fdb
    notification. However this is tricky in some scenarious.

    Example, bridge port delete notification comes before bridge fdb
    delete notifications. And we have seen problems in userspace
    when using libnl where, the bridge fdb delete notification handling code
    does not understand which bridge this fdb entry is part of because
    the bridge and port association has already been deleted.
    And these notifications (port membership and fdb) are generated on
    separate rtnl groups.

    Fixing the order of notifications could possibly solve the problem
    for some cases (I can submit a separate patch for that).

    This patch chooses to add NDA_MASTER to bridge fdb notify msgs
    because it not only solves the problem described above, but also helps
    userspace avoid another lookup into link msgs to derive the master index.

    Signed-off-by: Roopa Prabhu
    Acked-by: Jamal Hadi Salim
    Signed-off-by: David S. Miller

    Roopa Prabhu
     

22 Jan, 2014

1 commit


18 Mar, 2013

1 commit

  • This patch generalizes VXLAN forwarding table entries allowing an administrator
    to:
    1) specify multiple destinations for a given MAC
    2) specify alternate vni's in the VXLAN header
    3) specify alternate destination UDP ports
    4) use multicast MAC addresses as fdb lookup keys
    5) specify multicast destinations
    6) specify the outgoing interface for forwarded packets

    The combination allows configuration of more complex topologies using VXLAN
    encapsulation.

    Changes since v1: rebase to 3.9.0-rc2

    Signed-Off-By: David L Stevens

    Signed-off-by: David S. Miller

    David Stevens
     

14 Feb, 2013

1 commit

  • When a user adds bridge neighbors, allow him to specify VLAN id.
    If the VLAN id is not specified, the neighbor will be added
    for VLANs currently in the ports filter list. If no VLANs are
    configured on the port, we use vlan 0 and only add 1 entry.

    Signed-off-by: Vlad Yasevich
    Acked-by: Jitendra Kalsaria
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

13 Oct, 2012

1 commit