1. 04 Mar, 2015 19 commits
    • Ben Hutchings's avatar
      sh_eth: Mitigate lost statistics updates · 4398f9c8
      Ben Hutchings authored
      The statistics registers have write-clear behaviour, which means we
      will lose any increment between the read and write.  Mitigate this by
      only clearing when we read a non-zero value, so we will never falsely
      report a total of zero.  This also saves time as we only handle
      error statistics here and they won't often be incremented.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4398f9c8
    • Ben Hutchings's avatar
    • Ben Hutchings's avatar
      sh_eth: Implement ethtool register dump operations · 6b4b4fea
      Ben Hutchings authored
      There are many different sets of registers implemented by the
      different versions of this controller, and we can only expect this to
      get more complicated in future.  Limit how much ethtool needs to know
      by including an explicit bitmap of which registers are included in the
      dump, allowing room for future growth in the number of possible
      registers.
      
      As I don't have datasheets for all of these, I've only included
      registers that are:
      
      - defined in all 5 register type arrays, or
      - used by the driver, or
      - documented in the datasheet I have
      
      Add one new capability flag so we can tell whether the RTRATE
      register is implemented.
      
      Delete the TSU_ADRL0 and TSU_ADR{H,L}31 definitions, as they weren't
      used and the address table is already assumed to be contiguous.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b4b4fea
    • Ben Hutchings's avatar
      sh_eth: WARN on access to a register not implemented in a particular chip · 3365711d
      Ben Hutchings authored
      Currently we may silently read/write a register at offset 0.  Change
      this to WARN and then ignore the write or read-back all-ones.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3365711d
    • Ben Hutchings's avatar
      sh_eth: Implement multicast statistic based on the RFS8 status bit · 25b77ad7
      Ben Hutchings authored
      At least on the R8A7790, RFS8 reflects the RINT8 (multicast) MAC
      status flag.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25b77ad7
    • David S. Miller's avatar
      Merge branch 'basic-mpls-support' · 27db730c
      David S. Miller authored
      Eric W. Biederman says:
      
      ====================
      Basic MPLS support take 2
      
      On top of my two pending neighbour table prep patches here is the mpls
      support refactored to use them, and edited to not drop routes when
      an interface goes down.  Additionally the addition of RTA_LLGATEWAY
      has been replaced with the addtion of RTA_VIA.  RTA_VIA being an
      attribute that includes the address family as well as the address
      of the next hop.
      
      MPLS is at it's heart simple and I have endeavoured to maintain that
      simplicity in my implemenation.
      
      This is an implementation of a RFC3032 forwarding engine, and basic MPLS
      egress logic.  Which should make linux sufficient to be a mpls
      forwarding node or to be a LSA (Label Switched Router) as it says in all
      of the MPLS documents.  The ingress support will follow but it deserves
      it's own discussion so I am pushing it separately.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27db730c
    • Eric W. Biederman's avatar
      mpls: Multicast route table change notifications · 8de147dc
      Eric W. Biederman authored
      Unlike IPv4 this code notifies on all cases where mpls routes
      are added or removed and it never automatically removes routes.
      Avoiding both the userspace confusion that is caused by omitting
      route updates and the possibility of a flood of netlink traffic
      when an interface goes doew.
      
      For now reserved labels are handled automatically and userspace
      is not notified.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8de147dc
    • Eric W. Biederman's avatar
      mpls: Netlink commands to add, remove, and dump routes · 03c05665
      Eric W. Biederman authored
      This change adds two new netlink routing attributes:
      RTA_VIA and RTA_NEWDST.
      
      RTA_VIA specifies the specifies the next machine to send a packet to
      like RTA_GATEWAY.  RTA_VIA differs from RTA_GATEWAY in that it
      includes the address family of the address of the next machine to send
      a packet to.  Currently the MPLS code supports addresses in AF_INET,
      AF_INET6 and AF_PACKET.  For AF_INET and AF_INET6 the destination mac
      address is acquired from the neighbour table.  For AF_PACKET the
      destination mac_address is specified in the netlink configuration.
      
      I think raw destination mac address support with the family AF_PACKET
      will prove useful.  There is MPLS-TP which is defined to operate
      on machines that do not support internet packets of any flavor.  Further
      seem to be corner cases where it can be useful.  At this point
      I don't care much either way.
      
      RTA_NEWDST specifies the destination address to forward the packet
      with.  MPLS typically changes it's destination address at every hop.
      For a swap operation RTA_NEWDST is specified with a length of one label.
      For a push operation RTA_NEWDST is specified with two or more labels.
      For a pop operation RTA_NEWDST is not specified or equivalently an emtpy
      RTAN_NEWDST is specified.
      
      Those new netlink attributes are used to implement handling of rt-netlink
      RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE messages, to maintain the
      MPLS label table.
      
      rtm_to_route_config parses a netlink RTM_NEWROUTE or RTM_DELROUTE message,
      verify no unhandled attributes or unhandled values are present and sets
      up the data structures for mpls_route_add and mpls_route_del.
      
      I did my best to match up with the existing conventions with the caveats
      that MPLS addresses are all destination-specific-addresses, and so
      don't properly have a scope.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03c05665
    • Eric W. Biederman's avatar
      mpls: Functions for reading and wrinting mpls labels over netlink · 966bae33
      Eric W. Biederman authored
      Reading and writing addresses in network byte order in netlink is
      traditional and I see no reason to change that.  MPLS is interesting
      as effectively it has variabely length addresses (the MPLS label
      stack).  To represent these variable length addresses in netlink
      I use a valid MPLS label stack (complete with stop bit).
      
      This achieves two things: a well defined existing format is used,
      and the data can be interpreted without looking at it's length.
      
      Not needed to look at the length to decode the variable length
      network representation allows existing userspace functions
      such as inet_ntop to be used without needed to change their
      prototype.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      966bae33
    • Eric W. Biederman's avatar
      mpls: Basic support for adding and removing routes · a2519929
      Eric W. Biederman authored
      mpls_route_add and mpls_route_del implement the basic logic for adding
      and removing Next Hop Label Forwarding Entries from the MPLS input
      label map.  The addition and subtraction is done in a way that is
      consistent with how the existing routing table in Linux are
      maintained.  Thus all of the work to deal with NLM_F_APPEND,
      NLM_F_EXCL, NLM_F_REPLACE, and NLM_F_CREATE.
      
      Cases that are not clearly defined such as changing the interpretation
      of the mpls reserved labels is not allowed.
      
      Because it seems like the right thing to do adding an MPLS route without
      specifying an input label and allowing the kernel to pick a free label
      table entry is supported.   The implementation is currently less than optimal
      but that can be changed.
      
      As I don't have anything else to test with only ethernet and the loopback
      device are the only two device types currently supported for forwarding
      MPLS over.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2519929
    • Eric W. Biederman's avatar
      mpls: Add a sysctl to control the size of the mpls label table · 7720c01f
      Eric W. Biederman authored
      This sysctl gives two benefits.  By defaulting the table size to 0
      mpls even when compiled in and enabled defaults to not forwarding
      any packets.  This prevents unpleasant surprises for users.
      
      The other benefit is that as mpls labels are allocated locally a dense
      table a small dense label table may be used which saves memory and
      is extremely simple and efficient to implement.
      
      This sysctl allows userspace to choose the restrictions on the label
      table size userspace applications need to cope with.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7720c01f
    • Eric W. Biederman's avatar
      mpls: Basic routing support · 0189197f
      Eric W. Biederman authored
      This change adds a new Kconfig option MPLS_ROUTING.
      
      The core of this change is the code to look at an mpls packet received
      from another machine.  Look that packet up in a routing table and
      forward the packet on.
      
      Support of MPLS over ATM is not considered or attempted here.  This
      implemntation follows RFC3032 and implements the MPLS shim header that
      can pass over essentially any network.
      
      What RFC3021 refers to as the as the Incoming Label Map (ILM) I call
      net->mpls.platform_label[].  What RFC3031 refers to as the Next Label
      Hop Forwarding Entry (NHLFE) I call mpls_route.  Though calling it the
      label fordwarding information base (lfib) might also be valid.
      
      Further the implemntation forwards packets as described in RFC3032.
      There is no need and given the original motivation for MPLS a strong
      discincentive to have a flexible label forwarding path.  In essence
      the logic is the topmost label is read, looked up, removed, and
      replaced by 0 or more new lables and the sent out the specified
      interface to it's next hop.
      
      Quite a few optional features are not implemented here.  Among them
      are generation of ICMP errors when the TTL is exceeded or the packet
      is larger than the next hop MTU (those conditions are detected and the
      packets are dropped instead of generating an icmp error).  The traffic
      class field is always set to 0.  The implementation focuses on IP over
      MPLS and does not handle egress of other kinds of protocols.
      
      Instead of implementing coordination with the neighbour table and
      sorting out how to input next hops in a different address family (for
      which there is value).  I was lazy and implemented a next hop mac
      address instead.  The code is simpler and there are flavor of MPLS
      such as MPLS-TP where neither an IPv4 nor an IPv6 next hop is
      appropriate so a next hop by mac address would need to be implemented
      at some point.
      
      Two new definitions AF_MPLS and PF_MPLS are exposed to userspace.
      
      Decoding the mpls header must be done by first byeswapping a 32bit bit
      endian word into the local cpu endian and then bit shifting to extract
      the pieces.  There is no C bit-field that can represent a wire format
      mpls header on a little endian machine as the low bits of the 20bit
      label wind up in the wrong half of third byte.  Therefore internally
      everything is deal with in cpu native byte order except when writing
      to and reading from a packet.
      
      For management simplicity if a label is configured to forward out
      an interface that is down the packet is dropped early.  Similarly
      if an network interface is removed rt_dev is updated to NULL
      (so no reference is preserved) and any packets for that label
      are dropped.  Keeping the label entries in the kernel allows
      the kernel label table to function as the definitive source
      of which labels are allocated and which are not.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0189197f
    • Eric W. Biederman's avatar
      mpls: Refactor how the mpls module is built · cec9166c
      Eric W. Biederman authored
      This refactoring is needed to allow more than just mpls gso
      support to be built into the mpls moddule.
      Reviewed-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cec9166c
    • David S. Miller's avatar
      Merge branch 'neigh-mpls-prep' · ee23393b
      David S. Miller authored
      Eric W. Biederman says:
      
      ====================
      Neighbour table prep for MPLS
      
      In preparation for using the IPv4 and IPv6 neighbour tables in my mpls
      code this patchset factors out ___neigh_lookup_noref from
      __ipv4_neigh_lookup_noref, __ipv6_lookup_noref and neigh_lookup.
      Allowing the lookup logic to be shared between the different
      implementations.  At what appears to be no cost. (Aka the same assembly
      is generated for ip6_finish_output2 and ip_finish_output2).
      
      After that I add a simple function that takes an address family and an
      address consults the neighbour table and sends the packet to the
      appropriate location.  The address family argument decoupls callers
      of neigh_xmit from the addresses families the packets are sent over.
      (Aka The ipv6 module can be loaded after mpls and a previously
      configured ipv6 next hop will start working).
      
      The refactoring in ___neigh_lookup_noref may be a bit overkill but it
      feels like the right thing to do.  Especially since the same code is
      generated.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee23393b
    • Eric W. Biederman's avatar
      neigh: Add helper function neigh_xmit · 4fd3d7d9
      Eric W. Biederman authored
      For MPLS I am building the code so that either the neighbour mac
      address can be specified or we can have a next hop in ipv4 or ipv6.
      
      The kind of next hop we have is indicated by the neighbour table
      pointer.  A neighbour table pointer of NULL is a link layer address.
      A non-NULL neighbour table pointer indicates which neighbour table and
      thus which address family the next hop address is in that we need to
      look up.
      
      The code either sends a packet directly or looks up the appropriate
      neighbour table entry and sends the packet.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fd3d7d9
    • Eric W. Biederman's avatar
      neigh: Factor out ___neigh_lookup_noref · 60395a20
      Eric W. Biederman authored
      While looking at the mpls code I found myself writing yet another
      version of neigh_lookup_noref.  We currently have __ipv4_lookup_noref
      and __ipv6_lookup_noref.
      
      So to make my work a little easier and to make it a smidge easier to
      verify/maintain the mpls code in the future I stopped and wrote
      ___neigh_lookup_noref.  Then I rewote __ipv4_lookup_noref and
      __ipv6_lookup_noref in terms of this new function.  I tested my new
      version by verifying that the same code is generated in
      ip_finish_output2 and ip6_finish_output2 where these functions are
      inlined.
      
      To get to ___neigh_lookup_noref I added a new neighbour cache table
      function key_eq.  So that the static size of the key would be
      available.
      
      I also added __neigh_lookup_noref for people who want to to lookup
      a neighbour table entry quickly but don't know which neibhgour table
      they are going to look up.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60395a20
    • Johannes Berg's avatar
      bridge: fix bridge netlink RCU usage · 2f56f6be
      Johannes Berg authored
      When the STP timer fires, it can call br_ifinfo_notify(),
      which in turn ends up in the new br_get_link_af_size().
      This function is annotated to be using RTNL locking, which
      clearly isn't the case here, and thus lockdep warns:
      
        ===============================
        [ INFO: suspicious RCU usage. ]
        3.19.0+ #569 Not tainted
        -------------------------------
        net/bridge/br_private.h:204 suspicious rcu_dereference_protected() usage!
      
      Fix this by doing RCU locking here.
      
      Fixes: b7853d73 ("bridge: add vlan info to bridge setlink and dellink notification messages")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f56f6be
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 71a83a6d
      David S. Miller authored
      Conflicts:
      	drivers/net/ethernet/rocker/rocker.c
      
      The rocker commit was two overlapping changes, one to rename
      the ->vport member to ->pport, and another making the bitmask
      expression use '1ULL' instead of plain '1'.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71a83a6d
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next · b97526f3
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2015-03-03
      
      This series contains updates to fm10k, i40e and i40evf.
      
      Matthew updates the fm10k driver by cleaning up code comments and whitespace
      issues.  Also modifies the tunnel length header check, to make it more robust
      by calculating the inner L4 header length based on whether it is TCP or UDP.
      Implemented ndo_features_check() that allows drivers to report their offload
      capabilities per-skb.
      
      Neerav updates the i40e driver to skip over priority tagging if DCB is not
      enabled.  Fixes an issue where the driver is not flushing out the
      DCBNL app table for applications that are not present in the local DCBX
      application configuration TLVs.  Fixed i40e where, in the case of MFP
      mode, the driver was returning the incorrect number of traffic classes
      for partitions that are not enabled for iSCSI.  Even though the driver
      was not configuring these traffic classes in the transmit scheduler for
      the NIC partitions, it does use this map to setup the queue mappings.
      
      Shannon updates i40e/i40evf to include the firmware build number in the
      formatted firmware version string.
      
      Akeem adds a safety net (by adding a 'default' case) for the possible
      unmatched switch calls.
      
      Mitch updates i40e to not automatically disable PF loopback at runtime,
      now that we have the functionality to enable and disable PF loopback.  This
      fix cleans up a bogus error message when removing the PF module with VFs
      enabled.  Adds a extra check to make sure that the indirection table
      pointer is valid before dereferencing it.
      
      Anjali enables i40e to enable more than the max RSS qps when running in a
      single TC mode for the main VSI.  It is possible to enable as many as
      num_online_cpus().  Adds a firmware check to ensure that DCB is disabled for
      firmware versions older than 4.33.  Updates i40e/i40evf to add missing
      packet types for VXLAN offload.  Updated i40e to be able to handle varying
      RSS table size for each VSI, since all VSI's do not have the same RSS table
      size.
      
      v2: Dropped previous patch #9 "i40e/i40evf: Add capability to gather VEB
          per TC stats" since the stats should be in ethtool and not debugfs.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b97526f3
  2. 03 Mar, 2015 21 commits