1. 03 Mar, 2017 9 commits
    • David S. Miller's avatar
      Merge branch 'bgmac-fixes' · e2859980
      David S. Miller authored
      Jon Mason says:
      
      ====================
      net: ethernet: bgmac: bug fixes
      
      Changes in v5:
      * Rebased to the latest code and fixed up a compile error due to the
        mac_addr struct going away (found by David Miller)
      
      Changes in v4:
      * Added the udelays from the previous code (per David Miller)
      
      Changes in v3:
      * Reworked the init sequence patch to only remove the device reset if
        the device is actually in reset.  Given that this code doesn't bear
        much resemblance to the original code, I'm changing the author of the
        patch.  This was tested on NS2 SVK.
      
      Changes in v2:
      * Reworked the first match to make it more obvious what portions of the
        register were being preserved (Per Rafal Mileki)
      * Style change to reorder the function variables in patch 2 (per Sergei
        Shtylyov)
      
      Bug fixes for bgmac driver
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2859980
    • Hari Vyas's avatar
      net: ethernet: bgmac: mac address change bug · fa42245d
      Hari Vyas authored
      ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to
      bgmac_set_mac_address() but code assumed u8 *.  This caused two bytes
      chopping and the wrong mac address was configured.
      Signed-off-by: default avatarHari Vyas <hariv@broadcom.com>
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Fixes: 4e209001 ("bgmac: write mac address to hardware in ndo_set_mac_address")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa42245d
    • Jon Mason's avatar
      net: ethernet: bgmac: init sequence bug · 16206524
      Jon Mason authored
      Fix a bug in the 'bgmac' driver init sequence that blind writes for init
      sequence where it should preserve most bits other than the ones it is
      deliberately manipulating.
      
      The code now checks to see if the adapter needs to be brought out of
      reset (where as before it was doing an IDM write to bring it out of
      reset regardless of whether it was in reset or not).  Also, removed
      unnecessary usleeps (as there is already a read present to flush the
      IDM writes).
      Signed-off-by: default avatarZac Schroff <zschroff@broadcom.com>
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Fixes: f6a95a24 ("net: ethernet: bgmac: Add platform device support")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16206524
    • David S. Miller's avatar
      Merge branch 'xen-netback-fixes' · 2ddbcea7
      David S. Miller authored
      Paul Durrant says:
      
      ====================
      xen-netback: update memory leak fix to avoid BUG
      
      Commit 9a6cdf52 "xen-netback: fix memory leaks on XenBus disconnect"
      added missing code to fix a memory leak by calling vfree() in the
      appropriate place.
      Unfortunately subsequent commit f16f1df6 "xen-netback: protect
      resource cleaning on XenBus disconnect" then wrapped this call to vfree()
      in a spin lock, leading to a BUG due to incorrect context.
      
      Patch #1 makes the existing code more readable
      Patch #2 fixes the problem
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ddbcea7
    • Paul Durrant's avatar
      xen-netback: don't vfree() queues under spinlock · a254d8f9
      Paul Durrant authored
      This leads to a BUG of the following form:
      
      [  174.512861] switch: port 2(vif3.0) entered disabled state
      [  174.522735] BUG: sleeping function called from invalid context at
      /home/build/linux-linus/mm/vmalloc.c:1441
      [  174.523451] in_atomic(): 1, irqs_disabled(): 0, pid: 28, name: xenwatch
      [  174.524131] CPU: 1 PID: 28 Comm: xenwatch Tainted: G        W
      4.10.0upstream-11073-g4977ab6e-dirty #1
      [  174.524819] Hardware name: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0
      03/14/2011
      [  174.525517] Call Trace:
      [  174.526217]  show_stack+0x23/0x60
      [  174.526899]  dump_stack+0x5b/0x88
      [  174.527562]  ___might_sleep+0xde/0x130
      [  174.528208]  __might_sleep+0x35/0xa0
      [  174.528840]  ? _raw_spin_unlock_irqrestore+0x13/0x20
      [  174.529463]  ? __wake_up+0x40/0x50
      [  174.530089]  remove_vm_area+0x20/0x90
      [  174.530724]  __vunmap+0x1d/0xc0
      [  174.531346]  ? delete_object_full+0x13/0x20
      [  174.531973]  vfree+0x40/0x80
      [  174.532594]  set_backend_state+0x18a/0xa90
      [  174.533221]  ? dwc_scan_descriptors+0x24d/0x430
      [  174.533850]  ? kfree+0x5b/0xc0
      [  174.534476]  ? xenbus_read+0x3d/0x50
      [  174.535101]  ? xenbus_read+0x3d/0x50
      [  174.535718]  ? xenbus_gather+0x31/0x90
      [  174.536332]  ? ___might_sleep+0xf6/0x130
      [  174.536945]  frontend_changed+0x6b/0xd0
      [  174.537565]  xenbus_otherend_changed+0x7d/0x80
      [  174.538185]  frontend_changed+0x12/0x20
      [  174.538803]  xenwatch_thread+0x74/0x110
      [  174.539417]  ? woken_wake_function+0x20/0x20
      [  174.540049]  kthread+0xe5/0x120
      [  174.540663]  ? xenbus_printf+0x50/0x50
      [  174.541278]  ? __kthread_init_worker+0x40/0x40
      [  174.541898]  ret_from_fork+0x21/0x2c
      [  174.548635] switch: port 2(vif3.0) entered disabled state
      
      This patch defers the vfree() until after the spinlock is released.
      Reported-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a254d8f9
    • Paul Durrant's avatar
      xen-netback: keep a local pointer for vif in backend_disconnect() · d67ce7da
      Paul Durrant authored
      This patch replaces use of 'be->vif' with 'vif' and hence generally
      makes the function look tidier. No semantic change.
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d67ce7da
    • David S. Miller's avatar
      Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · f7bb3d86
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2017-03-02
      
      This series contains fixes to ixgbe only.
      
      Paolo fixes the driver so that you can actually update the RSS key value
      via ethtool.
      
      Alex fixes an issue on architectures that have a cache line size larger
      than 64 Bytes, where the amount of headroom for the frame starts
      shrinking.  To take this into account, Alex adds one small check so that
      we compare the max_frame to the amount of actual data we can store, so
      we will automatically enable 3K receive buffers as soon as the maximum
      frame size we can handle drops below the standard Ethernet MTU.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7bb3d86
    • Alexander Duyck's avatar
      ixgbe: Limit use of 2K buffers on architectures with 256B or larger cache lines · c74042f3
      Alexander Duyck authored
      On architectures that have a cache line size larger than 64 Bytes we start
      running into issues where the amount of headroom for the frame starts
      shrinking.
      
      The size of skb_shared_info on a system with a 64B L1 cache line size is
      320.  This increases to 384 with a 128B cache line, and 512 with a 256B
      cache line.
      
      In addition the NET_SKB_PAD value increases as well consistent with the
      cache line size.  As a result when we get to a 256B cache line as seen on
      the s390 we end up 768 bytes used by padding and shared info leaving us
      with only 1280 bytes to use for data storage.  On architectures such as
      this we should default to using 3K Rx buffers out of a 8K page instead of
      trying to do 1.5K buffers out of a 4K page.
      
      To take all of this into account I have added one small check so that we
      compare the max_frame to the amount of actual data we can store.  This was
      already occurring for igb, but I had overlooked it for ixgbe as it doesn't
      have strict limits for 82599 once we enable jumbo frames.  By adding this
      check we will automatically enable 3K Rx buffers as soon as the maximum
      frame size we can handle drops below the standard Ethernet MTU.
      
      I also went through and fixed one small typo that I found where I had left
      an IGB in a variable name due to a copy/paste error.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c74042f3
    • Paolo Abeni's avatar
      ixgbe: update the rss key on h/w, when ethtool ask for it · d3aa9c9f
      Paolo Abeni authored
      Currently ixgbe_set_rxfh() updates the rss_key copy in the driver
      memory, but does not push the new value into the h/w. This commit
      add a new helper for the latter operation and call it in
      ixgbe_set_rxfh(), so that the h/w rss key value can be really
      updated via ethtool.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d3aa9c9f
  2. 02 Mar, 2017 25 commits
    • Anoob Soman's avatar
      xen-netback: Use GFP_ATOMIC to allocate hash · 9f674e48
      Anoob Soman authored
      Allocation of new_hash, inside xenvif_new_hash(), always happen
      in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new
      hash allocation.
      Signed-off-by: default avatarAnoob Soman <anoob.soman@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f674e48
    • WANG Cong's avatar
      bonding: use ETH_MAX_MTU as max mtu · 31c05415
      WANG Cong authored
      This restores the ability of setting bond device's mtu to 9000.
      
      Fixes: 91572088 ("net: use core MTU range checking in core net infra")
      Reported-by: daznis@gmail.com
      Reported-by: default avatarBrad Campbell <lists2009@fnarfbargle.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31c05415
    • Dexuan Cui's avatar
      netvsc: fix use-after-free in netvsc_change_mtu() · 152669bd
      Dexuan Cui authored
      'nvdev' is freed in rndis_filter_device_remove -> netvsc_device_remove ->
      free_netvsc_device, so we mustn't access it, before it's re-created in
      rndis_filter_device_add -> netvsc_device_add.
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Reviewed-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      152669bd
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-03-02' of... · 35576ee1
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      This contains just the average.h change in order to get it
      into the tree before adding new users through -next trees.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35576ee1
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2017-03-02' of... · 1c296a3e
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2017-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.11
      
      Add back a fixed version of an ath10k patch which was reverted during
      the merge window.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c296a3e
    • WANG Cong's avatar
      ipv6: ignore null_entry in inet6_rtm_getroute() too · 9d6acb3b
      WANG Cong authored
      Like commit 1f17e2f2 ("net: ipv6: ignore null_entry on route dumps"),
      we need to ignore null entry in inet6_rtm_getroute() too.
      
      Return -ENETUNREACH here to sync with IPv4 behavior, as suggested by David.
      
      Fixes: a1a22c12 ("net: ipv6: Keep nexthop of multipath route on admin down")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d6acb3b
    • Dmitry Torokhov's avatar
      drivers: net: ethernet: remove incorrect __exit markups · be12502e
      Dmitry Torokhov authored
      Even if bus is not hot-pluggable, devices can be unbound from the
      driver via sysfs, so we should not be using __exit annotations on
      remove() methods. The only exception is drivers registered with
      platform_driver_probe() which specifically disables sysfs bind/unbind
      attributes.
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be12502e
    • Wei Wang's avatar
      tcp: fix potential double free issue for fastopen_req · 7db92362
      Wei Wang authored
      tp->fastopen_req could potentially be double freed if a malicious
      user does the following:
      1. Enable TCP_FASTOPEN_CONNECT sockopt and do a connect() on the socket.
      2. Call connect() with AF_UNSPEC to disconnect the socket.
      3. Make this socket a listening socket by calling listen().
      4. Accept incoming connections and generate child sockets. All child
         sockets will get a copy of the pointer of fastopen_req.
      5. Call close() on all sockets. fastopen_req will get freed multiple
         times.
      
      Fixes: 19f6d3f3 ("net/tcp-fastopen: Add new API support")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7db92362
    • Arnaldo Carvalho de Melo's avatar
      net: Introduce sk_clone_lock() error path routine · 94352d45
      Arnaldo Carvalho de Melo authored
      When handling problems in cloning a socket with the sk_clone_locked()
      function we need to perform several steps that were open coded in it and
      its callers, so introduce a routine to avoid this duplication:
      sk_free_unlock_clone().
      
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/n/net-ui6laqkotycunhtmqryl9bfx@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94352d45
    • Arnaldo Carvalho de Melo's avatar
      dccp: Unlock sock before calling sk_free() · d5afb6f9
      Arnaldo Carvalho de Melo authored
      The code where sk_clone() came from created a new socket and locked it,
      but then, on the error path didn't unlock it.
      
      This problem stayed there for a long while, till b0691c8e ("net:
      Unlock sock before calling sk_free()") fixed it, but unfortunately the
      callers of sk_clone() (now sk_clone_locked()) were not audited and the
      one in dccp_create_openreq_child() remained.
      
      Now in the age of the syskaller fuzzer, this was finally uncovered, as
      reported by Dmitry:
      
       ---- 8< ----
      
      I've got the following report while running syzkaller fuzzer on
      86292b33 ("Merge branch 'akpm' (patches from Andrew)")
      
        [ BUG: held lock freed! ]
        4.10.0+ #234 Not tainted
        -------------------------
        syz-executor6/6898 is freeing memory
        ffff88006286cac0-ffff88006286d3b7, with a lock still held there!
         (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock
        include/linux/spinlock.h:299 [inline]
         (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>]
        sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
        5 locks held by syz-executor6/6898:
         #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] lock_sock
        include/net/sock.h:1460 [inline]
         #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>]
        inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681
         #1:  (rcu_read_lock){......}, at: [<ffffffff83bc1c2a>]
        inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_unlink
        include/linux/skbuff.h:1767 [inline]
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_dequeue
        include/linux/skbuff.h:1783 [inline]
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>]
        process_backlog+0x264/0x730 net/core/dev.c:4835
         #3:  (rcu_read_lock){......}, at: [<ffffffff83aeb5c0>]
        ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59
         #4:  (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock
        include/linux/spinlock.h:299 [inline]
         #4:  (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>]
        sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
      
      Fix it just like was done by b0691c8e ("net: Unlock sock before calling
      sk_free()").
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170301153510.GE15145@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d5afb6f9
    • David S. Miller's avatar
      Merge tag 'batadv-net-for-davem-20170301' of git://git.open-mesh.org/linux-merge · 6ab2b999
      David S. Miller authored
      Simon Wunderlich says:
      
      ====================
      Here are two batman-adv bugfixes:
      
       - fix a potential double free when fragment merges fail,
         by Sven Eckelmann
      
       - fix failing tranmission of the 16th (last) fragment if that exists,
         by Linus Lüssing
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ab2b999
    • Peter Downs's avatar
      openvswitch: actions: fixed a brace coding style warning · f1304f7b
      Peter Downs authored
      Fixed a brace coding style warning reported by checkpatch.pl
      Signed-off-by: default avatarPeter Downs <padowns@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1304f7b
    • Ganesh Goudar's avatar
      cxgb4: update latest firmware version supported · 11bd44f6
      Ganesh Goudar authored
      Change t4fw_version.h to update latest firmware version
      number to 1.16.33.0.
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11bd44f6
    • David S. Miller's avatar
      Merge branch 'amd-xgbe-fixes' · a2d35d0b
      David S. Miller authored
      Tom Lendacky says:
      
      ====================
      amd-xgbe: AMD XGBE driver fixes 2017-02-28
      
      This patch series addresses some issues in the AMD XGBE driver.
      
      The following fixes are included in this driver update series:
      
      - Stop the PHY before disabling and releasing device interrupts so that
        MDIO requests issued by the device can be properly handled
      - Set the MDIO communication mode on device startup, not just device
        probe
      - Do not overwrite SFP settings when mod_absent is detected
      
      This patch series is based on net.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2d35d0b
    • Lendacky, Thomas's avatar
      amd-xgbe: Don't overwrite SFP PHY mod_absent settings · 2697ea5a
      Lendacky, Thomas authored
      If an SFP module is not present, xgbe_phy_sfp_phy_settings() should
      return after applying the default settings. Currently there is no return
      statement and the default settings are overwritten.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2697ea5a
    • Lendacky, Thomas's avatar
      amd-xgbe: Be sure to set MDIO modes on device (re)start · b42c6761
      Lendacky, Thomas authored
      The MDIO register mode is set when the device is probed. But when the
      device is brought down and then back up, the MDIO register mode has been
      reset.  Be sure to reset the mode during device startup and only change
      the mode of the address specified.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b42c6761
    • Lendacky, Thomas's avatar
      amd-xgbe: Stop the PHY before releasing interrupts · 402168b4
      Lendacky, Thomas authored
      Some configurations require the use of the hardware's MDIO support to
      communicate with external PHYs. The MDIO commands indicate completion
      through the device interrupt. When bringing down the device the interrupts
      were released before stopping the external PHY, resulting in MDIO command
      timeouts. Move the stopping of the PHY to before the releasing of the
      interrupts.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      402168b4
    • Alban Bedel's avatar
      drivers: net: xgene: Fix crash on DT systems · 9aea7779
      Alban Bedel authored
      On DT systems the driver require a clock, but the probe just print a
      warning and continue, leading to a crash when resetting the device.
      To fix this crash and properly handle probe deferals only ignore the
      missing clock if DT isn't used or if the clock doesn't exist.
      Signed-off-by: default avatarAlban Bedel <alban.bedel@avionic-design.de>
      Acked-by: default avatarIyappan Subramanian <isubramanian@apm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9aea7779
    • WANG Cong's avatar
      ipv6: check for ip6_null_entry in __ip6_del_rt_siblings() · e3330039
      WANG Cong authored
      Andrey reported a NULL pointer deref bug in ipv6_route_ioctl()
      -> ip6_route_del() -> __ip6_del_rt_siblings() code path. This is
      because ip6_null_entry is returned in this path since ip6_null_entry
      is kinda default for a ipv6 route table root node. Quote from
      David Ahern:
      
       ip6_null_entry is the root of all ipv6 fib tables making it integrated
       into the table ...
      
      We should ignore any attempt of trying to delete it, like we do in
      __ip6_del_rt() path and several others.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Fixes: 0ae81335 ("net: ipv6: Allow shorthand delete of all nexthops in multipath route")
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3330039
    • Waldemar Rymarkiewicz's avatar
      ath10k: search SMBIOS for OEM board file extension · 1657b8f8
      Waldemar Rymarkiewicz authored
      Board Data File (BDF) is loaded upon driver boot-up procedure. The right
      board data file is identified, among others, by device and sybsystem ids.
      
      The problem, however, can occur when the (default) board data file cannot
      fulfill with the vendor requirements and it is necessary to use a different
      board data file.
      
      To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
      Extension to specify the extension/variant name. The driver will take the
      extension suffix into consideration and will load the right (non-default)
      board data file if necessary.
      
      If it is unnecessary to use extension board data file, please leave the
      SMBIOS field blank and default configuration will be used.
      
      Example:
      If a default board data file for a specific board is identified by a string
            "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
             subsystem-device=0310"
      then the OEM specific data file, if used, could be identified by variant
      suffix:
            "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
             subsystem-device=0310,variant=DE_1AB"
      
      If board data file name extension is set but board-2.bin does not contain
      board data file for the variant, the driver will fallback to the default
      board data file not to break backward compatibility.
      
      This was first applied in commit f2593cb1 ("ath10k: Search SMBIOS for OEM
      board file extension") but later reverted in commit 005c3490 ("Revert
      "ath10k: Search SMBIOS for OEM board file extension"". This patch is now
      otherwise the same as commit f2593cb1 except the regression fixed.
      Signed-off-by: default avatarWaldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      1657b8f8
    • Johannes Berg's avatar
      average: change to declare precision, not factor · eb1e011a
      Johannes Berg authored
      Declaring the factor is counter-intuitive, and people are prone
      to using small(-ish) values even when that makes no sense.
      
      Change the DECLARE_EWMA() macro to take the fractional precision,
      in bits, rather than a factor, and update all users.
      
      While at it, add some more documentation.
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      eb1e011a
    • Eric Dumazet's avatar
      ipv6: orphan skbs in reassembly unit · 48cac18e
      Eric Dumazet authored
      Andrey reported a use-after-free in IPv6 stack.
      
      Issue here is that we free the socket while it still has skb
      in TX path and in some queues.
      
      It happens here because IPv6 reassembly unit messes skb->truesize,
      breaking skb_set_owner_w() badly.
      
      We fixed a similar issue for IPV4 in commit 8282f274 ("inet: frag:
      Always orphan skbs inside ip_defrag()")
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
      
      ==================================================================
      BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
      Read of size 8 at addr ffff880062da0060 by task a.out/4140
      
      page:ffffea00018b6800 count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x100000000008100(slab|head)
      raw: 0100000000008100 0000000000000000 0000000000000000 0000000180130013
      raw: dead000000000100 dead000000000200 ffff88006741f140 0000000000000000
      page dumped because: kasan: bad access detected
      
      CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       describe_address mm/kasan/report.c:262
       kasan_report_error+0x121/0x560 mm/kasan/report.c:370
       kasan_report mm/kasan/report.c:392
       __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
       sock_flag ./arch/x86/include/asm/bitops.h:324
       sock_wfree+0x118/0x120 net/core/sock.c:1631
       skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put ./include/net/inet_frag.h:133
       nf_ct_frag6_gather+0x1125/0x38b0 net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn ./include/linux/netfilter.h:102
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook ./include/linux/netfilter.h:212
       __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613
       rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x620 net/socket.c:848
       new_sync_write fs/read_write.c:499
       __vfs_write+0x483/0x760 fs/read_write.c:512
       vfs_write+0x187/0x530 fs/read_write.c:560
       SYSC_write fs/read_write.c:607
       SyS_write+0xfb/0x230 fs/read_write.c:599
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      RIP: 0033:0x7ff26e6f5b79
      RSP: 002b:00007ff268e0ed98 EFLAGS: 00000206 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007ff268e0f9c0 RCX: 00007ff26e6f5b79
      RDX: 0000000000000010 RSI: 0000000020f50fe1 RDI: 0000000000000003
      RBP: 00007ff26ebc1220 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
      R13: 00007ff268e0f9c0 R14: 00007ff26efec040 R15: 0000000000000003
      
      The buggy address belongs to the object at ffff880062da0000
       which belongs to the cache RAWv6 of size 1504
      The buggy address ffff880062da0060 is located 96 bytes inside
       of 1504-byte region [ffff880062da0000, ffff880062da05e0)
      
      Freed by task 4113:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
       slab_free_hook mm/slub.c:1352
       slab_free_freelist_hook mm/slub.c:1374
       slab_free mm/slub.c:2951
       kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
       sk_prot_free net/core/sock.c:1377
       __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sk_free+0x23/0x30 net/core/sock.c:1479
       sock_put ./include/net/sock.h:1638
       sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
       rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
       sock_release+0x8d/0x1e0 net/socket.c:599
       sock_close+0x16/0x20 net/socket.c:1063
       __fput+0x332/0x7f0 fs/file_table.c:208
       ____fput+0x15/0x20 fs/file_table.c:244
       task_work_run+0x19b/0x270 kernel/task_work.c:116
       exit_task_work ./include/linux/task_work.h:21
       do_exit+0x186b/0x2800 kernel/exit.c:839
       do_group_exit+0x149/0x420 kernel/exit.c:943
       SYSC_exit_group kernel/exit.c:954
       SyS_exit_group+0x1d/0x20 kernel/exit.c:952
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Allocated by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544
       slab_post_alloc_hook mm/slab.h:432
       slab_alloc_node mm/slub.c:2708
       slab_alloc mm/slub.c:2716
       kmem_cache_alloc+0x1af/0x250 mm/slub.c:2721
       sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1334
       sk_alloc+0x105/0x1010 net/core/sock.c:1396
       inet6_create+0x44d/0x1150 net/ipv6/af_inet6.c:183
       __sock_create+0x4f6/0x880 net/socket.c:1199
       sock_create net/socket.c:1239
       SYSC_socket net/socket.c:1269
       SyS_socket+0xf9/0x230 net/socket.c:1249
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Memory state around the buggy address:
       ffff880062d9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880062d9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff880062da0000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880062da0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880062da0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48cac18e
    • Eric Dumazet's avatar
      net: net_enable_timestamp() can be called from irq contexts · 13baa00a
      Eric Dumazet authored
      It is now very clear that silly TCP listeners might play with
      enabling/disabling timestamping while new children are added
      to their accept queue.
      
      Meaning net_enable_timestamp() can be called from BH context
      while current state of the static key is not enabled.
      
      Lets play safe and allow all contexts.
      
      The work queue is scheduled only under the problematic cases,
      which are the static key enable/disable transition, to not slow down
      critical paths.
      
      This extends and improves what we did in commit 5fa8bbda ("net: use
      a work queue to defer net_disable_timestamp() work")
      
      Fixes: b90e5794 ("net: dont call jump_label_dec from irq context")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13baa00a
    • Alexander Potapenko's avatar
      net: don't call strlen() on the user buffer in packet_bind_spkt() · 540e2894
      Alexander Potapenko authored
      KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
      uninitialized memory in packet_bind_spkt():
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      
      ==================================================================
      BUG: KMSAN: use of unitialized memory
      CPU: 0 PID: 1074 Comm: packet Not tainted 4.8.0-rc6+ #1891
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
       0000000000000000 ffff88006b6dfc08 ffffffff82559ae8 ffff88006b6dfb48
       ffffffff818a7c91 ffffffff85b9c870 0000000000000092 ffffffff85b9c550
       0000000000000000 0000000000000092 00000000ec400911 0000000000000002
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82559ae8>] dump_stack+0x238/0x290 lib/dump_stack.c:51
       [<ffffffff818a6626>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1003
       [<ffffffff818a783b>] __msan_warning+0x5b/0xb0
      mm/kmsan/kmsan_instr.c:424
       [<     inline     >] strlen lib/string.c:484
       [<ffffffff8259b58d>] strlcpy+0x9d/0x200 lib/string.c:144
       [<ffffffff84b2eca4>] packet_bind_spkt+0x144/0x230
      net/packet/af_packet.c:3132
       [<ffffffff84242e4d>] SYSC_bind+0x40d/0x5f0 net/socket.c:1370
       [<ffffffff84242a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff8515991b>] entry_SYSCALL_64_fastpath+0x13/0x8f
      arch/x86/entry/entry_64.o:?
      chained origin: 00000000eba00911
       [<ffffffff810bb787>] save_stack_trace+0x27/0x50
      arch/x86/kernel/stacktrace.c:67
       [<     inline     >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
       [<     inline     >] kmsan_save_stack mm/kmsan/kmsan.c:334
       [<ffffffff818a59f8>] kmsan_internal_chain_origin+0x118/0x1e0
      mm/kmsan/kmsan.c:527
       [<ffffffff818a7773>] __msan_set_alloca_origin4+0xc3/0x130
      mm/kmsan/kmsan_instr.c:380
       [<ffffffff84242b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356
       [<ffffffff84242a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff8515991b>] entry_SYSCALL_64_fastpath+0x13/0x8f
      arch/x86/entry/entry_64.o:?
      origin description: ----address@SYSC_bind (origin=00000000eb400911)
      ==================================================================
      (the line numbers are relative to 4.8-rc6, but the bug persists
      upstream)
      
      , when I run the following program as root:
      
      =====================================
       #include <string.h>
       #include <sys/socket.h>
       #include <netpacket/packet.h>
       #include <net/ethernet.h>
      
       int main() {
         struct sockaddr addr;
         memset(&addr, 0xff, sizeof(addr));
         addr.sa_family = AF_PACKET;
         int fd = socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL));
         bind(fd, &addr, sizeof(addr));
         return 0;
       }
      =====================================
      
      This happens because addr.sa_data copied from the userspace is not
      zero-terminated, and copying it with strlcpy() in packet_bind_spkt()
      results in calling strlen() on the kernel copy of that non-terminated
      buffer.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      540e2894
    • Mike Manning's avatar
      net: bridge: allow IPv6 when multicast flood is disabled · 8953de2f
      Mike Manning authored
      Even with multicast flooding turned off, IPv6 ND should still work so
      that IPv6 connectivity is provided. Allow this by continuing to flood
      multicast traffic originated by us.
      
      Fixes: b6cb5ac8 ("net: bridge: add per-port multicast flood flag")
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarMike Manning <mmanning@brocade.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8953de2f
  3. 01 Mar, 2017 6 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-02-28' of... · 16c54ac9
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-02-28' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      First round of fixes - details in the commits:
       * use a valid hrtimer clock ID in mac80211_hwsim
       * don't reorder frames prior to BA session
       * flush a delayed work at suspend so the state is all valid before
         suspend/resume
       * fix packet statistics in fast-RX, the RX packets
         counter increment was simply missing
       * don't try to re-transmit filtered frames in an aggregation session
       * shorten (for tracing) a debug message
       * typo fix in another debug message
       * fix nul-termination with HWSIM_ATTR_RADIO_NAME in hwsim
       * fix mgmt RX processing when station is looked up by driver/device
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16c54ac9
    • Eric Dumazet's avatar
      tcp/dccp: block BH for SYN processing · 449809a6
      Eric Dumazet authored
      SYN processing really was meant to be handled from BH.
      
      When I got rid of BH blocking while processing socket backlog
      in commit 5413d1ba ("net: do not block BH while processing socket
      backlog"), I forgot that a malicious user could transition to TCP_LISTEN
      from a state that allowed (SYN) packets to be parked in the socket
      backlog while socket is owned by the thread doing the listen() call.
      
      Sure enough syzkaller found this and reported the bug ;)
      
      =================================
      [ INFO: inconsistent lock state ]
      4.10.0+ #60 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      syz-executor0/5090 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&hashinfo->ehash_locks[i])->rlock){+.?...}, at:
      [<ffffffff83a6a370>] spin_lock include/linux/spinlock.h:299 [inline]
       (&(&hashinfo->ehash_locks[i])->rlock){+.?...}, at:
      [<ffffffff83a6a370>] inet_ehash_insert+0x240/0xad0
      net/ipv4/inet_hashtables.c:407
      {IN-SOFTIRQ-W} state was registered at:
        mark_irqflags kernel/locking/lockdep.c:2923 [inline]
        __lock_acquire+0xbcf/0x3270 kernel/locking/lockdep.c:3295
        lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
        __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
        _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
        spin_lock include/linux/spinlock.h:299 [inline]
        inet_ehash_insert+0x240/0xad0 net/ipv4/inet_hashtables.c:407
        reqsk_queue_hash_req net/ipv4/inet_connection_sock.c:753 [inline]
        inet_csk_reqsk_queue_hash_add+0x1b7/0x2a0 net/ipv4/inet_connection_sock.c:764
        tcp_conn_request+0x25cc/0x3310 net/ipv4/tcp_input.c:6399
        tcp_v4_conn_request+0x157/0x220 net/ipv4/tcp_ipv4.c:1262
        tcp_rcv_state_process+0x802/0x4130 net/ipv4/tcp_input.c:5889
        tcp_v4_do_rcv+0x56b/0x940 net/ipv4/tcp_ipv4.c:1433
        tcp_v4_rcv+0x2e12/0x3210 net/ipv4/tcp_ipv4.c:1711
        ip_local_deliver_finish+0x4ce/0xc40 net/ipv4/ip_input.c:216
        NF_HOOK include/linux/netfilter.h:257 [inline]
        ip_local_deliver+0x1ce/0x710 net/ipv4/ip_input.c:257
        dst_input include/net/dst.h:492 [inline]
        ip_rcv_finish+0xb1d/0x2110 net/ipv4/ip_input.c:396
        NF_HOOK include/linux/netfilter.h:257 [inline]
        ip_rcv+0xd90/0x19c0 net/ipv4/ip_input.c:487
        __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4179
        __netif_receive_skb+0x2a/0x170 net/core/dev.c:4217
        netif_receive_skb_internal+0x1d6/0x430 net/core/dev.c:4245
        napi_skb_finish net/core/dev.c:4602 [inline]
        napi_gro_receive+0x4e6/0x680 net/core/dev.c:4636
        e1000_receive_skb drivers/net/ethernet/intel/e1000/e1000_main.c:4033 [inline]
        e1000_clean_rx_irq+0x5e0/0x1490
      drivers/net/ethernet/intel/e1000/e1000_main.c:4489
        e1000_clean+0xb9a/0x2910 drivers/net/ethernet/intel/e1000/e1000_main.c:3834
        napi_poll net/core/dev.c:5171 [inline]
        net_rx_action+0xe70/0x1900 net/core/dev.c:5236
        __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
        invoke_softirq kernel/softirq.c:364 [inline]
        irq_exit+0x19e/0x1d0 kernel/softirq.c:405
        exiting_irq arch/x86/include/asm/apic.h:658 [inline]
        do_IRQ+0x81/0x1a0 arch/x86/kernel/irq.c:250
        ret_from_intr+0x0/0x20
        native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
        arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
        default_idle+0x8f/0x410 arch/x86/kernel/process.c:271
        arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:262
        default_idle_call+0x36/0x60 kernel/sched/idle.c:96
        cpuidle_idle_call kernel/sched/idle.c:154 [inline]
        do_idle+0x348/0x440 kernel/sched/idle.c:243
        cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:345
        start_secondary+0x344/0x440 arch/x86/kernel/smpboot.c:272
        verify_cpu+0x0/0xfc
      irq event stamp: 1741
      hardirqs last  enabled at (1741): [<ffffffff84d49d77>]
      __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
      [inline]
      hardirqs last  enabled at (1741): [<ffffffff84d49d77>]
      _raw_spin_unlock_irqrestore+0xf7/0x1a0 kernel/locking/spinlock.c:191
      hardirqs last disabled at (1740): [<ffffffff84d4a732>]
      __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
      hardirqs last disabled at (1740): [<ffffffff84d4a732>]
      _raw_spin_lock_irqsave+0xa2/0x110 kernel/locking/spinlock.c:159
      softirqs last  enabled at (1738): [<ffffffff84d4deff>]
      __do_softirq+0x7cf/0xb7d kernel/softirq.c:310
      softirqs last disabled at (1571): [<ffffffff84d4b92c>]
      do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&hashinfo->ehash_locks[i])->rlock);
        <Interrupt>
          lock(&(&hashinfo->ehash_locks[i])->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by syz-executor0/5090:
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83406b43>] lock_sock
      include/net/sock.h:1460 [inline]
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83406b43>]
      sock_setsockopt+0x233/0x1e40 net/core/sock.c:683
      
      stack backtrace:
      CPU: 1 PID: 5090 Comm: syz-executor0 Not tainted 4.10.0+ #60
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15 [inline]
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       print_usage_bug+0x3ef/0x450 kernel/locking/lockdep.c:2387
       valid_state kernel/locking/lockdep.c:2400 [inline]
       mark_lock_irq kernel/locking/lockdep.c:2602 [inline]
       mark_lock+0xf30/0x1410 kernel/locking/lockdep.c:3065
       mark_irqflags kernel/locking/lockdep.c:2941 [inline]
       __lock_acquire+0x6dc/0x3270 kernel/locking/lockdep.c:3295
       lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
       __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
       _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
       spin_lock include/linux/spinlock.h:299 [inline]
       inet_ehash_insert+0x240/0xad0 net/ipv4/inet_hashtables.c:407
       reqsk_queue_hash_req net/ipv4/inet_connection_sock.c:753 [inline]
       inet_csk_reqsk_queue_hash_add+0x1b7/0x2a0 net/ipv4/inet_connection_sock.c:764
       dccp_v6_conn_request+0xada/0x11b0 net/dccp/ipv6.c:380
       dccp_rcv_state_process+0x51e/0x1660 net/dccp/input.c:606
       dccp_v6_do_rcv+0x213/0x350 net/dccp/ipv6.c:632
       sk_backlog_rcv include/net/sock.h:896 [inline]
       __release_sock+0x127/0x3a0 net/core/sock.c:2052
       release_sock+0xa5/0x2b0 net/core/sock.c:2539
       sock_setsockopt+0x60f/0x1e40 net/core/sock.c:1016
       SYSC_setsockopt net/socket.c:1782 [inline]
       SyS_setsockopt+0x2fb/0x3a0 net/socket.c:1765
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x4458b9
      RSP: 002b:00007fe8b26c2b58 EFLAGS: 00000292 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00000000004458b9
      RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000006
      RBP: 00000000006e2110 R08: 0000000000000010 R09: 0000000000000000
      R10: 00000000208c3000 R11: 0000000000000292 R12: 0000000000708000
      R13: 0000000020000000 R14: 0000000000001000 R15: 0000000000000000
      
      Fixes: 5413d1ba ("net: do not block BH while processing socket backlog")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      449809a6
    • Gary Lin's avatar
      bpf: update the comment about the length of analysis · eba38a96
      Gary Lin authored
      Commit 07016151 ("bpf, verifier: further improve search
      pruning") increased the limit of processed instructions from
      32k to 64k, but the comment still mentioned the 32k limit.
      This commit updates the comment to reflect the change.
      
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGary Lin <glin@suse.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eba38a96
    • Yotam Gigi's avatar
      bridge: Fix error path in nbp_vlan_init · df2c4334
      Yotam Gigi authored
      Fix error path order in nbp_vlan_init, so if switchdev_port_attr_set
      call failes, the vlan_hash wouldn't be destroyed before inited.
      
      Fixes: efa5356b ("bridge: per vlan dst_metadata netlink support")
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Acked-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df2c4334
    • Liping Zhang's avatar
      net: route: add missing nla_policy entry for RTA_MARK attribute · 3b45a410
      Liping Zhang authored
      This will add stricter validating for RTA_MARK attribute.
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b45a410
    • Felix Jia's avatar
      net/ipv6: avoid possible dead locking on addr_gen_mode sysctl · 8c171d6c
      Felix Jia authored
      The addr_gen_mode variable can be accessed by both sysctl and netlink.
      Repleacd rtnl_lock() with rtnl_trylock() protect the sysctl operation to
      avoid the possbile dead lock.`
      Signed-off-by: default avatarFelix Jia <felix.jia@alliedtelesis.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c171d6c