1. 07 Feb, 2017 13 commits
  2. 06 Feb, 2017 9 commits
    • Arnd Bergmann's avatar
      hns: avoid stack overflow with CONFIG_KASAN · b3f2d07f
      Arnd Bergmann authored
      The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
      an indexed load for the register address, but it has an absolutely detrimental
      effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
      kernel stack overflow aside from very complex object code:
      
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
      hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
      hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
      hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
      hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
      hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
      hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
      hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
      hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
      hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
      hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
      seems safe anyway and it avoids a serious issue for some people. I have verified
      that with gcc-5.3.1, the object code we get is better in the new version
      both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
      stack frame for hns_dsaf_get_regs() but otherwise have practically identical
      object code.
      
      With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
      good either way.
      
      This patch is probably not urgent to get into 4.11 as only KASAN=y builds
      with certain compilers are affected, but I still think it makes sense to
      backport into older kernels.
      
      Cc: stable@vger.kernel.org
      Fixes: 511e6bc0 ("net: add Hisilicon Network Subsystem DSAF support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3f2d07f
    • Linus Lüssing's avatar
      ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches · a088d1d7
      Linus Lüssing authored
      When for instance a mobile Linux device roams from one access point to
      another with both APs sharing the same broadcast domain and a
      multicast snooping switch in between:
      
      1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)
      
      2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)
      
      Then currently IPv6 multicast packets will get lost for (c) until an
      MLD Querier sends its next query message. The packet loss occurs
      because upon roaming the Linux host so far stayed silent regarding
      MLD and the snooping switch will therefore be unaware of the
      multicast topology change for a while.
      
      This patch fixes this by always resending MLD reports when an interface
      change happens, for instance from NO-CARRIER to CARRIER state.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a088d1d7
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2017-02-06' of... · 62f01db9
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2017-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.10
      
      Only one important fix for rtlwifi which fixes a regression introduced
      in 4.9 and which caused problems for many users.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62f01db9
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-02-06' of... · 89389b4d
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A few simple fixes:
       * fix FILS AEAD cipher usage to use the correct AAD vectors
         and to use synchronous algorithms
       * fix using mesh HT operation data from userspace
       * fix adding mesh vendor elements to beacons & plink frames
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89389b4d
    • Eric Dumazet's avatar
      ipv6: tcp: add a missing tcp_v6_restore_cb() · ebf6c9cb
      Eric Dumazet authored
      Dmitry reported use-after-free in ip6_datagram_recv_specific_ctl()
      
      A similar bug was fixed in commit 8ce48623 ("ipv6: tcp: restore
      IP6CB for pktoptions skbs"), but I missed another spot.
      
      tcp_v6_syn_recv_sock() can indeed set np->pktoptions from ireq->pktopts
      
      Fixes: 971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
      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>
      ebf6c9cb
    • Masashi Honma's avatar
      nl80211: Fix mesh HT operation check · fd551bac
      Masashi Honma authored
      A previous change to fix checks for NL80211_MESHCONF_HT_OPMODE
      missed setting the flag when replacing FILL_IN_MESH_PARAM_IF_SET
      with checking codes. This results in dropping the received HT
      operation value when called by nl80211_update_mesh_config(). Fix
      this by setting the flag properly.
      
      Fixes: 9757235f ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      [rewrite commit message to use Fixes: line]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fd551bac
    • Thorsten Horstmann's avatar
      mac80211: Fix adding of mesh vendor IEs · da7061c8
      Thorsten Horstmann authored
      The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
      it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
      return value in mesh_add_vendor_ies must therefore be checked against
      ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
      WLAN_EID_VENDOR_SPECIFIC will be rejected.
      
      Fixes: 082ebb0c ("mac80211: fix mesh beacon format")
      Signed-off-by: default avatarThorsten Horstmann <thorsten@defutech.de>
      Signed-off-by: default avatarMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      [sven@narfation.org: Add commit message]
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      da7061c8
    • Jouni Malinen's avatar
      mac80211: Allocate a sync skcipher explicitly for FILS AEAD · 01fba20b
      Jouni Malinen authored
      The skcipher could have been of the async variant which may return from
      skcipher_encrypt() with -EINPROGRESS after having queued the request.
      The FILS AEAD implementation here does not have code for dealing with
      that possibility, so allocate a sync cipher explicitly to avoid
      potential issues with hardware accelerators.
      
      This is based on the patch sent out by Ard.
      
      Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      01fba20b
    • Jouni Malinen's avatar
      mac80211: Fix FILS AEAD protection in Association Request frame · e479ab65
      Jouni Malinen authored
      Incorrect num_elem parameter value (1 vs. 5) was used in the
      aes_siv_encrypt() call. This resulted in only the first one of the five
      AAD vectors to SIV getting included in calculation. This does not
      protect all the contents correctly and would not interoperate with a
      standard compliant implementation.
      
      Fix this by using the correct number. A matching fix is needed in the AP
      side (hostapd) to get FILS authentication working properly.
      
      Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e479ab65
  3. 05 Feb, 2017 3 commits
  4. 03 Feb, 2017 7 commits
    • Eric Dumazet's avatar
      net: use a work queue to defer net_disable_timestamp() work · 5fa8bbda
      Eric Dumazet authored
      Dmitry reported a warning [1] showing that we were calling
      net_disable_timestamp() -> static_key_slow_dec() from a non
      process context.
      
      Grabbing a mutex while holding a spinlock or rcu_read_lock()
      is not allowed.
      
      As Cong suggested, we now use a work queue.
      
      It is possible netstamp_clear() exits while netstamp_needed_deferred
      is not zero, but it is probably not worth trying to do better than that.
      
      netstamp_needed_deferred atomic tracks the exact number of deferred
      decrements.
      
      [1]
      [ INFO: suspicious RCU usage. ]
      4.10.0-rc5+ #192 Not tainted
      -------------------------------
      ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
      critical section!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 0
      2 locks held by syz-executor14/23111:
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
      include/net/sock.h:1454 [inline]
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
      rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
       #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
      include/linux/netfilter.h:201 [inline]
       #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
      __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160
      
      stack backtrace:
      CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
      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+0x2ee/0x3ef lib/dump_stack.c:51
       lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
       rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
       ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
       __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
       mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
       atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
       __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
       static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
       net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
       sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
       __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sock_wfree+0xae/0x120 net/core/sock.c:1645
       skb_release_head_state+0xfc/0x200 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/0x4c0 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 [inline]
       nf_ct_frag6_gather+0x1106/0x3840
      net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook include/linux/netfilter.h:212 [inline]
       __ip6_local_out+0x489/0x840 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 [inline]
       rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x600 net/socket.c:848
       do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
       do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
       vfs_writev+0x87/0xc0 fs/read_write.c:911
       do_writev+0x110/0x2c0 fs/read_write.c:944
       SYSC_writev fs/read_write.c:1017 [inline]
       SyS_writev+0x27/0x30 fs/read_write.c:1014
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x445559
      RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
      RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
      RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
      R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
      BUG: sleeping function called from invalid context at
      kernel/locking/mutex.c:752
      in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
      INFO: lockdep is turned off.
      CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
      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+0x2ee/0x3ef lib/dump_stack.c:51
       ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
       __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
       mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
       atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
       __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
       static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
       net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
       sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
       __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sock_wfree+0xae/0x120 net/core/sock.c:1645
       skb_release_head_state+0xfc/0x200 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/0x4c0 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 [inline]
       nf_ct_frag6_gather+0x1106/0x3840
      net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook include/linux/netfilter.h:212 [inline]
       __ip6_local_out+0x489/0x840 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 [inline]
       rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x600 net/socket.c:848
       do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
       do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
       vfs_writev+0x87/0xc0 fs/read_write.c:911
       do_writev+0x110/0x2c0 fs/read_write.c:944
       SYSC_writev fs/read_write.c:1017 [inline]
       SyS_writev+0x27/0x30 fs/read_write.c:1014
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x445559
      
      Fixes: b90e5794 ("net: dont call jump_label_dec from irq context")
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fa8bbda
    • Stanislaw Gruszka's avatar
      ethtool: do not vzalloc(0) on registers dump · 3808d348
      Stanislaw Gruszka authored
      If ->get_regs_len() callback return 0, we allocate 0 bytes of memory,
      what print ugly warning in dmesg, which can be found further below.
      
      This happen on mac80211 devices where ieee80211_get_regs_len() just
      return 0 and driver only fills ethtool_regs structure and actually
      do not provide any dump. However I assume this can happen on other
      drivers i.e. when for some devices driver provide regs dump and for
      others do not. Hence preventing to to print warning in ethtool code
      seems to be reasonable.
      
      ethtool: vmalloc: allocation failure: 0 bytes, mode:0x24080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO)
      <snip>
      Call Trace:
      [<ffffffff813bde47>] dump_stack+0x63/0x8c
      [<ffffffff811b0a1f>] warn_alloc+0x13f/0x170
      [<ffffffff811f0476>] __vmalloc_node_range+0x1e6/0x2c0
      [<ffffffff811f0874>] vzalloc+0x54/0x60
      [<ffffffff8169986c>] dev_ethtool+0xb4c/0x1b30
      [<ffffffff816adbb1>] dev_ioctl+0x181/0x520
      [<ffffffff816714d2>] sock_do_ioctl+0x42/0x50
      <snip>
      Mem-Info:
      active_anon:435809 inactive_anon:173951 isolated_anon:0
       active_file:835822 inactive_file:196932 isolated_file:0
       unevictable:0 dirty:8 writeback:0 unstable:0
       slab_reclaimable:157732 slab_unreclaimable:10022
       mapped:83042 shmem:306356 pagetables:9507 bounce:0
       free:130041 free_pcp:1080 free_cma:0
      Node 0 active_anon:1743236kB inactive_anon:695804kB active_file:3343288kB inactive_file:787728kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:332168kB dirty:32kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 1225424kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
      Node 0 DMA free:15900kB min:136kB low:168kB high:200kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15984kB managed:15900kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
      lowmem_reserve[]: 0 3187 7643 7643
      Node 0 DMA32 free:419732kB min:28124kB low:35152kB high:42180kB active_anon:541180kB inactive_anon:248988kB active_file:1466388kB inactive_file:389632kB unevictable:0kB writepending:0kB present:3370280kB managed:3290932kB mlocked:0kB slab_reclaimable:217184kB slab_unreclaimable:4180kB kernel_stack:160kB pagetables:984kB bounce:0kB free_pcp:2236kB local_pcp:660kB free_cma:0kB
      lowmem_reserve[]: 0 0 4456 4456
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3808d348
    • David Lebrun's avatar
      ipv6: sr: remove cleanup flag and fix HMAC computation · 013e8167
      David Lebrun authored
      In the latest version of the IPv6 Segment Routing IETF draft [1] the
      cleanup flag is removed and the flags field length is shrunk from 16 bits
      to 8 bits. As a consequence, the input of the HMAC computation is modified
      in a non-backward compatible way by covering the whole octet of flags
      instead of only the cleanup bit. As such, if an implementation compatible
      with the latest draft computes the HMAC of an SRH who has other flags set
      to 1, then the HMAC result would differ from the current implementation.
      
      This patch carries those modifications to prevent conflict with other
      implementations of IPv6 SR.
      
      [1] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05Signed-off-by: default avatarDavid Lebrun <david.lebrun@uclouvain.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      013e8167
    • Mao Wenan's avatar
      net: phy: Fix lack of reference count on PHY driver · cafe8df8
      Mao Wenan authored
      There is currently no reference count being held on the PHY driver,
      which makes it possible to remove the PHY driver module while the PHY
      state machine is running and polling the PHY. This could cause crashes
      similar to this one to show up:
      
      [   43.361162] BUG: unable to handle kernel NULL pointer dereference at 0000000000000140
      [   43.361162] IP: phy_state_machine+0x32/0x490
      [   43.361162] PGD 59dc067
      [   43.361162] PUD 0
      [   43.361162]
      [   43.361162] Oops: 0000 [#1] SMP
      [   43.361162] Modules linked in: dsa_loop [last unloaded: broadcom]
      [   43.361162] CPU: 0 PID: 1299 Comm: kworker/0:3 Not tainted 4.10.0-rc5+ #415
      [   43.361162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      [   43.361162] Workqueue: events_power_efficient phy_state_machine
      [   43.361162] task: ffff880006782b80 task.stack: ffffc90000184000
      [   43.361162] RIP: 0010:phy_state_machine+0x32/0x490
      [   43.361162] RSP: 0018:ffffc90000187e18 EFLAGS: 00000246
      [   43.361162] RAX: 0000000000000000 RBX: ffff8800059e53c0 RCX:
      ffff880006a15c60
      [   43.361162] RDX: ffff880006782b80 RSI: 0000000000000000 RDI:
      ffff8800059e5428
      [   43.361162] RBP: ffffc90000187e48 R08: ffff880006a15c40 R09:
      0000000000000000
      [   43.361162] R10: 0000000000000000 R11: 0000000000000000 R12:
      ffff8800059e5428
      [   43.361162] R13: ffff8800059e5000 R14: 0000000000000000 R15:
      ffff880006a15c40
      [   43.361162] FS:  0000000000000000(0000) GS:ffff880006a00000(0000)
      knlGS:0000000000000000
      [   43.361162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   43.361162] CR2: 0000000000000140 CR3: 0000000005979000 CR4:
      00000000000006f0
      [   43.361162] Call Trace:
      [   43.361162]  process_one_work+0x1b4/0x3e0
      [   43.361162]  worker_thread+0x43/0x4d0
      [   43.361162]  ? __schedule+0x17f/0x4e0
      [   43.361162]  kthread+0xf7/0x130
      [   43.361162]  ? process_one_work+0x3e0/0x3e0
      [   43.361162]  ? kthread_create_on_node+0x40/0x40
      [   43.361162]  ret_from_fork+0x29/0x40
      [   43.361162] Code: 56 41 55 41 54 4c 8d 67 68 53 4c 8d af 40 fc ff ff
      48 89 fb 4c 89 e7 48 83 ec 08 e8 c9 9d 27 00 48 8b 83 60 ff ff ff 44 8b
      73 98 <48> 8b 90 40 01 00 00 44 89 f0 48 85 d2 74 08 4c 89 ef ff d2 8b
      
      Keep references on the PHY driver module right before we are going to
      utilize it in phy_attach_direct(), and conversely when we don't use it
      anymore in phy_detach().
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      [florian: rebase, rework commit message]
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cafe8df8
    • David S. Miller's avatar
      Merge branch 'mlx4-queue-reinit' · 2372bcda
      David S. Miller authored
      Martin KaFai Lau says:
      
      ====================
      mlx4: Misc bug fixes after reinitializing queues
      
      This patchset fixes misc bugs after reinitializing
      queues (e.g. by ethtool -L).
      
      v2:
      * Add another fix to mem leak in tx_ring[t] and tx_cq[t]
      * In mlx4_en_try_alloc_resources(),
        move all xdp_prog logic after calling mlx4_en_alloc_resources()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2372bcda
    • Martin KaFai Lau's avatar
      mlx4: xdp_prog becomes inactive after ethtool '-L' or '-G' · 770f8225
      Martin KaFai Lau authored
      After calling mlx4_en_try_alloc_resources (e.g. by changing the
      number of rx-queues with ethtool -L), the existing xdp_prog becomes
      inactive.
      
      The bug is that the xdp_prog ptr has not been carried over from
      the old rx-queues to the new rx-queues
      
      Fixes: 47a38e15 ("net/mlx4_en: add support for fast rx drop bpf program")
      Cc: Brenden Blanco <bblanco@plumgrid.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      770f8225
    • Martin KaFai Lau's avatar
      mlx4: Fix memory leak after mlx4_en_update_priv() · f32b20e8
      Martin KaFai Lau authored
      In mlx4_en_update_priv(), dst->tx_ring[t] and dst->tx_cq[t]
      are over-written by src->tx_ring[t] and src->tx_cq[t] without
      first calling kfree.
      
      One of the reproducible code paths is by doing 'ethtool -L'.
      
      The fix is to do the kfree in mlx4_en_free_resources().
      
      Here is the kmemleak report:
      unreferenced object 0xffff880841211800 (size 2048):
        comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 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:
          [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
          [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
          [<ffffffff8170e0a8>] mlx4_en_try_alloc_resources+0x118/0x1a0
          [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
          [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
          [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
          [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
          [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
          [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
          [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
          [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
          [<ffffffffffffffff>] 0xffffffffffffffff
      unreferenced object 0xffff880841213000 (size 2048):
        comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 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:
          [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
          [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
          [<ffffffff8170e0cb>] mlx4_en_try_alloc_resources+0x13b/0x1a0
          [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
          [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
          [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
          [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
          [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
          [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
          [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
          [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      (gdb) list *mlx4_en_try_alloc_resources+0x118
      0xffffffff8170e0a8 is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2145).
      2140                    if (!dst->tx_ring_num[t])
      2141                            continue;
      2142
      2143                    dst->tx_ring[t] = kzalloc(sizeof(struct mlx4_en_tx_ring *) *
      2144                                              MAX_TX_RINGS, GFP_KERNEL);
      2145                    if (!dst->tx_ring[t])
      2146                            goto err_free_tx;
      2147
      2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
      2149                                            MAX_TX_RINGS, GFP_KERNEL);
      (gdb) list *mlx4_en_try_alloc_resources+0x13b
      0xffffffff8170e0cb is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2150).
      2145                    if (!dst->tx_ring[t])
      2146                            goto err_free_tx;
      2147
      2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
      2149                                            MAX_TX_RINGS, GFP_KERNEL);
      2150                    if (!dst->tx_cq[t]) {
      2151                            kfree(dst->tx_ring[t]);
      2152                            goto err_free_tx;
      2153                    }
      2154            }
      
      Fixes: ec25bc04 ("net/mlx4_en: Add resilience in low memory systems")
      Cc: Eugenia Emantayev <eugenia@mellanox.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f32b20e8
  5. 01 Feb, 2017 8 commits