1. 12 7月, 2017 1 次提交
  2. 11 7月, 2017 1 次提交
  3. 08 7月, 2017 7 次提交
    • 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
    • M
      PCI: tango: Add Sigma Designs Tango SMP8759 PCIe host bridge support · 5e14e9fa
      Marc Gonzalez 提交于
      This driver is required to work around several hardware bugs in the PCIe
      controller.
      
      The SMP8759 does not support legacy interrupts or IO space.
      Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
      [bhelgaas: add CONFIG_BROKEN dependency, various cleanups]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5e14e9fa
  4. 07 7月, 2017 25 次提交
  5. 06 7月, 2017 6 次提交
    • 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