1. 07 3月, 2015 26 次提交
  2. 06 3月, 2015 14 次提交
    • S
      e1000: add dummy allocator to fix race condition between mtu change and netpoll · 08e83316
      Sabrina Dubroca 提交于
      There is a race condition between e1000_change_mtu's cleanups and
      netpoll, when we change the MTU across jumbo size:
      
      Changing MTU frees all the rx buffers:
          e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
              e1000_clean_rx_ring
      
      Then, close to the end of e1000_change_mtu:
          pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
              e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag
      
      And when we come back to do the rest of the MTU change:
          e1000_up -> e1000_configure -> e1000_configure_rx ->
              e1000_alloc_jumbo_rx_buffers
      
      alloc_jumbo finds the buffers already != NULL, since data (shared with
      page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
      or at least not what is expected when in jumbo state.
      
      This results in an unusable adapter (packets don't get through), and a
      NULL pointer dereference on the next call to e1000_clean_rx_ring
      (other mtu change, link down, shutdown):
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
      
          [...]
      
      Call Trace:
       [<ffffffff81195445>] put_page+0x55/0x60
       [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200
       [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60
       [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0
       [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840
       [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170
       [<ffffffff81647050>] dev_set_mtu+0xa0/0x140
       [<ffffffff81664218>] do_setlink+0x218/0xac0
       [<ffffffff814459e9>] ? nla_parse+0xb9/0x120
       [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890
       [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40
       [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100
       [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260
      
      By setting the allocator to a dummy version, netpoll can't mess up our
      rx buffers.  The allocator is set back to a sane value in
      e1000_configure_rx.
      
      Fixes: edbbb3ca ("e1000: implement jumbo receive with partial descriptors")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      08e83316
    • E
      e1000: call netif_carrier_off early on down · f9c029db
      Eliezer Tamir 提交于
      When bringing down an interface netif_carrier_off() should be
      one the first things we do, since this will prevent the stack
      from queuing more packets to this interface.
      This operation is very fast, and should make the device behave
      much nicer when trying to bring down an interface under load.
      
      Also, this would Do The Right Thing (TM) if this device has some
      sort of fail-over teaming and redirect traffic to the other IF.
      
      Move netif_carrier_off as early as possible.
      Signed-off-by: NEliezer Tamir <eliezer.tamir@linux.intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f9c029db
    • A
      igb: Make arrays on stack static const to avoid reallocation · b23c0cc5
      Alexander Duyck 提交于
      While addressing the pin problem I noticed that all of the pin register
      values where having to be pushed onto the stack each time the function was
      called.  To avoid that I am making them static const so that they should
      only need to be allocated once and we can avoid all the instructions to get
      them onto the stack..
      
      size before:
         text	   data	    bss	    dec	    hex	filename
       161477	  10512	      8	 171997	  29fdd	drivers/net/ethernet/intel/igb/igb.ko
      
      size after:
         text	   data	    bss	    dec	    hex	filename
       161205	  10512	      8	 171725	  29ecd	drivers/net/ethernet/intel/igb/igb.ko
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b23c0cc5
    • A
      igb: Fix warning pin may be used uninitialized · e357f0aa
      Alexander Duyck 提交于
      When building the kernel using the gcc 4.8.3 compiler included in Fedora 20
      I was repeatedly seeing the warning:
      
       drivers/net/ethernet/intel/igb/igb_ptp.c: In function ‘igb_ptp_feature_enable_i210’:
       drivers/net/ethernet/intel/igb/igb_ptp.c:395:21: warning: ‘pin’ may be used uninitialized in this function
       [-Wmaybe-uninitialized]
         tssdp &= ~ts_sdp_en[pin];
                           ^
       drivers/net/ethernet/intel/igb/igb_ptp.c:471:6: note: ‘pin’ was declared here
         int pin;
             ^
      
      To resolve it I am assigning the pin a value of -1 when it is instantiated.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e357f0aa
    • Y
      e1000e: remove calls to ioremap/unmap for NVM addr · 1103a631
      Yanir Lubetkin 提交于
      Starting I219, the NVM will not be mapped to its own BAR, but to an
      address region in another bar.  The mapping/unmapping is relevant
      to older HW only.
      
      CC: John W Linville <linville@tuxdriver.com>
      Reported-by: NJohn W Linville <linville@tuxdriver.com>
      Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1103a631
    • Y
      e1000e: fix obscure comments · 9d17ce49
      Yanir Lubetkin 提交于
      The interface to the device flash was modified in i219 and later HW.
      This patch better describes the change and the impact on the driver.
      
      CC: John W Linville <linville@tuxdriver.com>
      Reported-by: NJohn W Linville <linville@tuxdriver.com>
      Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9d17ce49
    • D
      ipv4: Fix unused variable warnings in fib_table_flush_external. · 23375a0f
      David S. Miller 提交于
      net/ipv4/fib_trie.c: In function ‘fib_table_flush_external’:
      net/ipv4/fib_trie.c:1572:6: warning: unused variable ‘found’ [-Wunused-variable]
        int found = 0;
            ^
      net/ipv4/fib_trie.c:1571:16: warning: unused variable ‘slen’ [-Wunused-variable]
        unsigned char slen;
                      ^
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23375a0f
    • D
      Merge branch 'l3_hw_offload' · fabe7bed
      David S. Miller 提交于
      Scott Feldman says:
      
      ====================
      switchdev: add IPv4 routing offload
      
      v4:
      
        - Add NETIF_F_NETNS_LOCAL to rocker port feature list to keep rocker
          ports in the default netns.  Rocker hardware can't be partitioned
          to support multiple namespaces, currently.  It would be interesting
          to add netns support to rocker device by basically adding another
          match field to each table to match on some unique netns ID, with
          a port knowing it's netns ID.  Future work TDB.
        - Up-level the RTNH_F_EXTERNAL marking of routes installed to offload
          device from driver to switchdev common code.  Now driver can't skip
          routes.  Either it can install the route or it cannot.  Yes or No.
          If no on any route, all offloading is aborted by removing routes
          from offload device and setting ipv4.fib_offload_disabled so no more
          routes can be offloaded.  This is harsh, but it's our starting point.
          We can refine the policies in follow-up work.
        - Add new net.ipv4.fib_offload_disabled bool that is set if anything
          goes wrong with route offloading.  We can refine this later to make
          the setting per-device or per-device-port-netdev, but let's start
          here simple and refine in follow-up work.
        - Rebase against Alex's latest FIB changes.  I think I did everything
          correctly, and didn't run into any issues with testing, but I'd like
          Alex to look over the changes and maybe follow-up with any cleanups.
      
      v3:
      
      Changes based on v2 review comments:
      
        - Move check for custom rules up earlier in patch set, to keep git bisect
          safe.
        - Simplify the route add/modify failure handling to simple try until
          failure, and then on failure, undo everything.  The switchdev driver
          will return err when route can normally be installed to device, but
          the install fails for one reason or another (no space left on device,
          etc).  If a failure happens, uninstall all routes from the device,
          punting forwarding for all routes back to the kernel.
        - Scan route's full nexthop list, ensuring all nexthop devs belong
          to the same switchdev device, otherwise don't try to install route
          to device.
      
      v2:
      
      Changes based on v1 review comments and discussions at netconf:
      
        - Allow route modification, but use same ndo op used for adding route.
          Driver/device is expected to modify route in-place, if it can, to avoid
          interruption of service.
        - Add new RTNH_F_EXTERNAL flag to mark FIB entries offloaded externally.
        - Don't offload routes if using custom IP rules.  If routes are already
          offloaded, and custom IP rules are turned on, flush routes from offload
          device.  (Offloaded routes are marked with RTNH_F_EXTERNAL).
        - Use kernel's neigh resolution code to resolve route's nexthops' neigh
          MAC addrs.  (Thanks davem, works great!).
        - Use fib->fib_priority in rocker driver to give priorities to routes in
          OF-DPA unicast route table.
      
      v1:
      
      This patch set adds L3 routing offload support for IPv4 routes.  The idea is to
      mirror routes installed in the kernel's FIB down to a hardware switch device to
      offload the data forwarding path for L3.  Only the data forwarding path is
      intercepted.  Control and management of the kernel's FIB remains with the
      kernel.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fabe7bed
    • S
      rocker: implement IPv4 fib offloading · c1beeef7
      Scott Feldman 提交于
      The driver implements ndo_switch_fib_ipv4_add/del ops to add/del/mod IPv4
      routes to/from switchdev device.  Once a route is added to the device, and the
      route's nexthops are resolved to neighbor MAC address, the device will forward
      matching pkts rather than the kernel.  This offloads the L3 forwarding path
      from the kernel to the device.  Note that control and management planes are
      still mananged by Linux; only the data plane is offloaded.  Standard routing
      control protocols such as OSPF and BGP run on Linux and manage the kernel's FIB
      via standard rtm netlink msgs...nothing changes here.
      
      A new hash table is added to rocker to track neighbors.  The driver listens for
      neighbor updates events using netevent notifier NETEVENT_NEIGH_UPDATE.  Any ARP
      table updates for ports on this device are recorded in this table.  Routes
      installed to the device with nexthops that reference neighbors in this table
      are "qualified".  In the case of a route with nexthops not resolved in the
      table, the kernel is asked to resolve the nexthop.
      
      The driver uses fib_info->fib_priority for the priority field in rocker's
      unicast routing table.
      
      The device can only forward to pkts matching route dst to resolved nexthops.
      Currently, the device only supports single-path routes (i.e. routes with one
      nexthop).  Equal Cost Multipath (ECMP) route support will be added in followup
      patches.
      
      This patch is driver support for unicast IPv4 routing only.  Followup patches
      will add driver and infrastructure for IPv6 routing and multicast routing.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1beeef7
    • S
      fib: hook IPv4 fib for hardware offload · 8e05fd71
      Scott Feldman 提交于
      Call into the switchdev driver any time an IPv4 fib entry is
      added/modified/deleted from the kernel's FIB.  The switchdev driver may or
      may not install the route to the offload device.  In the case where the
      driver tries to install the route and something goes wrong (device's routing
      table is full, etc), then all of the offloaded routes will be flushed from the
      device, route forwarding falls back to the kernel, and no more routes are
      offloading.
      
      We can refine this logic later.  For now, use the simplist model of offloading
      routes up to the point of failure, and then on failure, undo everything and
      mark IPv4 offloading disabled.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e05fd71
    • S
      ipv4: add net bool fib_offload_disabled · 448b128a
      Scott Feldman 提交于
      If something goes wrong with IPv4 FIB offload, mark entire net offload
      disabled.  This is brute force policy to basically shut down IPv4 FIB offload
      permanently if there is a problem offloading any route to an external device.
      We can refine the policy in the future, to handle failures on a per-device or
      per-route basis, but for now, this policy is per-net.
      
      What we're trying to avoid is an inconsistent split between the kernel's FIB
      and the offload device's FIB.  We don't want the device to fwd a pkt
      inconsitent with what the kernel would do.  An example of a split is if device
      has 10.0.0.0/16 and kernel has 10.0.0.0/16 and 10.0.0.0/24, the device wouldn't
      see the longest prefix 10.0.0.0/24 and potentially forward pkts incorrectly.
      
      Limited capacity or limited capability are two ways a route may fail to install
      to the offload device.  We'll not differentiate between failures at this time,
      and treat any failure as fatal and mark the net as fib_offload_disabled.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      448b128a
    • S
      switchdev: implement IPv4 fib ndo wrappers · b5d6fbde
      Scott Feldman 提交于
      Flesh out ndo wrappers to call into device driver.  To call into device driver,
      the wrapper must interate over route's nexthops to ensure all nexthop devs
      belong to the same switch device.  Currently, there is no support for route's
      nexthops spanning offloaded and non-offloaded devices, or spanning ports of
      multiple offload devices.
      
      Since switch device ports may be stacked under virtual interfaces (bonds and/or
      bridges), and the route's nexthop may be on the virtual interface, the wrapper
      will traverse the nexthop dev down to the base dev.  It's the base dev that's
      passed to the switchdev driver's ndo ops.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5d6fbde
    • S
      switchdev: don't support custom ip rules, for now · 104616e7
      Scott Feldman 提交于
      Keep switchdev FIB offload model simple for now and don't allow custom ip
      rules.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      104616e7
    • S
      switchdev: add IPv4 fib ndo ops wrappers · 5e8d9049
      Scott Feldman 提交于
      Add IPv4 fib ndo wrapper funcs and stub them out for now.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e8d9049