1. 10 11月, 2015 4 次提交
    • V
      macvtap: Resolve possible __might_sleep warning in macvtap_do_read() · a499a2e9
      Vlad Yasevich 提交于
      macvtap_do_read code calls macvtap_put_user while it might be set up
      to wait for the user.  This results in the following warning:
      
      Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------
      Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c:
      7286 __might_sleep+0x7f/0x90()
      Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state
      =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+
       #11
      Jun 23 16:25:26 galen kernel: Call Trace:
      Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65
      Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc
      0
      Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ?  trace_hardirqs_on_caller+0x fd/0x1c0
      Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360
      Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ?  prepare_to_wait_event+0x110/0x110
      Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0
      Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140
      Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76
      Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]---
      
      Make sure thet we call finish_wait() if we have the skb to process
      before trying to actually process it.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a499a2e9
    • A
      mvneta: add FIXED_PHY dependency · 4bed5395
      Arnd Bergmann 提交于
      The fixed_phy infrastructure is done in a way that is optional,
      by providing 'static inline' helper functions doing nothing in
      include/linux/phy_fixed.h for all its APIs. However, three out
      of the four users (DSA, BCMGENET, and SYSTEMPORT) always
      'select FIXED_PHY', presumably because they need that.
      MVNETA is the fourth one, and if that is built-in but FIXED_PHY
      is configured as a loadable module, we get a link error:
      
      drivers/built-in.o: In function `mvneta_fixed_link_update':
      fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state'
      
      Presumably this driver has the same dependency as the others,
      so this patch also uses 'select' to ensure that the fixed-phy
      support is built-in.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 898b2970 ("mvneta: implement SGMII-based in-band link state signaling")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bed5395
    • R
      net: caif: check return value of alloc_netdev · cfb76d77
      Rasmus Villemoes 提交于
      I don't know if dev can actually be NULL here, but the test should be
      above alloc_netdev(), to avoid leaking the struct net_device in case
      dev is actually NULL. And of course the return value from alloc_netdev
      should be tested.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfb76d77
    • G
      net: hisilicon: NET_VENDOR_HISILICON should depend on HAS_DMA · 3870502a
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
      
      As this affects all of HNS_ENET, HNS_DSAF, HNS, HIX5HD2_GMAC, and
      HIP04_ETH, add a dependency on HAS_DMA to the main NET_VENDOR_HISILICON
      symbol to fix this.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3870502a
  2. 09 11月, 2015 10 次提交
  3. 08 11月, 2015 4 次提交
    • M
      dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put" · 3694bfbd
      Markus Elfring 提交于
      The of_node_put() function tests whether its argument is NULL
      and then returns immediately.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3694bfbd
    • J
      bonding: fix panic on non-ARPHRD_ETHER enslave failure · 40baec22
      Jay Vosburgh 提交于
      Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
      are not ARPHRD_ETHER, if needed, it resets the bonding device back to
      ARPHRD_ETHER by calling ether_setup.
      
      	Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
      if the bond device is up, leaving it in a quasi-down state without
      having actually gone through dev_close.  For bonding, if any periodic
      work queue items are active (miimon, arp_interval, etc), those will
      remain running, as they are stopped by bond_close.  At this point, if
      the bonding module is unloaded or the bond is deleted, the system will
      panic when the work function is called.
      
      	This panic is resolved by calling dev_close on the bond itself
      prior to calling ether_setup.
      
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40baec22
    • J
      net/qlcnic: fix mac address restore in bond mode 5/6 · e824de8a
      Jarod Wilson 提交于
      The bonding driver saves a copy of slaves' original mac address and then
      assigns whatever mac as needed to the slave, depending on mode. In at
      least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
      mac address of another slave. On release from the bond, the original mac
      address is supposed to get restored via a dev_set_mac_address() call in
      the bonding driver's __bond_release_one() function, which calls the
      slave's ndo_set_mac_address function, which for qlcnic, is
      qlcnic_set_mac().
      
      Now, this function tries to be somewhat intelligent and exit early if
      you're trying to set the mac address to the same thing that is already
      set. The problem here is that adapter->mac_addr isn't in sync with
      netdev->dev_addr. The qlcnic driver still has the original mac stored in
      adapter->mac_addr, while the bonding driver has updated netdev->dev_addr,
      so qlcnic thinks we're trying to set the same address it already has.
      
      I think the way to go here, since the function updates both netdev and
      adapter's stored mac addresses, is to check if either of them doesn't
      match the newly requested mac. Simply checking netdev's value only could
      result in a similar mismatch and non-update, so look at both.
      
      CC: Dept-GELinuxNICDev@qlogic.com
      CC: netdev@vger.kernel.org
      CC: Manish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e824de8a
    • M
      fjes: Delete an unnecessary check before the function call "vfree" · f7b5964d
      Markus Elfring 提交于
      The vfree() function performs also input parameter validation.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7b5964d
  4. 06 11月, 2015 16 次提交
  5. 05 11月, 2015 6 次提交