1. 18 8月, 2016 19 次提交
  2. 17 8月, 2016 6 次提交
  3. 16 8月, 2016 14 次提交
    • D
      Merge branch 'mediatek-fixes' · a1560dd7
      David S. Miller 提交于
      Sean Wang says:
      
      ====================
      mediatek: Fix warning and issue
      
      This patch set fixes the following warning and issues
      
      v1 -> v2: Fix message typos and add coverletter
      
      v2 -> v3: Split from the previous series for submitting bug fixes
      as a series targeting 'net'
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1560dd7
    • S
      net: ethernet: mediatek: fix runtime warning raised by inconsistent struct... · 55a4e778
      sean.wang@mediatek.com 提交于
      net: ethernet: mediatek: fix runtime warning raised by inconsistent struct device pointers passed to DMA API
      
      Runtime warning occurs if DMA-API debug feature is enabled that would be
      raised by pointers passed to DMA API as arguments to inconsistent struct
      device objects, so that the patch makes them usage aligned between DMA
      operations such as dma_map_*() and dma_unmap_*() to eliminate the warning.
      Signed-off-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55a4e778
    • S
      net: ethernet: mediatek: fix flow control settings on GMAC0 is not being enabled properly · b2025c7c
      sean.wang@mediatek.com 提交于
      Commit 08ef55c6
      ("net-next: mediatek: fix gigabit and flow control advertisement")
      had supported proper flow control settings for GMAC1. But for GMAC0,
      
      1.GMAC0 shares the common logic with GMAC1 inside mtk_phy_link_adjust()
      to adapt various settings for the target phy.
      
      2.GMAC0 uses fixed-phy to connect to a builtin gigabit switch with
      fixed link speed as commit 0c72c50f
      ("net-next: mediatek: add fixed-phy support") describes.
      
      3.However, fixed-phy doesn't enable SUPPORTED_Pause & SUPPORTED_Asym_Pause
      supported flag on default that would cause mtk_phy_link_adjust() not to
      enable flow control setting on GMAC0 properly and cause packet dropped
      when high traffic.
      
      Due to these reasons, the patch adds SUPPORTED_Pause & SUPPORTED_Asym_Pause
      supported flags on fixed-phy used by the driver to have proper handling on
      the both GMAC with the shared common logic.
      Signed-off-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2025c7c
    • S
      net: ethernet: mediatek: fix RMII mode and add REVMII supported by GMAC · 8ca7f4fe
      sean.wang@mediatek.com 提交于
      The patch fixes up the incorrect setup of reduced MII (RMII) on GMAC
      and adds the supplement for the setup of reverse MII (REVMII) on GMAC
      , and rearranges the error handling for invalid PHY argument.
      Signed-off-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ca7f4fe
    • V
      tipc: fix NULL pointer dereference in shutdown() · d2fbdf76
      Vegard Nossum 提交于
      tipc_msg_create() can return a NULL skb and if so, we shouldn't try to
      call tipc_node_xmit_skb() on it.
      
          general protection fault: 0000 [#1] PREEMPT SMP KASAN
          CPU: 3 PID: 30298 Comm: trinity-c0 Not tainted 4.7.0-rc7+ #19
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
          task: ffff8800baf09980 ti: ffff8800595b8000 task.ti: ffff8800595b8000
          RIP: 0010:[<ffffffff830bb46b>]  [<ffffffff830bb46b>] tipc_node_xmit_skb+0x6b/0x140
          RSP: 0018:ffff8800595bfce8  EFLAGS: 00010246
          RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003023b0e0
          RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffffffff83d12580
          RBP: ffff8800595bfd78 R08: ffffed000b2b7f32 R09: 0000000000000000
          R10: fffffbfff0759725 R11: 0000000000000000 R12: 1ffff1000b2b7f9f
          R13: ffff8800595bfd58 R14: ffffffff83d12580 R15: dffffc0000000000
          FS:  00007fcdde242700(0000) GS:ffff88011af80000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 00007fcddde1db10 CR3: 000000006874b000 CR4: 00000000000006e0
          DR0: 00007fcdde248000 DR1: 00007fcddd73d000 DR2: 00007fcdde248000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000090602
          Stack:
           0000000000000018 0000000000000018 0000000041b58ab3 ffffffff83954208
           ffffffff830bb400 ffff8800595bfd30 ffffffff8309d767 0000000000000018
           0000000000000018 ffff8800595bfd78 ffffffff8309da1a 00000000810ee611
          Call Trace:
           [<ffffffff830c84a3>] tipc_shutdown+0x553/0x880
           [<ffffffff825b4a3b>] SyS_shutdown+0x14b/0x170
           [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
           [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: 90 00 b4 0b 83 c7 00 f1 f1 f1 f1 4c 8d 6d e0 c7 40 04 00 00 00 f4 c7 40 08 f3 f3 f3 f3 48 89 d8 48 c1 e8 03 c7 45 b4 00 00 00 00 <80> 3c 30 00 75 78 48 8d 7b 08 49 8d 75 c0 48 b8 00 00 00 00 00
          RIP  [<ffffffff830bb46b>] tipc_node_xmit_skb+0x6b/0x140
           RSP <ffff8800595bfce8>
          ---[ end trace 57b0484e351e71f1 ]---
      
      I feel like we should maybe return -ENOMEM or -ENOBUFS, but I'm not sure
      userspace is equipped to handle that. Anyway, this is better than a GPF
      and looks somewhat consistent with other tipc_msg_create() callers.
      Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2fbdf76
    • D
      Merge branch 'hv_netvsc-VF-removal-fixes' · a8545b60
      David S. Miller 提交于
      Vitaly Kuznetsov says:
      
      ====================
      hv_netvsc: fixes for VF removal path
      
      Kernel crash is reported after VF is removed and detached from netvsc
      device. Turns out we have multiple different (but related) issues on the
      VF removal path which I'm trying to address with PATCHes 2-5 of this
      series. PATCH1 is required to support the change.
      
      Changes since v1:
      - Re-arrange patches in the series to not introduce new issues [David Miller]
      - Add PATCH5 which fixes a new issue I discovered while testing.
      - Add Haiyang' A-b tags to PATCH1-4
      
      With regards to Stephen's suggestion: I believe that switching to using RCU
      and eliminating vf_use_cnt/vf_inject is the right thing to do long-term, we
      can either put this on top of this series or do it later in net-next.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8545b60
    • V
      hv_netvsc: fix bonding devices check in netvsc_netdev_event() · 0dbff144
      Vitaly Kuznetsov 提交于
      Bonding driver sets IFF_BONDING on both master (the bonding device) and
      slave (the real NIC) devices and in netvsc_netdev_event() we want to skip
      master devices only. Currently, there is an uncertainty when a slave
      interface is removed: if bonding module comes first in netdev_chain it
      clears IFF_BONDING flag on the netdev and netvsc_netdev_event() correctly
      handles NETDEV_UNREGISTER event, but in case netvsc comes first on the
      chain it sees the device with IFF_BONDING still attached and skips it. As
      we still hold vf_netdev pointer to the device we crash on the next inject.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dbff144
    • V
      hv_netvsc: protect module refcount by checking net_device_ctx->vf_netdev · 0f20d795
      Vitaly Kuznetsov 提交于
      We're not guaranteed to see NETDEV_REGISTER/NETDEV_UNREGISTER notifications
      only once per VF but we increase/decrease module refcount unconditionally.
      Check vf_netdev to make sure we don't take/release it twice. We presume
      that only one VF per netvsc device may exist.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f20d795
    • V
      hv_netvsc: reset vf_inject on VF removal · 57c1826b
      Vitaly Kuznetsov 提交于
      We reset vf_inject on VF going down (netvsc_vf_down()) but we don't on
      VF removal (netvsc_unregister_vf()) so vf_inject stays 'true' while
      vf_netdev is already NULL and we're trying to inject packets into NULL
      net device in netvsc_recv_callback() causing kernel to crash.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57c1826b
    • V
      hv_netvsc: avoid deadlocks between rtnl lock and vf_use_cnt wait · d072218f
      Vitaly Kuznetsov 提交于
      Here is a deadlock scenario:
      - netvsc_vf_up() schedules netvsc_notify_peers() work and quits.
      - netvsc_vf_down() runs before netvsc_notify_peers() gets executed. As it
        is being executed from netdev notifier chain we hold rtnl lock when we
        get here.
      - we enter while (atomic_read(&net_device_ctx->vf_use_cnt) != 0) loop and
        wait till netvsc_notify_peers() drops vf_use_cnt.
      - netvsc_notify_peers() starts on some other CPU but netdev_notify_peers()
        will hang on rtnl_lock().
      - deadlock!
      
      Instead of introducing additional synchronization I suggest we drop
      gwrk.dwrk completely and call NETDEV_NOTIFY_PEERS directly. As we're
      acting under rtnl lock this is legitimate.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d072218f
    • V
      hv_netvsc: don't lose VF information · f9a7da91
      Vitaly Kuznetsov 提交于
      struct netvsc_device is not suitable for storing VF information as this
      structure is being destroyed on MTU change / set channel operation (see
      rndis_filter_device_remove()). Move all VF related stuff to struct
      net_device_context which is persistent.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9a7da91
    • S
      gre: set inner_protocol on xmit · 3d7b3320
      Simon Horman 提交于
      Ensure that the inner_protocol is set on transmit so that GSO segmentation,
      which relies on that field, works correctly.
      
      This is achieved by setting the inner_protocol in gre_build_header rather
      than each caller of that function. It ensures that the inner_protocol is
      set when gre_fb_xmit() is used to transmit GRE which was not previously the
      case.
      
      I have observed this is not the case when OvS transmits GRE using
      lwtunnel metadata (which it always does).
      
      Fixes: 38720352 ("gre: Use inner_proto to obtain inner header protocol")
      Cc: Pravin Shelar <pshelar@ovn.org>
      Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d7b3320
    • L
      net: ipv6: Fix ping to link-local addresses. · 5e457896
      Lorenzo Colitti 提交于
      ping_v6_sendmsg does not set flowi6_oif in response to
      sin6_scope_id or sk_bound_dev_if, so it is not possible to use
      these APIs to ping an IPv6 address on a different interface.
      Instead, it sets flowi6_iif, which is incorrect but harmless.
      
      Stop setting flowi6_iif, and support various ways of setting oif
      in the same priority order used by udpv6_sendmsg.
      
      Tested: https://android-review.googlesource.com/#/c/254470/Signed-off-by: NLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e457896
    • V
      rhashtable: fix shift by 64 when shrinking · 12311959
      Vegard Nossum 提交于
      I got this:
      
          ================================================================================
          UBSAN: Undefined behaviour in ./include/linux/log2.h:63:13
          shift exponent 64 is too large for 64-bit type 'long unsigned int'
          CPU: 1 PID: 721 Comm: kworker/1:1 Not tainted 4.8.0-rc1+ #87
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          Workqueue: events rht_deferred_worker
           0000000000000000 ffff88011661f8d8 ffffffff82344f50 0000000041b58ab3
           ffffffff84f98000 ffffffff82344ea4 ffff88011661f900 ffff88011661f8b0
           0000000000000001 ffff88011661f6b8 dffffc0000000000 ffffffff867f7640
          Call Trace:
           [<ffffffff82344f50>] dump_stack+0xac/0xfc
           [<ffffffff82344ea4>] ? _atomic_dec_and_lock+0xc4/0xc4
           [<ffffffff8242f5b8>] ubsan_epilogue+0xd/0x8a
           [<ffffffff82430c41>] __ubsan_handle_shift_out_of_bounds+0x255/0x29a
           [<ffffffff824309ec>] ? __ubsan_handle_out_of_bounds+0x180/0x180
           [<ffffffff84003436>] ? nl80211_req_set_reg+0x256/0x2f0
           [<ffffffff812112ba>] ? print_context_stack+0x8a/0x160
           [<ffffffff81200031>] ? amd_pmu_reset+0x341/0x380
           [<ffffffff823af808>] rht_deferred_worker+0x1618/0x1790
           [<ffffffff823af808>] ? rht_deferred_worker+0x1618/0x1790
           [<ffffffff823ae1f0>] ? rhashtable_jhash2+0x370/0x370
           [<ffffffff8134c12d>] ? process_one_work+0x6fd/0x1970
           [<ffffffff8134c1cf>] process_one_work+0x79f/0x1970
           [<ffffffff8134c12d>] ? process_one_work+0x6fd/0x1970
           [<ffffffff8134ba30>] ? try_to_grab_pending+0x4c0/0x4c0
           [<ffffffff8134d564>] ? worker_thread+0x1c4/0x1340
           [<ffffffff8134d8ff>] worker_thread+0x55f/0x1340
           [<ffffffff845e904f>] ? __schedule+0x4df/0x1d40
           [<ffffffff8134d3a0>] ? process_one_work+0x1970/0x1970
           [<ffffffff8134d3a0>] ? process_one_work+0x1970/0x1970
           [<ffffffff813642f7>] kthread+0x237/0x390
           [<ffffffff813640c0>] ? __kthread_parkme+0x280/0x280
           [<ffffffff845f8c93>] ? _raw_spin_unlock_irq+0x33/0x50
           [<ffffffff845f95df>] ret_from_fork+0x1f/0x40
           [<ffffffff813640c0>] ? __kthread_parkme+0x280/0x280
          ================================================================================
      
      roundup_pow_of_two() is undefined when called with an argument of 0, so
      let's avoid the call and just fall back to ht->p.min_size (which should
      never be smaller than HASH_MIN_SIZE).
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12311959
  4. 15 8月, 2016 1 次提交