1. 16 7月, 2014 3 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen 提交于
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
    • T
      net: set name assign type for renamed devices · 238fa362
      Tom Gundersen 提交于
      Based on a patch from David Herrmann.
      
      This is the only place devices can be renamed.
      
      v9: restore revers-christmas-tree order of local variables
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      238fa362
    • T
      net: add name_assign_type netdev attribute · 685343fc
      Tom Gundersen 提交于
      Based on a patch by David Herrmann.
      
      The name_assign_type attribute gives hints where the interface name of a
      given net-device comes from. These values are currently defined:
        NET_NAME_ENUM:
          The ifname is provided by the kernel with an enumerated
          suffix, typically based on order of discovery. Names may
          be reused and unpredictable.
        NET_NAME_PREDICTABLE:
          The ifname has been assigned by the kernel in a predictable way
          that is guaranteed to avoid reuse and always be the same for a
          given device. Examples include statically created devices like
          the loopback device and names deduced from hardware properties
          (including being given explicitly by the firmware). Names
          depending on the order of discovery, or in any other way on the
          existence of other devices, must not be marked as PREDICTABLE.
        NET_NAME_USER:
          The ifname was provided by user-space during net-device setup.
        NET_NAME_RENAMED:
          The net-device has been renamed from userspace. Once this type is set,
          it cannot change again.
        NET_NAME_UNKNOWN:
          This is an internal placeholder to indicate that we yet haven't yet
          categorized the name. It will not be exposed to userspace, rather
          -EINVAL is returned.
      
      The aim of these patches is to improve user-space renaming of interfaces. As
      a general rule, userspace must rename interfaces to guarantee that names stay
      the same every time a given piece of hardware appears (at boot, or when
      attaching it). However, there are several situations where userspace should
      not perform the renaming, and that depends on both the policy of the local
      admin, but crucially also on the nature of the current interface name.
      
      If an interface was created in repsonse to a userspace request, and userspace
      already provided a name, we most probably want to leave that name alone. The
      main instance of this is wifi-P2P devices created over nl80211, which currently
      have a long-standing bug where they are getting renamed by udev. We label such
      names NET_NAME_USER.
      
      If an interface, unbeknown to us, has already been renamed from userspace, we
      most probably want to leave also that alone. This will typically happen when
      third-party plugins (for instance to udev, but the interface is generic so could
      be from anywhere) renames the interface without informing udev about it. A
      typical situation is when you switch root from an installer or an initrd to the
      real system and the new instance of udev does not know what happened before
      the switch. These types of problems have caused repeated issues in the past. To
      solve this, once an interface has been renamed, its name is labelled
      NET_NAME_RENAMED.
      
      In many cases, the kernel is actually able to name interfaces in such a
      way that there is no need for userspace to rename them. This is the case when
      the enumeration order of devices, or in fact any other (non-parent) device on
      the system, can not influence the name of the interface. Examples include
      statically created devices, or any naming schemes based on hardware properties
      of the interface. In this case the admin may prefer to use the kernel-provided
      names, and to make that possible we label such names NET_NAME_PREDICTABLE.
      We want the kernel to have tho possibilty of performing predictable interface
      naming itself (and exposing to userspace that it has), as the information
      necessary for a proper naming scheme for a certain class of devices may not
      be exposed to userspace.
      
      The case where renaming is almost certainly desired, is when the kernel has
      given the interface a name using global device enumeration based on order of
      discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM.
      
      Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has
      not yet been ported. This is mostly useful as a transitionary measure, allowing
      us to label the various naming schemes bit by bit.
      
      v8: minor documentation fixes
      v9: move comment to the right commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      685343fc
  2. 15 7月, 2014 3 次提交
  3. 14 7月, 2014 1 次提交
  4. 12 7月, 2014 5 次提交
  5. 11 7月, 2014 3 次提交
    • L
      ipv6: fix the check when handle RA · b6428817
      Li RongQing 提交于
      d9333196(ipv6:  Allow accepting RA from local IP addresses.) made the wrong
      check, whether or not to accept RA with source-addr found on local machine, when
      accept_ra_from_local is 0.
      
      Fixes: d9333196(ipv6:  Allow accepting RA from local IP addresses.)
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Hannes Frederic Sowa <hannes@redhat.com>
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6428817
    • J
      bridge: netlink dump interface at par with brctl · 5e6d2435
      Jamal Hadi Salim 提交于
      Actually better than brctl showmacs because we can filter by bridge
      port in the kernel.
      The current bridge netlink interface doesnt scale when you have many
      bridges each with large fdbs or even bridges with many bridge ports
      
      And now for the science non-fiction novel you have all been
      waiting for..
      
      //lets see what bridge ports we have
      root@moja-1:/configs/may30-iprt/bridge# ./bridge link show
      8: eth1 state DOWN : <BROADCAST,MULTICAST> mtu 1500 master br0 state
      disabled priority 32 cost 19
      17: sw1-p1 state DOWN : <BROADCAST,NOARP> mtu 1500 master br0 state
      disabled priority 32 cost 100
      
      // show all..
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show
      33:33:00:00:00:01 dev bond0 self permanent
      33:33:00:00:00:01 dev dummy0 self permanent
      33:33:00:00:00:01 dev ifb0 self permanent
      33:33:00:00:00:01 dev ifb1 self permanent
      33:33:00:00:00:01 dev eth0 self permanent
      01:00:5e:00:00:01 dev eth0 self permanent
      33:33:ff:22:01:01 dev eth0 self permanent
      02:00:00:12:01:02 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:05 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:07 dev eth1 self permanent
      33:33:00:00:00:01 dev eth1 self permanent
      33:33:00:00:00:01 dev gretap0 self permanent
      da:ac:46:27:d9:53 dev sw1-p1 vlan 0 master br0 permanent
      33:33:00:00:00:01 dev sw1-p1 self permanent
      
      //filter by bridge
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show br br0
      02:00:00:12:01:02 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:05 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:07 dev eth1 self permanent
      33:33:00:00:00:01 dev eth1 self permanent
      da:ac:46:27:d9:53 dev sw1-p1 vlan 0 master br0 permanent
      33:33:00:00:00:01 dev sw1-p1 self permanent
      
      // bridge sw1 has no ports attached..
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show br sw1
      
      //filter by port
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show brport eth1
      02:00:00:12:01:02 vlan 0 master br0 permanent
      00:17:42:8a:b4:05 vlan 0 master br0 permanent
      00:17:42:8a:b4:07 self permanent
      33:33:00:00:00:01 self permanent
      
      // filter by port + bridge
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show br br0 brport
      sw1-p1
      da:ac:46:27:d9:53 vlan 0 master br0 permanent
      33:33:00:00:00:01 self permanent
      
      // for shits and giggles (as they say in New Brunswick), lets
      // change the mac that br0 uses
      // Note: a magical fdb entry with no brport is added ...
      root@moja-1:/configs/may30-iprt/bridge# ip link set dev br0 address
      02:00:00:12:01:04
      
      // lets see if we can see the unicorn ..
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show
      33:33:00:00:00:01 dev bond0 self permanent
      33:33:00:00:00:01 dev dummy0 self permanent
      33:33:00:00:00:01 dev ifb0 self permanent
      33:33:00:00:00:01 dev ifb1 self permanent
      33:33:00:00:00:01 dev eth0 self permanent
      01:00:5e:00:00:01 dev eth0 self permanent
      33:33:ff:22:01:01 dev eth0 self permanent
      02:00:00:12:01:02 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:05 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:07 dev eth1 self permanent
      33:33:00:00:00:01 dev eth1 self permanent
      33:33:00:00:00:01 dev gretap0 self permanent
      02:00:00:12:01:04 dev br0 vlan 0 master br0 permanent <=== there it is
      da:ac:46:27:d9:53 dev sw1-p1 vlan 0 master br0 permanent
      33:33:00:00:00:01 dev sw1-p1 self permanent
      
      //can we see it if we filter by bridge?
      root@moja-1:/configs/may30-iprt/bridge# ./bridge fdb show br br0
      02:00:00:12:01:02 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:05 dev eth1 vlan 0 master br0 permanent
      00:17:42:8a:b4:07 dev eth1 self permanent
      33:33:00:00:00:01 dev eth1 self permanent
      02:00:00:12:01:04 dev br0 vlan 0 master br0 permanent <=== there it is
      da:ac:46:27:d9:53 dev sw1-p1 vlan 0 master br0 permanent
      33:33:00:00:00:01 dev sw1-p1 self permanent
      Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e6d2435
    • J
      bridge: fdb dumping takes a filter device · 5d5eacb3
      Jamal Hadi Salim 提交于
      Dumping a bridge fdb dumps every fdb entry
      held. With this change we are going to filter
      on selected bridge port.
      Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d5eacb3
  6. 10 7月, 2014 2 次提交
  7. 09 7月, 2014 23 次提交