1. 28 Sep, 2016 17 commits
  2. 27 Sep, 2016 12 commits
  3. 26 Sep, 2016 11 commits
    • David S. Miller's avatar
      Merge branch 'bnx2x-fix-page-allocation-failure' · be92e538
      David S. Miller authored
      Jason Baron says:
      
      ====================
      bnx2x: page allocation failure
      
      While configuring ~500 multicast addrs, we ran into high order
      page allocation failures. They don't need to be high order, and
      thus I'm proposing to split them into at most PAGE_SIZE allocations.
      
      Below is a sample failure.
      
      [1201902.617882] bnx2x: [bnx2x_set_mc_list:12374(eth0)]Failed to create multicast MACs list: -12
      [1207325.695021] kworker/1:0: page allocation failure: order:2, mode:0xc020
      [1207325.702059] CPU: 1 PID: 15805 Comm: kworker/1:0 Tainted: G        W
      [1207325.712940] Hardware name: SYNNEX CORPORATION 1x8-X4i SSD 10GE/S5512LE, BIOS V8.810 05/16/2013
      [1207325.722284] Workqueue: events bnx2x_sp_rtnl_task [bnx2x]
      [1207325.728206]  0000000000000000 ffff88012d873a78 ffffffff8267f7c7 000000000000c020
      [1207325.736754]  0000000000000000 ffff88012d873b08 ffffffff8212f8e0 fffffffc00000003
      [1207325.745301]  ffff88041ffecd80 ffff880400000030 0000000000000002 0000c0206800da13
      [1207325.753846] Call Trace:
      [1207325.756789]  [<ffffffff8267f7c7>] dump_stack+0x4d/0x63
      [1207325.762426]  [<ffffffff8212f8e0>] warn_alloc_failed+0xe0/0x130
      [1207325.768756]  [<ffffffff8213c898>] ? wakeup_kswapd+0x48/0x140
      [1207325.774914]  [<ffffffff82132afc>] __alloc_pages_nodemask+0x2bc/0x970
      [1207325.781761]  [<ffffffff82173691>] alloc_pages_current+0x91/0x100
      [1207325.788260]  [<ffffffff8212fa1e>] alloc_kmem_pages+0xe/0x10
      [1207325.794329]  [<ffffffff8214c9c8>] kmalloc_order+0x18/0x50
      [1207325.800227]  [<ffffffff8214ca26>] kmalloc_order_trace+0x26/0xb0
      [1207325.806642]  [<ffffffff82451c68>] ? _xfer_secondary_pool+0xa8/0x1a0
      [1207325.813404]  [<ffffffff8217cfda>] __kmalloc+0x19a/0x1b0
      [1207325.819142]  [<ffffffffa02fe975>] bnx2x_set_rx_mode_inner+0x3d5/0x590 [bnx2x]
      [1207325.827000]  [<ffffffffa02ff52d>] bnx2x_sp_rtnl_task+0x28d/0x760 [bnx2x]
      [1207325.834197]  [<ffffffff820695d4>] process_one_work+0x134/0x3c0
      [1207325.840522]  [<ffffffff82069981>] worker_thread+0x121/0x460
      [1207325.846585]  [<ffffffff82069860>] ? process_one_work+0x3c0/0x3c0
      [1207325.853089]  [<ffffffff8206f039>] kthread+0xc9/0xe0
      [1207325.858459]  [<ffffffff82070000>] ? notify_die+0x10/0x40
      [1207325.864263]  [<ffffffff8206ef70>] ? kthread_create_on_node+0x180/0x180
      [1207325.871288]  [<ffffffff826852d2>] ret_from_fork+0x42/0x70
      [1207325.877183]  [<ffffffff8206ef70>] ? kthread_create_on_node+0x180/0x180
      
      v2:
       -make use of list_next_entry()
       -only use PAGE_SIZE allocations
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be92e538
    • Jason Baron's avatar
      bnx2x: allocate mac filtering pending list in PAGE_SIZE increments · 3129e159
      Jason Baron authored
      Currently, we can have high order page allocations that specify
      GFP_ATOMIC when configuring multicast MAC address filters.
      
      For example, we have seen order 2 page allocation failures with
      ~500 multicast addresses configured.
      
      Convert the allocation for the pending list to be done in PAGE_SIZE
      increments.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Acked-by: default avatarYuval Mintz <Yuval.Mintz@caviumnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3129e159
    • Jason Baron's avatar
      bnx2x: allocate mac filtering 'mcast_list' in PAGE_SIZE increments · e8c6ae9f
      Jason Baron authored
      Currently, we can have high order page allocations that specify
      GFP_ATOMIC when configuring multicast MAC address filters.
      
      For example, we have seen order 2 page allocation failures with
      ~500 multicast addresses configured.
      
      Convert the allocation for 'mcast_list' to be done in PAGE_SIZE
      increments.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8c6ae9f
    • Arnd Bergmann's avatar
      nfp: bpf: improve handling for disabled BPF syscall · b47c62c5
      Arnd Bergmann authored
      I stumbled over a new warning during randconfig testing,
      with CONFIG_BPF_SYSCALL disabled:
      
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function 'nfp_net_bpf_offload':
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void *)&res+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: 'res.n_instr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      As far as I can tell, this is a false positive caused by the compiler
      getting confused about a function that is partially inlined, but it's
      easy to avoid while improving the code:
      
      The nfp_bpf_jit() stub helper for that configuration is unusual as it
      is defined in a header file but not marked 'static inline'. By moving
      the compile-time check into the caller using the IS_ENABLED() macro,
      we can remove that stub and simplify the nfp_net_bpf_offload_prepare()
      function enough to unconfuse the compiler.
      
      Fixes: 7533fdc0 ("nfp: bpf: add hardware bpf offload")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b47c62c5
    • Baoyou Xie's avatar
      net: bcmgenet: remove unused function in bcmgenet.c · e2072600
      Baoyou Xie authored
      We get 1 warning when building kernel with W=1:
      drivers/net/ethernet/broadcom/genet/bcmgenet.c:2763:5: warning: no previous prototype for 'bcmgenet_hfb_add_filter' [-Wmissing-prototypes]
      
      In fact, this function is implemented in
      drivers/net/ethernet/broadcom/genet/bcmgenet.c, but be called
      by no one, thus can be removed.
      
      So this patch removes the unused functions.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2072600
    • Baoyou Xie's avatar
      cxgb4: mark symbols static where possible · 50935857
      Baoyou Xie authored
      We get 10 warnings when building kernel with W=1:
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:304:5: warning: no previous prototype for 'cxgb4_dcb_enabled' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:194:5: warning: no previous prototype for 'setup_sge_queues_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:241:6: warning: no previous prototype for 'free_sge_queues_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:268:5: warning: no previous prototype for 'cfg_queues_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:344:6: warning: no previous prototype for 'free_queues_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:353:5: warning: no previous prototype for 'request_msix_queue_irqs_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:379:6: warning: no previous prototype for 'free_msix_queue_irqs_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:393:6: warning: no previous prototype for 'name_msix_vecs_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:433:6: warning: no previous prototype for 'enable_rx_uld' [-Wmissing-prototypes]
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:442:6: warning: no previous prototype for 'quiesce_rx_uld' [-Wmissing-prototypes]
      
      In fact, these functions are only used in the file in which they are
      declared and don't need a declaration, but can be made static.
      so this patch marks these functions with 'static'.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      50935857
    • Baoyou Xie's avatar
      net: mvneta: mark symbols static where possible · 2dc0d2b4
      Baoyou Xie authored
      We get 2 warnings when building kernel with W=1:
      drivers/net/ethernet/marvell/mvneta.c:639:27: warning: no previous prototype for 'mvneta_get_stats64' [-Wmissing-prototypes]
      drivers/net/ethernet/marvell/mvneta.c:3529:5: warning: no previous prototype for 'mvneta_ethtool_set_link_ksettings' [-Wmissing-prototypes]
      
      In fact, these two functions are only used in the file in which they are
      declared and don't need a declaration, but can be made static.
      so this patch marks these functions with 'static'.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2dc0d2b4
    • Baoyou Xie's avatar
      net: hip04: mark tx_done() static · 49e3e6f3
      Baoyou Xie authored
      We get 1 warning when building kernel with W=1:
      drivers/net/ethernet/hisilicon/hip04_eth.c:603:22: warning: no previous prototype for 'tx_done' [-Wmissing-prototypes]
      
      In fact, this function is only used in the file in which it is
      declared and don't need a declaration, but can be made static.
      so this patch marks this function with 'static'.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49e3e6f3
    • Baoyou Xie's avatar
      net: hisilicon: mark symbols static where possible · ecdad234
      Baoyou Xie authored
      We get 2 warnings when building kernel with W=1:
      drivers/net/ethernet/hisilicon/hisi_femac.c:943:5: warning: no previous prototype for 'hisi_femac_drv_suspend' [-Wmissing-prototypes]
      drivers/net/ethernet/hisilicon/hisi_femac.c:960:5: warning: no previous prototype for 'hisi_femac_drv_resume' [-Wmissing-prototypes]
      
      In fact, these two functions are only used in the file in which they are
      declared and don't need a declaration, but can be made static.
      so this patch marks these functions with 'static'.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ecdad234
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · 71527eb2
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2016-09-25
      
      Here are a few more Bluetooth & 802.15.4 patches for the 4.9 kernel that
      have popped up during the past week:
      
       - New USB ID for QCA_ROME Bluetooth device
       - NULL pointer dereference fix for Bluetooth mgmt sockets
       - Fixes for BCSP driver
       - Fix for updating LE scan response
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71527eb2
    • Wei Yongjun's avatar
      net: dsa: mv88e6xxx: fix non static symbol warnings · b3f5bf64
      Wei Yongjun authored
      Fixes the following sparse warnings:
      
      drivers/net/dsa/mv88e6xxx/chip.c:219:5: warning:
       symbol 'mv88e6xxx_port_read' was not declared. Should it be static?
      drivers/net/dsa/mv88e6xxx/chip.c:227:5: warning:
       symbol 'mv88e6xxx_port_write' was not declared. Should it be static?
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3f5bf64