1. 22 Dec, 2016 2 commits
  2. 21 Dec, 2016 7 commits
    • Colin Ian King's avatar
      net: fddi: skfp: use %p format specifier for addresses rather than %x · 551cde19
      Colin Ian King authored
      Trivial fix: Addresses should be printed using the %p format specifier
      rather than using %x.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      551cde19
    • Eric Dumazet's avatar
      tcp: add a missing barrier in tcp_tasklet_func() · 0a9648f1
      Eric Dumazet authored
      Madalin reported crashes happening in tcp_tasklet_func() on powerpc64
      
      Before TSQ_QUEUED bit is cleared, we must ensure the changes done
      by list_del(&tp->tsq_node); are committed to memory, otherwise
      corruption might happen, as an other cpu could catch TSQ_QUEUED
      clearance too soon.
      
      We can notice that old kernels were immune to this bug, because
      TSQ_QUEUED was cleared after a bh_lock_sock(sk)/bh_unlock_sock(sk)
      section, but they could have missed a kick to write additional bytes,
      when NIC interrupts for a given flow are spread to multiple cpus.
      
      Affected TCP flows would need an incoming ACK or RTO timer to add more
      packets to the pipe. So overall situation should be better now.
      
      Fixes: b223feb9 ("tcp: tsq: add shortcut in tcp_tasklet_func()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMadalin Bucur <madalin.bucur@nxp.com>
      Tested-by: default avatarMadalin Bucur <madalin.bucur@nxp.com>
      Tested-by: default avatarXing Lei <xing.lei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a9648f1
    • Thomas Petazzoni's avatar
      net: mvpp2: fix dma unmapping of TX buffers for fragments · 8354491c
      Thomas Petazzoni authored
      Since commit 71ce391d ("net: mvpp2: enable proper per-CPU TX
      buffers unmapping"), we are not correctly DMA unmapping TX buffers for
      fragments.
      
      Indeed, the mvpp2_txq_inc_put() function only stores in the
      txq_cpu->tx_buffs[] array the physical address of the buffer to be
      DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
      skb_headlen(skb) to get the size to be unmapped. Both of this works fine
      for TX descriptors that are associated directly to a SKB, but not the
      ones that are used for fragments, with a NULL pointer as skb:
      
       - We have a NULL physical address when calling DMA unmap
       - skb_headlen(skb) crashes because skb is NULL
      
      This causes random crashes when fragments are used.
      
      To solve this problem, we need to:
      
       - Store the physical address of the buffer to be unmapped
         unconditionally, regardless of whether it is tied to a SKB or not.
      
       - Store the length of the buffer to be unmapped, which requires a new
         field.
      
      Instead of adding a third array to store the length of the buffer to be
      unmapped, and as suggested by David Miller, this commit refactors the
      tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
      separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
      added. Therefore, instead of having three arrays to allocate/free, we
      have a single one, which also improve data locality, reducing the
      impact on the CPU cache.
      
      Fixes: 71ce391d ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
      Reported-by: default avatarRaphael G <raphael.glon@corp.ovh.com>
      Cc: Raphael G <raphael.glon@corp.ovh.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8354491c
    • Heiko Stübner's avatar
      net: ethernet: stmmac: dwmac-rk: make clk enablement first in powerup · f217bfde
      Heiko Stübner authored
      Right now the dwmac-rk tries to set up the GRF-specific speed and link
      options before enabling clocks, phys etc and on previous socs this works
      because the GRF is supplied on the whole by one clock.
      
      On the rk3399 however the GRF (General Register Files) clock-supply
      has been split into multiple clocks and while there is no specific
      grf-gmac clock like for other sub-blocks, it seems the mac-specific
      portions are actually supplied by the general mac clock.
      
      This results in hangs on rk3399 boards if the driver is build as module.
      When built in te problem of course doesn't surface, as the clocks
      are of course still on at the stage before clock_disable_unused.
      
      To solve this, simply move the clock enablement to the first position
      in the powerup callback. This is also a good idea in general to
      enable clocks before everything else.
      
      Tested on rk3288, rk3368 and rk3399 the dwmac still works on all of them.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f217bfde
    • Kalesh A P's avatar
      be2net: Increase skb headroom size to 256 bytes · 76b15923
      Kalesh A P authored
      The driver currently allocates 128 bytes of skb headroom.
      This was found to be insufficient with some configurations
      like Geneve tunnels, which resulted in skb head reallocations.
      
      Increase the headroom to 256 bytes to fix this.
      Signed-off-by: default avatarKalesh A P <kalesh-anakkur.purayil@broadcom.com>
      Signed-off-by: default avatarSuresh Reddy <suresh.reddy@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76b15923
    • Larry Finger's avatar
      rtlwifi: Fix kernel oops introduced with commit e4965614 · 22b68b93
      Larry Finger authored
      With commit e4965614 {"rtlwifi: Use dev_kfree_skb_irq instead of
      kfree_skb"), the method used to free an skb was changed because the
      kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb()
      guards against a NULL value for the argument. Routine dev_kfree_skb_irq()
      does not, and a test is needed to prevent kernel panics.
      
      Fixes: e4965614 ("rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb")
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org> # 4.9+
      Cc: Wei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      22b68b93
    • Tobias Klausmann's avatar
      ath9k: do not return early to fix rcu unlocking · d1f1c0e2
      Tobias Klausmann authored
      Starting with commit d94a461d ("ath9k: use ieee80211_tx_status_noskb
      where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
      returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
      and suspicious RCU usage:
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       4.9.0-rc8 #11 Not tainted
       -------------------------------
       kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
      
       other info that might help us debug this:
      
       RCU used illegally from idle CPU!
       rcu_scheduler_active = 1, debug_locks = 0
       RCU used illegally from extended quiescent state!
       1 lock held by swapper/7/0:
       #0:
        (
       rcu_read_lock
       ){......}
       , at:
       [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]
      
       stack backtrace:
       CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
       Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
        ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
        ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
        ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
       Call Trace:
        <IRQ>
        [<ffffffff8132b1e5>] dump_stack+0x68/0x93
        [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
        [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
        [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
        [<ffffffff81058631>] irq_exit+0x61/0xd0
        [<ffffffff81018d25>] do_IRQ+0x65/0x110
        [<ffffffff81672189>] common_interrupt+0x89/0x89
        <EOI>
        [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
        [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
        [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
        [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
        [<ffffffff810336f8>] start_secondary+0x148/0x170
      Signed-off-by: default avatarTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
      Fixes: d94a461d ("ath9k: use ieee80211_tx_status_noskb where possible")
      Cc: <stable@vger.kernel.org> # v4.9
      Acked-by: default avatarFelix Fietkau <nbd@nbd.name>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: default avatarGabriel Craciunescu <nix.or.die@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d1f1c0e2
  3. 20 Dec, 2016 31 commits