1. 12 Jun, 2017 3 commits
    • Jacob Keller's avatar
      i40e: fix handling of HW ATR eviction · 6964e53f
      Jacob Keller authored
      A recent commit to refactor the driver and remove the hw_disabled_flags
      field accidentally introduced two regressions. First, we overwrote
      pf->flags which removed various key flags including the MSI-X settings.
      
      Additionally, it was intended that we have now two flags,
      HW_ATR_EVICT_CAPABLE and HW_ATR_EVICT_ENABLED, but this was not done,
      and we accidentally were mis-using HW_ATR_EVICT_CAPABLE everywhere.
      
      This patch adds the missing piece, HW_ATR_EVICT_ENABLED, and safely
      updates pf->flags instead of overwriting it.
      
      Without this patch we will have many problems including disabling MSI-X
      support, and we'll attempt to use HW ATR eviction on devices which do
      not support it.
      
      Fixes: 47994c11 ("i40e: remove hw_disabled_flags in favor of using separate flag bits", 2017-04-19)
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6964e53f
    • Karicheri, Muralidharan's avatar
      hsr: fix incorrect warning · 675c8da0
      Karicheri, Muralidharan authored
      When HSR interface is setup using ip link command, an annoying warning
      appears with the trace as below:-
      
      [  203.019828] hsr_get_node: Non-HSR frame
      [  203.019833] Modules linked in:
      [  203.019848] CPU: 0 PID: 158 Comm: sd-resolve Tainted: G        W       4.12.0-rc3-00052-g9fa6bf70 #2
      [  203.019853] Hardware name: Generic DRA74X (Flattened Device Tree)
      [  203.019869] [<c0110280>] (unwind_backtrace) from [<c010c2f4>] (show_stack+0x10/0x14)
      [  203.019880] [<c010c2f4>] (show_stack) from [<c04b9f64>] (dump_stack+0xac/0xe0)
      [  203.019894] [<c04b9f64>] (dump_stack) from [<c01374e8>] (__warn+0xd8/0x104)
      [  203.019907] [<c01374e8>] (__warn) from [<c0137548>] (warn_slowpath_fmt+0x34/0x44)
      root@am57xx-evm:~# [  203.019921] [<c0137548>] (warn_slowpath_fmt) from [<c081126c>] (hsr_get_node+0x148/0x170)
      [  203.019932] [<c081126c>] (hsr_get_node) from [<c0814240>] (hsr_forward_skb+0x110/0x7c0)
      [  203.019942] [<c0814240>] (hsr_forward_skb) from [<c0811d64>] (hsr_dev_xmit+0x2c/0x34)
      [  203.019954] [<c0811d64>] (hsr_dev_xmit) from [<c06c0828>] (dev_hard_start_xmit+0xc4/0x3bc)
      [  203.019963] [<c06c0828>] (dev_hard_start_xmit) from [<c06c13d8>] (__dev_queue_xmit+0x7c4/0x98c)
      [  203.019974] [<c06c13d8>] (__dev_queue_xmit) from [<c0782f54>] (ip6_finish_output2+0x330/0xc1c)
      [  203.019983] [<c0782f54>] (ip6_finish_output2) from [<c0788f0c>] (ip6_output+0x58/0x454)
      [  203.019994] [<c0788f0c>] (ip6_output) from [<c07b16cc>] (mld_sendpack+0x420/0x744)
      
      As this is an expected path to hsr_get_node() with frame coming from
      the master interface, add a check to ensure packet is not from the
      master port and then warn.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      675c8da0
    • Christian Perle's avatar
      proc: snmp6: Use correct type in memset · 3500cd73
      Christian Perle authored
      Reading /proc/net/snmp6 yields bogus values on 32 bit kernels.
      Use "u64" instead of "unsigned long" in sizeof().
      
      Fixes: 4a4857b1 ("proc: Reduce cache miss in snmp6_seq_show")
      Signed-off-by: default avatarChristian Perle <christian.perle@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3500cd73
  2. 11 Jun, 2017 18 commits
  3. 10 Jun, 2017 13 commits
  4. 09 Jun, 2017 6 commits
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-4.12-20170609' of... · f6d4c713
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-4.12-20170609' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2017-06-09
      
      this is a pull request of 6 patches for net/master.
      
      There's a patch by Stephane Grosjean that fixes an uninitialized symbol warning
      in the peak_canfd driver. A patch by Johan Hovold to fix the product-id
      endianness in an error message in the the peak_usb driver. A patch by Oliver
      Hartkopp to enable CAN FD for virtual CAN devices by default. Three patches by
      me, one makes the helper function can_change_state() robust to be called with
      cf == NULL. The next patch fixes a memory leak in the gs_usb driver. And the
      last one fixes a lockdep splat by properly initialize the per-net
      can_rcvlists_lock spin_lock.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6d4c713
    • Johannes Berg's avatar
      mac80211: free netdev on dev_alloc_name() error · c7a61cba
      Johannes Berg authored
      The change to remove free_netdev() from ieee80211_if_free()
      erroneously didn't add the necessary free_netdev() for when
      ieee80211_if_free() is called directly in one place, rather
      than as the priv_destructor. Add the missing call.
      
      Fixes: cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7a61cba
    • ashwanth@codeaurora.org's avatar
      net: rps: send out pending IPI's on CPU hotplug · 773fc8f6
      ashwanth@codeaurora.org authored
      IPI's from the victim cpu are not handled in dev_cpu_callback.
      So these pending IPI's would be sent to the remote cpu only when
      NET_RX is scheduled on the victim cpu and since this trigger is
      unpredictable it would result in packet latencies on the remote cpu.
      
      This patch add support to send the pending ipi's of victim cpu.
      Signed-off-by: default avatarAshwanth Goli <ashwanth@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      773fc8f6
    • Mario Molitor's avatar
      stmmac: fix for hw timestamp of GMAC3 unit · 33d4c482
      Mario Molitor authored
      1.) Bugfix of function stmmac_get_tx_hwtstamp.
          Corrected the tx timestamp available check (same as 4.8 and older)
          Change printout from info syslevel to debug.
      
      2.) Bugfix of function stmmac_get_rx_hwtstamp.
          Corrected the rx timestamp available check (same as 4.8 and older)
          Change printout from info syslevel to debug.
      
      Fixes: ba1ffd74 ("stmmac: fix PTP support for GMAC4")
      Signed-off-by: default avatarMario Molitor <mario_molitor@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33d4c482
    • Mario Molitor's avatar
      stmmac: fix ptp header for GMAC3 hw timestamp · fd6720ae
      Mario Molitor authored
      According the CYCLON V documention only the bit 16 of snaptypesel should
      set.
      (more information see Table 17-20 (cv_5v4.pdf) :
       Timestamp Snapshot Dependency on Register Bits)
      
      Fixes: d2042052 ("stmmac: update the PTP header file")
      Signed-off-by: default avatarMario Molitor <mario_molitor@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd6720ae
    • Krister Johansen's avatar
      Fix an intermittent pr_emerg warning about lo becoming free. · f186ce61
      Krister Johansen authored
      It looks like this:
      
      Message from syslogd@flamingo at Apr 26 00:45:00 ...
       kernel:unregister_netdevice: waiting for lo to become free. Usage count = 4
      
      They seem to coincide with net namespace teardown.
      
      The message is emitted by netdev_wait_allrefs().
      
      Forced a kdump in netdev_run_todo, but found that the refcount on the lo
      device was already 0 at the time we got to the panic.
      
      Used bcc to check the blocking in netdev_run_todo.  The only places
      where we're off cpu there are in the rcu_barrier() and msleep() calls.
      That behavior is expected.  The msleep time coincides with the amount of
      time we spend waiting for the refcount to reach zero; the rcu_barrier()
      wait times are not excessive.
      
      After looking through the list of callbacks that the netdevice notifiers
      invoke in this path, it appears that the dst_dev_event is the most
      interesting.  The dst_ifdown path places a hold on the loopback_dev as
      part of releasing the dev associated with the original dst cache entry.
      Most of our notifier callbacks are straight-forward, but this one a)
      looks complex, and b) places a hold on the network interface in
      question.
      
      I constructed a new bcc script that watches various events in the
      liftime of a dst cache entry.  Note that dst_ifdown will take a hold on
      the loopback device until the invalidated dst entry gets freed.
      
      [      __dst_free] on DST: ffff883ccabb7900 IF tap1008300eth0 invoked at 1282115677036183
          __dst_free
          rcu_nocb_kthread
          kthread
          ret_from_fork
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f186ce61