1. 24 1月, 2017 1 次提交
  2. 20 1月, 2017 1 次提交
  3. 17 1月, 2017 13 次提交
    • J
      clocksource/exynos_mct: Clear interrupt when cpu is shut down · bc7c36ee
      Joonyoung Shim 提交于
      When a CPU goes offline a potentially pending timer interrupt is not
      cleared. When the CPU comes online again then the pending interrupt is
      delivered before the per cpu clockevent device is initialized. As a
      consequence the tick interrupt handler dereferences a NULL pointer.
      
      [   51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040
      [   51.289348] task: ee942d00 task.stack: ee960000
      [   51.293861] PC is at tick_periodic+0x38/0xb0
      [   51.298102] LR is at tick_handle_periodic+0x1c/0x90
      
      Clear the pending interrupt in the cpu dying path.
      
      Fixes: 56a94f13 ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier")
      Reported-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: cw00.choi@samsung.com
      Cc: daniel.lezcano@linaro.org
      Cc: stable@vger.kernel.org
      Cc: javier@osg.samsung.com
      Cc: kgene@kernel.org
      Cc: krzk@kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      bc7c36ee
    • J
      net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV · 9577b174
      Jack Morgenstein 提交于
      When running SRIOV, warnings for SRQ LIMIT events flood the Hypervisor's
      message log when (correct, normally operating) apps use SRQ LIMIT events
      as a trigger to post WQEs to SRQs.
      
      Add more information to the existing debug printout for SRQ_LIMIT, and
      output the warning messages only for the SRQ CATAS ERROR event.
      
      Fixes: acba2420 ("mlx4_core: Add wrapper functions and comm channel and slave event support to EQs")
      Fixes: e0debf9c ("mlx4_core: Reduce warning message for SRQ_LIMIT event to debug level")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9577b174
    • J
      net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions · 7c3945bc
      Jack Morgenstein 提交于
      Save the qp context flags byte containing the flag disabling vlan stripping
      in the RESET to INIT qp transition, rather than in the INIT to RTR
      transition. Per the firmware spec, the flags in this byte are active
      in the RESET to INIT transition.
      
      As a result of saving the flags in the incorrect qp transition, when
      switching dynamically from VGT to VST and back to VGT, the vlan
      remained stripped (as is required for VST) and did not return to
      not-stripped (as is required for VGT).
      
      Fixes: f0f829bf ("net/mlx4_core: Add immediate activate for VGT->VST->VGT")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c3945bc
    • J
      net/mlx4_core: Fix racy CQ (Completion Queue) free · 291c566a
      Jack Morgenstein 提交于
      In function mlx4_cq_completion() and mlx4_cq_event(), the
      radix_tree_lookup requires a rcu_read_lock.
      This is mandatory: if another core frees the CQ, it could
      run the radix_tree_node_rcu_free() call_rcu() callback while
      its being used by the radix tree lookup function.
      
      Additionally, in function mlx4_cq_event(), since we are adding
      the rcu lock around the radix-tree lookup, we no longer need to take
      the spinlock. Also, the synchronize_irq() call for the async event
      eliminates the need for incrementing the cq reference count in
      mlx4_cq_event().
      
      Other changes:
      1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock:
         we no longer take this spinlock in the interrupt context.
         The spinlock here, therefore, simply protects against different
         threads simultaneously invoking mlx4_cq_free() for different cq's.
      
      2. In function mlx4_cq_free(), we move the radix tree delete to before
         the synchronize_irq() calls. This guarantees that we will not
         access this cq during any subsequent interrupts, and therefore can
         safely free the CQ after the synchronize_irq calls. The rcu_read_lock
         in the interrupt handlers only needs to protect against corrupting the
         radix tree; the interrupt handlers may access the cq outside the
         rcu_read_lock due to the synchronize_irq calls which protect against
         premature freeing of the cq.
      
      3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg.
      
      4. We leave the cq reference count mechanism in place, because it is
         still needed for the cq completion tasklet mechanism.
      
      Fixes: 6d90aa5c ("net/mlx4_core: Make sure there are no pending async events when freeing CQ")
      Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      291c566a
    • H
      net: stmmac: don't use netdev_[dbg, info, ..] before net_device is registered · b618ab45
      Heiner Kallweit 提交于
      Don't use netdev_info and friends before the net_device is registered.
      This avoids ugly messages like
      "meson8b-dwmac c9410000.ethernet (unnamed net_device) (uninitialized):
      Enable RX Mitigation via HW Watchdog Timer"
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b618ab45
    • A
      net/mlx5e: Fix a -Wmaybe-uninitialized warning · abeffce9
      Arnd Bergmann 提交于
      As found by Olof's build bot, we gain a harmless warning about a
      potential uninitialized variable reference in mlx5:
      
      drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
      drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
      
      This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair
      that gcc is unfortunately unable to completely figure out.
      
      The problem being gcc cannot tell that if(IS_ERR()) in
      mlx5e_route_lookup_ipv4() is equivalent to checking if(err) later,
      so it assumes that 'out_dev' is used after the 'return PTR_ERR(rt)'.
      
      The PTR_ERR_OR_ZERO() case by comparison is fairly easy to detect
      by gcc, so it can't get that wrong, so it no longer warns.
      
      Hadar Hen Zion already attempted to fix the warning earlier by adding fake
      initializations, but that ended up not fully addressing all warnings, so
      I'm reverting it now that it is no longer needed.
      
      Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
      Fixes: a42485eb ("net/mlx5e: TC ipv4 tunnel encap offload error flow fixes")
      Fixes: a757d108 ("net/mlx5e: Fix kbuild warnings for uninitialized parameters")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      abeffce9
    • K
      net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types · 34c55cf2
      Karicheri, Muralidharan 提交于
      Currently dp83867 driver returns error if phy interface type
      PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
      delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
      Fix this by checking also the interface type if a particular delay
      value is missing in the phy dt bindings. Also update the DT document
      accordingly.
      Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34c55cf2
    • I
      be2net: fix MAC addr setting on privileged BE3 VFs · 34393529
      Ivan Vecera 提交于
      During interface opening MAC address stored in netdev->dev_addr is
      programmed in the HW with exception of BE3 VFs where the initial
      MAC is programmed by parent PF. This is OK when MAC address is not
      changed when an interfaces is down. In this case the requested MAC is
      stored to netdev->dev_addr and later is stored into HW during opening.
      But this is not done for all BE3 VFs so the NIC HW does not know
      anything about this change and all traffic is filtered.
      
      This is the case of bonding if fail_over_mac == 0 where the MACs of
      the slaves are changed while they are down.
      
      The be2net behavior is too restrictive because if a BE3 VF has
      the FILTMGMT privilege then it is able to modify its MAC without
      any restriction.
      
      To solve the described problem the driver should take care about these
      privileged BE3 VFs so the MAC is programmed during opening. And by
      contrast unpriviled BE3 VFs should not be allowed to change its MAC
      in any case.
      
      Cc: Sathya Perla <sathya.perla@broadcom.com>
      Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Cc: Somnath Kotur <somnath.kotur@broadcom.com>
      Signed-off-by: NIvan Vecera <cera@cera.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34393529
    • I
      be2net: don't delete MAC on close on unprivileged BE3 VFs · 6d928ae5
      Ivan Vecera 提交于
      BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
      VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
      
      Cc: Sathya Perla <sathya.perla@broadcom.com>
      Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Cc: Somnath Kotur <somnath.kotur@broadcom.com>
      Signed-off-by: NIvan Vecera <cera@cera.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d928ae5
    • I
      be2net: fix status check in be_cmd_pmac_add() · fe68d8bf
      Ivan Vecera 提交于
      Return value from be_mcc_notify_wait() contains a base completion status
      together with an additional status. The base_status() macro need to be
      used to access base status.
      
      Fixes: e3a7ae2c be2net: Changing MAC Address of a VF was broken
      Cc: Sathya Perla <sathya.perla@broadcom.com>
      Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
      Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      Cc: Somnath Kotur <somnath.kotur@broadcom.com>
      Signed-off-by: NIvan Vecera <cera@cera.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe68d8bf
    • A
      cpmac: remove hopeless #warning · d43e6fb4
      Arnd Bergmann 提交于
      The #warning was present 10 years ago when the driver first got merged.
      As the platform is rather obsolete by now, it seems very unlikely that
      the warning will cause anyone to fix the code properly.
      
      kernelci.org reports the warning for every build in the meantime, so
      I think it's better to just turn it into a code comment to reduce
      noise.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d43e6fb4
    • M
      ravb: do not use zero-length alignment DMA descriptor · 8ec3e8a1
      Masaru Nagai 提交于
      Due to alignment requirements of the hardware transmissions are split into
      two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
      followed by a descriptor for rest of the packet.
      
      In the case of IP packets the first descriptor will never be zero due to
      the way that the stack aligns buffers for IP packets. However, for non-IP
      packets it may be zero.
      
      In that case it has been reported that timeouts occur, presumably because
      transmission stops at the first zero-length DMA descriptor and thus the
      packet is not transmitted. However, in my environment a BUG is triggered as
      follows:
      
      [   20.381417] ------------[ cut here ]------------
      [   20.386054] kernel BUG at lib/swiotlb.c:495!
      [   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [   20.395805] Modules linked in:
      [   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
      [   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
      [   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
      [   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
      [   20.424625] LR is at map_single+0x4c/0x98
      [   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
      [   20.436019] sp : ffff80063a71f9b0
      [   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
      [   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
      [   20.449944] x25: 000000067abe2adc x24: 0000000000000000
      [   20.455252] x23: 0000000000200000 x22: 0000000000000001
      [   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
      [   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
      [   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
      [   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
      [   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
      [   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
      [   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
      [   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
      [   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
      [   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
      [   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
      [   20.518958]
      [   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
      [   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
      [   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
      [   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
      [   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
      [   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
      [   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
      [   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
      [   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
      [   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
      [   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
      [   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
      [   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
      [   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
      [   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
      [   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
      [   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
      [   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
      [   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
      [   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
      [   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
      [   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
      [   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
      [   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
      [   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
      [   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
      [   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
      [   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
      [   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
      [   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
      [   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
      [   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
      [   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
      [   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
      [   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
      [   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
      [   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
      [   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
      [   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
      [   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
      [   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
      [   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
      [   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
      [   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
      [   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
      [   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
      [   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
      [   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
      [   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
      [   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
      [   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
      [   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
      [   20.931867] Call trace:
      [   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
      [   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
      [   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
      [   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
      [   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
      [   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
      [   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
      [   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
      [   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
      [   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
      [   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
      [   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
      [   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
      [   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
      [   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
      [   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
      [   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
      [   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
      [   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
      [   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
      [   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
      [   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
      [   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
      [   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
      [   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
      [   21.094611] ---[ end trace 5bc544ad491f3814 ]---
      [   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
      [   21.105587] Kernel Offset: disabled
      [   21.109073] Memory Limit: none
      [   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      Fixes: 2f45d190 ("ravb: minimize TX data copying")
      Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ec3e8a1
    • E
      mlx4: do not call napi_schedule() without care · 8cf699ec
      Eric Dumazet 提交于
      Disable BH around the call to napi_schedule() to avoid following warning
      
      [   52.095499] NOHZ: local_softirq_pending 08
      [   52.421291] NOHZ: local_softirq_pending 08
      [   52.608313] NOHZ: local_softirq_pending 08
      
      Fixes: 8d59de8f ("net/mlx4_en: Process all completions in RX rings after port goes up")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Cc: Eugenia Emantayev <eugenia@mellanox.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Acked-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cf699ec
  4. 16 1月, 2017 1 次提交
  5. 14 1月, 2017 5 次提交
  6. 13 1月, 2017 15 次提交
  7. 12 1月, 2017 4 次提交