Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 7月, 2017 1 次提交
  3. 11 7月, 2017 1 次提交
  5. 08 7月, 2017 6 次提交
    • G
      net: ethernet: mediatek: remove useless code in mtk_probe() · e8df7603
      由 Gustavo A. R. Silva 提交于 
      Remove useless local variables _match_, _soc_ and the code related.

Notice that

const struct of_device_id of_mtk_match[] = {
        { .compatible = "mediatek,mt2701-eth" },
        {},
};

So match->data is NULL.
Suggested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8df7603
    • W
      bonding: avoid NETDEV_CHANGEMTU event when unregistering slave · f51048c3
      由 WANG Cong 提交于 
      As Hongjun/Nicolas summarized in their original patch:

"
When a device changes from one netns to another, it's first unregistered,
then the netns reference is updated and the dev is registered in the new
netns. Thus, when a slave moves to another netns, it is first
unregistered. This triggers a NETDEV_UNREGISTER event which is caught by
the bonding driver. The driver calls bond_release(), which calls
dev_set_mtu() and thus triggers NETDEV_CHANGEMTU (the device is still in
the old netns).
"

This is a very special case, because the device is being unregistered
no one should still care about the NETDEV_CHANGEMTU event triggered
at this point, we can avoid broadcasting this event on this path,
and avoid touching inetdev_event()/addrconf_notify() path.

It requires to export __dev_set_mtu() to bonding driver.
Reported-by: NHongjun Li <hongjun.li@6wind.com>
Reported-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f51048c3
    • Y
      net: hns: Fix a skb used after free bug · 27463ad9
      由 Yunsheng Lin 提交于 
      skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK,
which cause hns_nic_net_xmit to use a freed skb.

BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
	[17659.112635]      alloc_debug_processing+0x18c/0x1a0
	[17659.117208]      __slab_alloc+0x52c/0x560
	[17659.120909]      kmem_cache_alloc_node+0xac/0x2c0
	[17659.125309]      __alloc_skb+0x6c/0x260
	[17659.128837]      tcp_send_ack+0x8c/0x280
	[17659.132449]      __tcp_ack_snd_check+0x9c/0xf0
	[17659.136587]      tcp_rcv_established+0x5a4/0xa70
	[17659.140899]      tcp_v4_do_rcv+0x27c/0x620
	[17659.144687]      tcp_prequeue_process+0x108/0x170
	[17659.149085]      tcp_recvmsg+0x940/0x1020
	[17659.152787]      inet_recvmsg+0x124/0x180
	[17659.156488]      sock_recvmsg+0x64/0x80
	[17659.160012]      SyS_recvfrom+0xd8/0x180
	[17659.163626]      __sys_trace_return+0x0/0x4
	[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
	[17659.174000]      free_debug_processing+0x1d4/0x2c0
	[17659.178486]      __slab_free+0x240/0x390
	[17659.182100]      kmem_cache_free+0x24c/0x270
	[17659.186062]      kfree_skbmem+0xa0/0xb0
	[17659.189587]      __kfree_skb+0x28/0x40
	[17659.193025]      napi_gro_receive+0x168/0x1c0
	[17659.197074]      hns_nic_rx_up_pro+0x58/0x90
	[17659.201038]      hns_nic_rx_poll_one+0x518/0xbc0
	[17659.205352]      hns_nic_common_poll+0x94/0x140
	[17659.209576]      net_rx_action+0x458/0x5e0
	[17659.213363]      __do_softirq+0x1b8/0x480
	[17659.217062]      run_ksoftirqd+0x64/0x80
	[17659.220679]      smpboot_thread_fn+0x224/0x310
	[17659.224821]      kthread+0x150/0x170
	[17659.228084]      ret_from_fork+0x10/0x40

	BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
	[17751.080490]      __slab_alloc+0x52c/0x560
	[17751.084188]      kmem_cache_alloc+0x244/0x280
	[17751.088238]      __build_skb+0x40/0x150
	[17751.091764]      build_skb+0x28/0x100
	[17751.095115]      __alloc_rx_skb+0x94/0x150
	[17751.098900]      __napi_alloc_skb+0x34/0x90
	[17751.102776]      hns_nic_rx_poll_one+0x180/0xbc0
	[17751.107097]      hns_nic_common_poll+0x94/0x140
	[17751.111333]      net_rx_action+0x458/0x5e0
	[17751.115123]      __do_softirq+0x1b8/0x480
	[17751.118823]      run_ksoftirqd+0x64/0x80
	[17751.122437]      smpboot_thread_fn+0x224/0x310
	[17751.126575]      kthread+0x150/0x170
	[17751.129838]      ret_from_fork+0x10/0x40
	[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
	[17751.139951]      free_debug_processing+0x1d4/0x2c0
	[17751.144436]      __slab_free+0x240/0x390
	[17751.148051]      kmem_cache_free+0x24c/0x270
	[17751.152014]      kfree_skbmem+0xa0/0xb0
	[17751.155543]      __kfree_skb+0x28/0x40
	[17751.159022]      napi_gro_receive+0x168/0x1c0
	[17751.163074]      hns_nic_rx_up_pro+0x58/0x90
	[17751.167041]      hns_nic_rx_poll_one+0x518/0xbc0
	[17751.171358]      hns_nic_common_poll+0x94/0x140
	[17751.175585]      net_rx_action+0x458/0x5e0
	[17751.179373]      __do_softirq+0x1b8/0x480
	[17751.183076]      run_ksoftirqd+0x64/0x80
	[17751.186691]      smpboot_thread_fn+0x224/0x310
	[17751.190826]      kthread+0x150/0x170
	[17751.194093]      ret_from_fork+0x10/0x40

Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem")
Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Nlipeng <lipeng321@huawei.com>
Reported-by: NJun He <hjat2005@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27463ad9
    • Y
      net: hns: Fix a wrong op phy C45 code · ebe8d359
      由 Yunsheng Lin 提交于 
      As the user manual described, the second step to write to C45 phy
by mdio should be data, but not address. Here we should fix this
issue.

Fixes: 5b904d39 ("net: add Hisilicon Network Subsystem MDIO support")
Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Nlipeng <lipeng321@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebe8d359
    • V
      net: macb: Adding Support for Jumbo Frames up to 10240 Bytes in SAMA5D3 · 233a1587
      由 vishnuvardhan 提交于 
      As per the SAMA5D3 device specification it supports Jumbo frames.
But the suggested flag and length of bytes it supports was not updated
in this driver config_structure.
The maximum jumbo frames the device supports :
10240 bytes as per the device spec.

While changing the MTU value greater than 1500, it threw error:
sudo ifconfig eth1 mtu 9000
SIOCSIFMTU: Invalid argument

Add this support to driver so that it works as expected and designed.
Signed-off-by: Nvishnuvardhan <vardhanraj4143@gmail.com>
[nicolas.ferre@microchip.com: modify slightly commit msg]
Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      233a1587
    • J
      virtio-net: fix leaking of ctx array · 55281621
      由 Jason Wang 提交于 
      Fixes: commit d45b897b ("virtio_net: allow specifying context for rx")
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55281621
  7. 07 7月, 2017 2 次提交
  9. 06 7月, 2017 9 次提交
    • N
      vrf: fix bug_on triggered by rx when destroying a vrf · f630c38e
      由 Nikolay Aleksandrov 提交于 
      When destroying a VRF device we cleanup the slaves in its ndo_uninit()
function, but that causes packets to be switched (skb->dev == vrf being
destroyed) even though we're pass the point where the VRF should be
receiving any packets while it is being dismantled. This causes a BUG_ON
to trigger if we have raw sockets (trace below).
The reason is that the inetdev of the VRF has been destroyed but we're
still sending packets up the stack with it, so let's free the slaves in
the dellink callback as David Ahern suggested.

Note that this fix doesn't prevent packets from going up when the VRF
device is admin down.

[   35.631371] ------------[ cut here ]------------
[   35.631603] kernel BUG at net/ipv4/fib_frontend.c:285!
[   35.631854] invalid opcode: 0000 [#1] SMP
[   35.631977] Modules linked in:
[   35.632081] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.12.0-rc7+ #45
[   35.632247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[   35.632477] task: ffff88005ad68000 task.stack: ffff88005ad64000
[   35.632632] RIP: 0010:fib_compute_spec_dst+0xfc/0x1ee
[   35.632769] RSP: 0018:ffff88005ad67978 EFLAGS: 00010202
[   35.632910] RAX: 0000000000000001 RBX: ffff880059a7f200 RCX: 0000000000000000
[   35.633084] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82274af0
[   35.633256] RBP: ffff88005ad679f8 R08: 000000000001ef70 R09: 0000000000000046
[   35.633430] R10: ffff88005ad679f8 R11: ffff880037731cb0 R12: 0000000000000001
[   35.633603] R13: ffff8800599e3000 R14: 0000000000000000 R15: ffff8800599cb852
[   35.634114] FS:  0000000000000000(0000) GS:ffff88005d900000(0000) knlGS:0000000000000000
[   35.634306] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.634456] CR2: 00007f3563227095 CR3: 000000000201d000 CR4: 00000000000406e0
[   35.634632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.634865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.635055] Call Trace:
[   35.635271]  ? __lock_acquire+0xf0d/0x1117
[   35.635522]  ipv4_pktinfo_prepare+0x82/0x151
[   35.635831]  raw_rcv_skb+0x17/0x3c
[   35.636062]  raw_rcv+0xe5/0xf7
[   35.636287]  raw_local_deliver+0x169/0x1d9
[   35.636534]  ip_local_deliver_finish+0x87/0x1c4
[   35.636820]  ip_local_deliver+0x63/0x7f
[   35.637058]  ip_rcv_finish+0x340/0x3a1
[   35.637295]  ip_rcv+0x314/0x34a
[   35.637525]  __netif_receive_skb_core+0x49f/0x7c5
[   35.637780]  ? lock_acquire+0x13f/0x1d7
[   35.638018]  ? lock_acquire+0x15e/0x1d7
[   35.638259]  __netif_receive_skb+0x1e/0x94
[   35.638502]  ? __netif_receive_skb+0x1e/0x94
[   35.638748]  netif_receive_skb_internal+0x74/0x300
[   35.639002]  ? dev_gro_receive+0x2ed/0x411
[   35.639246]  ? lock_is_held_type+0xc4/0xd2
[   35.639491]  napi_gro_receive+0x105/0x1a0
[   35.639736]  receive_buf+0xc32/0xc74
[   35.639965]  ? detach_buf+0x67/0x153
[   35.640201]  ? virtqueue_get_buf_ctx+0x120/0x176
[   35.640453]  virtnet_poll+0x128/0x1c5
[   35.640690]  net_rx_action+0x103/0x343
[   35.640932]  __do_softirq+0x1c7/0x4b7
[   35.641171]  run_ksoftirqd+0x23/0x5c
[   35.641403]  smpboot_thread_fn+0x24f/0x26d
[   35.641646]  ? sort_range+0x22/0x22
[   35.641878]  kthread+0x129/0x131
[   35.642104]  ? __list_add+0x31/0x31
[   35.642335]  ? __list_add+0x31/0x31
[   35.642568]  ret_from_fork+0x2a/0x40
[   35.642804] Code: 05 bd 87 a3 00 01 e8 1f ef 98 ff 4d 85 f6 48 c7 c7 f0 4a 27 82 41 0f 94 c4 31 c9 31 d2 41 0f b6 f4 e8 04 71 a1 ff 45 84 e4 74 02 <0f> 0b 0f b7 93 c4 00 00 00 4d 8b a5 80 05 00 00 48 03 93 d0 00
[   35.644342] RIP: fib_compute_spec_dst+0xfc/0x1ee RSP: ffff88005ad67978

Fixes: 193125db ("net: Introduce VRF device driver")
Reported-by: NChris Cormier <chriscormier@cumulusnetworks.com>
Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f630c38e
    • H
      net/mlx5e: Initialize CEE's getpermhwaddr address buffer to 0xff · d968f0f2
      由 Huy Nguyen 提交于 
      Latest change in open-lldp code uses bytes 6-11 of perm_addr buffer
as the Ethernet source address for the host TLV packet.
Since our driver does not fill these bytes, they stay at zero and
the open-lldp code ends up sending the TLV packet with zero source
address and the switch drops this packet.

The fix is to initialize these bytes to 0xff. The open-lldp code
considers 0xff:ff:ff:ff:ff:ff as the invalid address and falls back to
use the host's mac address as the Ethernet source address.

Fixes: 3a6a931d ("net/mlx5e: Support DCBX CEE API")
Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
Reviewed-by: NDaniel Jurgens <danielj@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      d968f0f2
    • I
      net/mlx5: Add Makefiles for subdirectories · fb000f78
      由 Ilan Tayari 提交于 
      Currently it is not possible to build just one .o file inside
a subdirectory, because the subdirectories lack a Makefile.

Add a Makefile to the mlx5 subdirectories.

Fixes: e29341fb ("net/mlx5: FPGA, Add basic support for Innova")
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Reported-by: NDavid Miller <davem@davemloft.net>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      fb000f78
    • I
      net/mlx5: Build wq.o even if MLX5_CORE_EN is not selected · 111a6763
      由 Ilan Tayari 提交于 
      Both the ethernet and FPGA portions of MLX5 now require the wq functions,
and we get a link error when CONFIG_MLX5_CORE_EN is disabled:

drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.o: In function `mlx5_fpga_conn_create_cq':
conn.c:(.text+0x10b3): undefined reference to `mlx5_cqwq_create'
conn.c:(.text+0x10c6): undefined reference to `mlx5_cqwq_get_size'
conn.c:(.text+0x12bc): undefined reference to `mlx5_cqwq_destroy'

Build wq.o even if MLX5_CORE_EN is not selected.

Fixes: 537a5057 ("net/mlx5: FPGA, Add high-speed connection routines")
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      111a6763
    • I
      net/mlx5: FPGA, Fix datatype mismatch · 2a41d15b
      由 Ilan Tayari 提交于 
      Fix warnings when building with -Wall:
drivers/net/ethernet/mellanox/mlx5/core/fpga/ipsec.c:313:36: warning: cast to restricted __be32
drivers/net/ethernet/mellanox/mlx5/core/fpga/ipsec.c:314:37: warning: cast to restricted __be32

Fixes: bebb23e6 ("net/mlx5: Accel, Add IPSec acceleration interface")
Reported-by: NOr Gerlitz <gerlitz.or@gmail.com>
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      2a41d15b
    • I
      net/mlx5: FPGA, make mlx5_fpga_device_brb static · c8af0169
      由 Ilan Tayari 提交于 
      Fix warning when building with -Wall:
drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c:105:5: warning: symbol 'mlx5_fpga_device_brb' was not declared. Should it be static?

Fixes: c43051d7 ("net/mlx5: FPGA, Add SBU bypass and reset flows")
Reported-by: NOr Gerlitz <gerlitz.or@gmail.com>
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      c8af0169
    • I
      net/mlx5: IPSec, Fix 64-bit division on 32-bit builds · 5dfd87b6
      由 Ilan Tayari 提交于 
      Fix warnings when building 386 kernel:
>> ERROR: "__udivdi3" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined!

Fixes: 2ac9cfe7 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data path")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      5dfd87b6
    • I
      net/mlx5: Add missing include in lib/gid.c · aa07b633
      由 Ilan Tayari 提交于 
      Fix warnings when building with -Wall:
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:38:6: warning: symbol 'mlx5_init_reserved_gids' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:47:6: warning: symbol 'mlx5_cleanup_reserved_gids' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:55:5: warning: symbol 'mlx5_core_reserve_gids' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:79:6: warning: symbol 'mlx5_core_unreserve_gids' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:92:5: warning: symbol 'mlx5_core_reserved_gid_alloc' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c:109:6: warning: symbol 'mlx5_core_reserved_gid_free' was not declared. Should it be static?

Fixes: 52ec462e ("net/mlx5: Add reserved-gids support")
Reported-by: NOr Gerlitz <gerlitz.or@gmail.com>
Signed-off-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      aa07b633
    • D
      liquidio: fix bug in soft reset failure detection · 05a6b4ca
      由 Derek Chickles 提交于 
      The code that detects a failed soft reset of Octeon is comparing the wrong
value against the reset value of the Octeon SLI_SCRATCH_1 register,
resulting in an inability to detect a soft reset failure.  Fix it by using
the correct value in the comparison, which is any non-zero value.

Fixes: f21fb3ed ("Add support of Cavium Liquidio ethernet adapters")
Fixes: c0eab5b3 ("liquidio: CN23XX firmware download")
Signed-off-by: NDerek Chickles <derek.chickles@cavium.com>
Signed-off-by: NSatanand Burla <satananda.burla@cavium.com>
Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: NFelix Manlunas <felix.manlunas@cavium.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05a6b4ca
  11. 05 7月, 2017 9 次提交
  13. 04 7月, 2017 2 次提交
    • S
      net: ethernet: mediatek: fixed deadlock captured by lockdep · 8d32e062
      由 Sean Wang 提交于 
      Lockdep found an inconsistent lock state when mtk_get_stats64 is called
in user context while NAPI updates MAC statistics in softirq.

Use spin_trylock_bh/spin_unlock_bh fix following lockdep warning.

[   81.321030] WARNING: inconsistent lock state
[   81.325266] 4.12.0-rc1-00035-gd9dda65 #32 Not tainted
[   81.330273] --------------------------------
[   81.334505] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   81.340464] ksoftirqd/0/7 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   81.345731]  (&syncp->seq#2){+.?...}, at: [<c054ba3c>] mtk_handle_status_irq.part.6+0x70/0x84
[   81.354219] {SOFTIRQ-ON-W} state was registered at:
[   81.359062]   lock_acquire+0xfc/0x2b0
[   81.362696]   mtk_stats_update_mac+0x60/0x2c0
[   81.367017]   mtk_get_stats64+0x17c/0x18c
[   81.370995]   dev_get_stats+0x48/0xbc
[   81.374628]   rtnl_fill_stats+0x48/0x128
[   81.378520]   rtnl_fill_ifinfo+0x4ac/0xd1c
[   81.382584]   rtmsg_ifinfo_build_skb+0x7c/0xe0
[   81.386991]   rtmsg_ifinfo.part.5+0x24/0x54
[   81.391139]   rtmsg_ifinfo+0x24/0x28
[   81.394685]   __dev_notify_flags+0xa4/0xac
[   81.398749]   dev_change_flags+0x50/0x58
[   81.402640]   devinet_ioctl+0x768/0x85c
[   81.406444]   inet_ioctl+0x1a4/0x1d0
[   81.409990]   sock_ioctl+0x16c/0x33c
[   81.413538]   do_vfs_ioctl+0xb4/0xa34
[   81.417169]   SyS_ioctl+0x44/0x6c
[   81.420458]   ret_fast_syscall+0x0/0x1c
[   81.424260] irq event stamp: 3354692
[   81.427806] hardirqs last  enabled at (3354692): [<c0678168>] net_rx_action+0xc0/0x504
[   81.435660] hardirqs last disabled at (3354691): [<c0678134>] net_rx_action+0x8c/0x504
[   81.443515] softirqs last  enabled at (3354106): [<c0101944>] __do_softirq+0x4b4/0x614
[   81.451370] softirqs last disabled at (3354109): [<c012f0c4>] run_ksoftirqd+0x44/0x80
[   81.459134]
[   81.459134] other info that might help us debug this:
[   81.465608]  Possible unsafe locking scenario:
[   81.465608]
[   81.471478]        CPU0
[   81.473900]        ----
[   81.476321]   lock(&syncp->seq#2);
[   81.479701]   <Interrupt>
[   81.482294]     lock(&syncp->seq#2);
[   81.485847]
[   81.485847]  *** DEADLOCK ***
[   81.485847]
[   81.491720] 1 lock held by ksoftirqd/0/7:
[   81.495693]  #0:  (&(&mac->hw_stats->stats_lock)->rlock){+.+...}, at: [<c054ba14>] mtk_handle_status_irq.part.6+0x48/0x84
[   81.506579]
[   81.506579] stack backtrace:
[   81.510904] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.12.0-rc1-00035-gd9dda65 #32
[   81.518668] Hardware name: Mediatek Cortex-A7 (Device Tree)
[   81.524208] [<c0113dc4>] (unwind_backtrace) from [<c010e3f0>] (show_stack+0x20/0x24)
[   81.531899] [<c010e3f0>] (show_stack) from [<c03f9c64>] (dump_stack+0xb4/0xe0)
[   81.539072] [<c03f9c64>] (dump_stack) from [<c017e970>] (print_usage_bug+0x234/0x2e0)
[   81.546846] [<c017e970>] (print_usage_bug) from [<c017f058>] (mark_lock+0x63c/0x7bc)
[   81.554532] [<c017f058>] (mark_lock) from [<c017fe90>] (__lock_acquire+0x654/0x1bfc)
[   81.562217] [<c017fe90>] (__lock_acquire) from [<c0181d04>] (lock_acquire+0xfc/0x2b0)
[   81.569990] [<c0181d04>] (lock_acquire) from [<c054b76c>] (mtk_stats_update_mac+0x60/0x2c0)
[   81.578283] [<c054b76c>] (mtk_stats_update_mac) from [<c054ba3c>] (mtk_handle_status_irq.part.6+0x70/0x84)
[   81.587865] [<c054ba3c>] (mtk_handle_status_irq.part.6) from [<c054c2b8>] (mtk_napi_tx+0x358/0x37c)
[   81.596845] [<c054c2b8>] (mtk_napi_tx) from [<c06782ec>] (net_rx_action+0x244/0x504)
[   81.604533] [<c06782ec>] (net_rx_action) from [<c01015c4>] (__do_softirq+0x134/0x614)
[   81.612306] [<c01015c4>] (__do_softirq) from [<c012f0c4>] (run_ksoftirqd+0x44/0x80)
[   81.619907] [<c012f0c4>] (run_ksoftirqd) from [<c0154680>] (smpboot_thread_fn+0x14c/0x25c)
[   81.628110] [<c0154680>] (smpboot_thread_fn) from [<c014f8cc>] (kthread+0x150/0x180)
[   81.635798] [<c014f8cc>] (kthread) from [<c0109290>] (ret_from_fork+0x14/0x24)
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d32e062
    • M
      qed: initialize ll2_syn_handle at start of function · 25f4535a
      由 Michal Kalderon 提交于 
      Fix compilation warning
qed_iwarp.c:1721:5: warning: ll2_syn_handle may be used
uninitialized in this function
Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: NAriel Elior <Ariel.Elior@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25f4535a
  15. 03 7月, 2017 10 次提交