1. 07 Mar, 2018 10 commits
    • Michal Kalderon's avatar
      qed: Free RoCE ILT Memory on rmmod qedr · 9de506a5
      Michal Kalderon authored
      Rdma requires ILT Memory to be allocated for it's QPs.
      Each ILT entry points to a page used by several Rdma QPs.
      To avoid allocating all the memory in advance, the rdma
      implementation dynamically allocates memory as more QPs are
      added, however it does not dynamically free the memory.
      The memory should have been freed on rmmod qedr, but isn't.
      This patch adds the memory freeing on rmmod qedr (currently
      it will be freed with qed is removed).
      
      An outcome of this bug, is that if qedr is unloaded and loaded
      without unloaded qed, there will be no more RoCE traffic.
      
      The reason these are related, is that the logic of detecting the
      first QP ever opened is by asking whether ILT memory for RoCE has
      been allocated.
      
      In addition, this patch modifies freeing of the Task context to
      always use the PROTOCOLID_ROCE and not the protocol passed,
      this is because task context for iWARP and ROCE both use the
      ROCE protocol id, as opposed to the connection context.
      
      Fixes: dbb799c3 ("qed: Initialize hardware for new protocols")
      Signed-off-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Signed-off-by: default avatarAriel Elior <Ariel.Elior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9de506a5
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · 87772fe6
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2018-03-05
      
      This series contains fixes to e1000e only.
      
      Benjamin Poirier provides all but one fix in this series, starting with
      workaround for a VMWare e1000e emulation issue where ICR reads 0x0 on
      the emulated device.  Partially reverted a previous commit dealing with
      the "Other" interrupt throttling to avoid unforeseen fallout from these
      changes that are not strictly necessary.  Restored the ICS write for
      receive and transmit queue interrupts in the case that txq or rxq bits
      were set in ICR and the Other interrupt handler read and cleared ICR
      before the queue interrupt was raised.  Fixed an bug where interrupts
      may be missed if ICR is read while INT_ASSERTED is not set, so avoid the
      problem by setting all bits related to events that can trigger the Other
      interrupt in IMS.  Fixed the return value for check_for_link() when
      auto-negotiation is off.
      
      Pierre-Yves Kerbrat fixes e1000e to use dma_zalloc_coherent() to make
      sure the ring is memset to 0 to prevent the area from containing
      garbage.
      
      v2: added an additional e1000e fix to the series
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87772fe6
    • Eric Dumazet's avatar
      net: usbnet: fix potential deadlock on 32bit hosts · 2695578b
      Eric Dumazet authored
      Marek reported a LOCKDEP issue occurring on 32bit host,
      that we tracked down to the fact that usbnet could either
      run from soft or hard irqs.
      
      This patch adds u64_stats_update_begin_irqsave() and
      u64_stats_update_end_irqrestore() helpers to solve this case.
      
      [   17.768040] ================================
      [   17.772239] WARNING: inconsistent lock state
      [   17.776511] 4.16.0-rc3-next-20180227-00007-g876c53a7493c #453 Not tainted
      [   17.783329] --------------------------------
      [   17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      [   17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   17.798751]  (&syncp->seq#5){?.-.}, at: [<9b22e5f0>]
      asix_rx_fixup_internal+0x188/0x288
      [   17.806790] {IN-HARDIRQ-W} state was registered at:
      [   17.811677]   tx_complete+0x100/0x208
      [   17.815319]   __usb_hcd_giveback_urb+0x60/0xf0
      [   17.819770]   xhci_giveback_urb_in_irq+0xa8/0x240
      [   17.824469]   xhci_td_cleanup+0xf4/0x16c
      [   17.828367]   xhci_irq+0xe74/0x2240
      [   17.831827]   usb_hcd_irq+0x24/0x38
      [   17.835343]   __handle_irq_event_percpu+0x98/0x510
      [   17.840111]   handle_irq_event_percpu+0x1c/0x58
      [   17.844623]   handle_irq_event+0x38/0x5c
      [   17.848519]   handle_fasteoi_irq+0xa4/0x138
      [   17.852681]   generic_handle_irq+0x18/0x28
      [   17.856760]   __handle_domain_irq+0x6c/0xe4
      [   17.860941]   gic_handle_irq+0x54/0xa0
      [   17.864666]   __irq_svc+0x70/0xb0
      [   17.867964]   arch_cpu_idle+0x20/0x3c
      [   17.871578]   arch_cpu_idle+0x20/0x3c
      [   17.875190]   do_idle+0x144/0x218
      [   17.878468]   cpu_startup_entry+0x18/0x1c
      [   17.882454]   start_kernel+0x394/0x400
      [   17.886177] irq event stamp: 161912
      [   17.889616] hardirqs last  enabled at (161912): [<7bedfacf>]
      __netdev_alloc_skb+0xcc/0x140
      [   17.897893] hardirqs last disabled at (161911): [<d58261d0>]
      __netdev_alloc_skb+0x94/0x140
      [   17.904903] exynos5-hsi2c 12ca0000.i2c: tx timeout
      [   17.906116] softirqs last  enabled at (161904): [<387102ff>]
      irq_enter+0x78/0x80
      [   17.906123] softirqs last disabled at (161905): [<cf4c628e>]
      irq_exit+0x134/0x158
      [   17.925722].
      [   17.925722] other info that might help us debug this:
      [   17.933435]  Possible unsafe locking scenario:
      [   17.933435].
      [   17.940331]        CPU0
      [   17.942488]        ----
      [   17.944894]   lock(&syncp->seq#5);
      [   17.948274]   <Interrupt>
      [   17.950847]     lock(&syncp->seq#5);
      [   17.954386].
      [   17.954386]  *** DEADLOCK ***
      [   17.954386].
      [   17.962422] no locks held by swapper/0/0.
      
      Fixes: c8b5d129 ("net: usbnet: support 64bit stats")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2695578b
    • Alexey Kodanev's avatar
      sch_netem: fix skb leak in netem_enqueue() · 35d889d1
      Alexey Kodanev authored
      When we exceed current packets limit and we have more than one
      segment in the list returned by skb_gso_segment(), netem drops
      only the first one, skipping the rest, hence kmemleak reports:
      
      unreferenced object 0xffff880b5d23b600 (size 1024):
        comm "softirq", pid 0, jiffies 4384527763 (age 2770.629s)
        hex dump (first 32 bytes):
          00 80 23 5d 0b 88 ff ff 00 00 00 00 00 00 00 00  ..#]............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000d8a19b9d>] __alloc_skb+0xc9/0x520
          [<000000001709b32f>] skb_segment+0x8c8/0x3710
          [<00000000c7b9bb88>] tcp_gso_segment+0x331/0x1830
          [<00000000c921cba1>] inet_gso_segment+0x476/0x1370
          [<000000008b762dd4>] skb_mac_gso_segment+0x1f9/0x510
          [<000000002182660a>] __skb_gso_segment+0x1dd/0x620
          [<00000000412651b9>] netem_enqueue+0x1536/0x2590 [sch_netem]
          [<0000000005d3b2a9>] __dev_queue_xmit+0x1167/0x2120
          [<00000000fc5f7327>] ip_finish_output2+0x998/0xf00
          [<00000000d309e9d3>] ip_output+0x1aa/0x2c0
          [<000000007ecbd3a4>] tcp_transmit_skb+0x18db/0x3670
          [<0000000042d2a45f>] tcp_write_xmit+0x4d4/0x58c0
          [<0000000056a44199>] tcp_tasklet_func+0x3d9/0x540
          [<0000000013d06d02>] tasklet_action+0x1ca/0x250
          [<00000000fcde0b8b>] __do_softirq+0x1b4/0x5a3
          [<00000000e7ed027c>] irq_exit+0x1e2/0x210
      
      Fix it by adding the rest of the segments, if any, to skb 'to_free'
      list. Add new __qdisc_drop_all() and qdisc_drop_all() functions
      because they can be useful in the future if we need to drop segmented
      GSO packets in other places.
      
      Fixes: 6071bd1a ("netem: Segment GSO packets on enqueue")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35d889d1
    • David S. Miller's avatar
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth · 89036a2a
      David S. Miller authored
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth 2018-03-05
      
      Here are a few more Bluetooth fixes for the 4.16 kernel:
      
       - btusb: reset/resume fixes for Yoga 920 and Dell OptiPlex 3060
       - Fix for missing encryption refresh with the Security Manager protocol
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89036a2a
    • Denis Kirjanov's avatar
      fsl/fman: avoid sleeping in atomic context while adding an address · 803fafbe
      Denis Kirjanov authored
      __dev_mc_add grabs an adress spinlock so use
      atomic context in kmalloc.
      
      / # ifconfig eth0 inet 192.168.0.111
      [   89.331622] BUG: sleeping function called from invalid context at mm/slab.h:420
      [   89.339002] in_atomic(): 1, irqs_disabled(): 0, pid: 1035, name: ifconfig
      [   89.345799] 2 locks held by ifconfig/1035:
      [   89.349908]  #0:  (rtnl_mutex){+.+.}, at: [<(ptrval)>] devinet_ioctl+0xc0/0x8a0
      [   89.357258]  #1:  (_xmit_ETHER){+...}, at: [<(ptrval)>] __dev_mc_add+0x28/0x80
      [   89.364520] CPU: 1 PID: 1035 Comm: ifconfig Not tainted 4.16.0-rc3-dirty #8
      [   89.371464] Call Trace:
      [   89.373908] [e959db60] [c066f948] dump_stack+0xa4/0xfc (unreliable)
      [   89.380177] [e959db80] [c00671d8] ___might_sleep+0x248/0x280
      [   89.385833] [e959dba0] [c01aec34] kmem_cache_alloc_trace+0x174/0x320
      [   89.392179] [e959dbd0] [c04ab920] dtsec_add_hash_mac_address+0x130/0x240
      [   89.398874] [e959dc00] [c04a9d74] set_multi+0x174/0x1b0
      [   89.404093] [e959dc30] [c04afb68] dpaa_set_rx_mode+0x68/0xe0
      [   89.409745] [e959dc40] [c057baf8] __dev_mc_add+0x58/0x80
      [   89.415052] [e959dc60] [c060fd64] igmp_group_added+0x164/0x190
      [   89.420878] [e959dca0] [c060ffa8] ip_mc_inc_group+0x218/0x460
      [   89.426617] [e959dce0] [c06120fc] ip_mc_up+0x3c/0x190
      [   89.431662] [e959dd10] [c0607270] inetdev_event+0x250/0x620
      [   89.437227] [e959dd50] [c005f190] notifier_call_chain+0x80/0xf0
      [   89.443138] [e959dd80] [c0573a74] __dev_notify_flags+0x54/0xf0
      [   89.448964] [e959dda0] [c05743f8] dev_change_flags+0x48/0x60
      [   89.454615] [e959ddc0] [c0606744] devinet_ioctl+0x544/0x8a0
      [   89.460180] [e959de10] [c060987c] inet_ioctl+0x9c/0x1f0
      [   89.465400] [e959de80] [c05479a8] sock_ioctl+0x168/0x460
      [   89.470708] [e959ded0] [c01cf3ec] do_vfs_ioctl+0xac/0x8c0
      [   89.476099] [e959df20] [c01cfc40] SyS_ioctl+0x40/0xc0
      [   89.481147] [e959df40] [c0011318] ret_from_syscall+0x0/0x3c
      [   89.486715] --- interrupt: c01 at 0x1006943c
      [   89.486715]     LR = 0x100c45ec
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Acked-by: default avatarMadalin Bucur <madalin.bucur@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      803fafbe
    • David S. Miller's avatar
      Merge branch 'rhltable-dups' · 6f22c07f
      David S. Miller authored
      Paul Blakey says:
      
      ====================
      rhashtable: Fix rhltable duplicates insertion
      
      On our mlx5 driver fs_core.c, we use the rhltable interface to store
      flow groups. We noticed that sometimes we get a warning that flow group isn't
      found at removal. This rare case was caused when a specific scenario happened,
      insertion of a flow group with a similar match criteria (a duplicate),
      but only where the flow group rhash_head was second (or not first)
      on the relevant rhashtable bucket list.
      
      The first patch fixes it, and the second one adds a test that show
      it is now working.
      
      Paul.
      
      v3 --> v2 changes:
          * added missing fix in rhashtable_lookup_one code path as well.
      
      v1 --> v2 changes:
          * Changed commit messages to better reflect the change
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f22c07f
    • Paul Blakey's avatar
      test_rhashtable: add test case for rhltable with duplicate objects · 499ac3b6
      Paul Blakey authored
      Tries to insert duplicates in the middle of bucket's chain:
      bucket 1:  [[val 21 (tid=1)]] -> [[ val 1 (tid=2),  val 1 (tid=0) ]]
      
      Reuses tid to distinguish the elements insertion order.
      Signed-off-by: default avatarPaul Blakey <paulb@mellanox.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      499ac3b6
    • Paul Blakey's avatar
      rhashtable: Fix rhlist duplicates insertion · d3dcf8eb
      Paul Blakey authored
      When inserting duplicate objects (those with the same key),
      current rhlist implementation messes up the chain pointers by
      updating the bucket pointer instead of prev next pointer to the
      newly inserted node. This causes missing elements on removal and
      travesal.
      
      Fix that by properly updating pprev pointer to point to
      the correct rhash_head next pointer.
      
      Issue: 1241076
      Change-Id: I86b2c140bcb4aeb10b70a72a267ff590bb2b17e7
      Fixes: ca26893f ('rhashtable: Add rhlist interface')
      Signed-off-by: default avatarPaul Blakey <paulb@mellanox.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3dcf8eb
    • Geert Uytterhoeven's avatar
      dt-bindings: net: renesas-ravb: Make stream buffer optional · 25b5cdfc
      Geert Uytterhoeven authored
      The Stream Buffer for EtherAVB-IF (STBE) is an optional component, and
      is not present on all SoCs.
      
      Document this in the DT bindings, including a list of SoCs that do have
      it.
      
      Fixes: 785ec874 ("ravb: document R8A77970 bindings")
      Fixes: f231c417 ("dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25b5cdfc
  2. 06 Mar, 2018 8 commits
  3. 05 Mar, 2018 22 commits