1. 09 8月, 2019 12 次提交
    • H
      r8169: don't use MSI before RTL8168d · 473430ed
      Heiner Kallweit 提交于
      [ Upstream commit 003bd5b4a7b4a94b501e3a1e2e7c9df6b2a94ed4 ]
      
      It was reported that after resuming from suspend network fails with
      error "do_IRQ: 3.38 No irq handler for vector", see [0]. Enabling WoL
      can work around the issue, but the only actual fix is to disable MSI.
      So let's mimic the behavior of the vendor driver and disable MSI on
      all chip versions before RTL8168d.
      
      [0] https://bugzilla.kernel.org/show_bug.cgi?id=204079
      
      Fixes: 6c6aa15f ("r8169: improve interrupt handling")
      Reported-by: NDušan Dragić <dragic.dusan@gmail.com>
      Tested-by: NDušan Dragić <dragic.dusan@gmail.com>
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      473430ed
    • A
      net/mlx5e: Prevent encap flow counter update async to user query · 0ccf4726
      Ariel Levkovich 提交于
      [ Upstream commit 90bb769291161cf25a818d69cf608c181654473e ]
      
      This patch prevents a race between user invoked cached counters
      query and a neighbor last usage updater.
      
      The cached flow counter stats can be queried by calling
      "mlx5_fc_query_cached" which provides the number of bytes and
      packets that passed via this flow since the last time this counter
      was queried.
      It does so by reducting the last saved stats from the current, cached
      stats and then updating the last saved stats with the cached stats.
      It also provide the lastuse value for that flow.
      
      Since "mlx5e_tc_update_neigh_used_value" needs to retrieve the
      last usage time of encapsulation flows, it calls the flow counter
      query method periodically and async to user queries of the flow counter
      using cls_flower.
      This call is causing the driver to update the last reported bytes and
      packets from the cache and therefore, future user queries of the flow
      stats will return lower than expected number for bytes and packets
      since the last saved stats in the driver was updated async to the last
      saved stats in cls_flower.
      
      This causes wrong stats presentation of encapsulation flows to user.
      
      Since the neighbor usage updater only needs the lastuse stats from the
      cached counter, the fix is to use a dedicated lastuse query call that
      returns the lastuse value without synching between the cached stats and
      the last saved stats.
      
      Fixes: f6dfb4c3 ("net/mlx5e: Update neighbour 'used' state using HW flow rules counters")
      Signed-off-by: NAriel Levkovich <lariel@mellanox.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ccf4726
    • A
      tun: mark small packets as owned by the tap sock · f378724e
      Alexis Bauvin 提交于
      [ Upstream commit 4b663366246be1d1d4b1b8b01245b2e88ad9e706 ]
      
      - v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size
      
      Small packets going out of a tap device go through an optimized code
      path that uses build_skb() rather than sock_alloc_send_pskb(). The
      latter calls skb_set_owner_w(), but the small packet code path does not.
      
      The net effect is that small packets are not owned by the userland
      application's socket (e.g. QEMU), while large packets are.
      This can be seen with a TCP session, where packets are not owned when
      the window size is small enough (around PAGE_SIZE), while they are once
      the window grows (note that this requires the host to support virtio
      tso for the guest to offload segmentation).
      All this leads to inconsistent behaviour in the kernel, especially on
      netfilter modules that uses sk->socket (e.g. xt_owner).
      
      Fixes: 66ccbc9c ("tap: use build_skb() for small packet")
      Signed-off-by: NAlexis Bauvin <abauvin@scaleway.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f378724e
    • C
      ocelot: Cancel delayed work before wq destruction · eaa34bd4
      Claudiu Manoil 提交于
      [ Upstream commit c5d139697d5d9ecf9c7cd92d7d7838a173508900 ]
      
      Make sure the delayed work for stats update is not pending before
      wq destruction.
      This fixes the module unload path.
      The issue is there since day 1.
      
      Fixes: a556c76a ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Reviewed-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eaa34bd4
    • S
      net: qualcomm: rmnet: Fix incorrect UL checksum offload logic · 44b96a38
      Subash Abhinov Kasiviswanathan 提交于
      [ Upstream commit a7cf3d24ee6081930feb4c830a7f6f16ebe31c49 ]
      
      The udp_ip4_ind bit is set only for IPv4 UDP non-fragmented packets
      so that the hardware can flip the checksum to 0xFFFF if the computed
      checksum is 0 per RFC768.
      
      However, this bit had to be set for IPv6 UDP non fragmented packets
      as well per hardware requirements. Otherwise, IPv6 UDP packets
      with computed checksum as 0 were transmitted by hardware and were
      dropped in the network.
      
      In addition to setting this bit for IPv6 UDP, the field is also
      appropriately renamed to udp_ind as part of this change.
      
      Fixes: 5eb5f860 ("net: qualcomm: rmnet: Add support for TX checksum offload")
      Cc: Sean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44b96a38
    • R
      net: phylink: Fix flow control for fixed-link · c8b05980
      René van Dorst 提交于
      [ Upstream commit 8aace4f3eba2a3ceb431e18683ea0e1ecbade5cd ]
      
      In phylink_parse_fixedlink() the pl->link_config.advertising bits are AND
      with pl->supported, pl->supported is zeroed and only the speed/duplex
      modes and MII bits are set.
      So pl->link_config.advertising always loses the flow control/pause bits.
      
      By setting Pause and Asym_Pause bits in pl->supported, the flow control
      work again when devicetree "pause" is set in fixes-link node and the MAC
      advertise that is supports pause.
      
      Results with this patch.
      
      Legend:
      - DT = 'Pause' is set in the fixed-link in devicetree.
      - validate() = ‘Yes’ means phylink_set(mask, Pause) is set in the
        validate().
      - flow = results reported my link is Up line.
      
      +-----+------------+-------+
      | DT  | validate() | flow  |
      +-----+------------+-------+
      | Yes | Yes        | rx/tx |
      | No  | Yes        | off   |
      | Yes | No         | off   |
      +-----+------------+-------+
      
      Fixes: 9525ae83 ("phylink: add phylink infrastructure")
      Signed-off-by: NRené van Dorst <opensource@vdorst.com>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8b05980
    • M
      net/mlx5: Use reversed order when unregister devices · 4dddd08b
      Mark Zhang 提交于
      [ Upstream commit 08aa5e7da6bce1a1963f63cf32c2e7ad434ad578 ]
      
      When lag is active, which is controlled by the bonded mlx5e netdev, mlx5
      interface unregestering must happen in the reverse order where rdma is
      unregistered (unloaded) first, to guarantee all references to the lag
      context in hardware is removed, then remove mlx5e netdev interface which
      will cleanup the lag context from hardware.
      
      Without this fix during destroy of LAG interface, we observed following
      errors:
       * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
         status bad parameter(0x3), syndrome (0xe4ac33)
       * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
         status bad parameter(0x3), syndrome (0xa5aee8).
      
      Fixes: a31208b1 ("net/mlx5_core: New init and exit flow for mlx5_core")
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NMark Zhang <markz@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dddd08b
    • Q
      net/mlx5e: always initialize frag->last_in_page · 858f82c6
      Qian Cai 提交于
      [ Upstream commit 60d60c8fbd8d1acf25b041ecd72ae4fa16e9405b ]
      
      The commit 069d1146 ("net/mlx5e: RX, Enhance legacy Receive Queue
      memory scheme") introduced an undefined behaviour below due to
      "frag->last_in_page" is only initialized in mlx5e_init_frags_partition()
      when,
      
      if (next_frag.offset + frag_info[f].frag_stride > PAGE_SIZE)
      
      or after bailed out the loop,
      
      for (i = 0; i < mlx5_wq_cyc_get_size(&rq->wqe.wq); i++)
      
      As the result, there could be some "frag" have uninitialized
      value of "last_in_page".
      
      Later, get_frag() obtains those "frag" and check "frag->last_in_page" in
      mlx5e_put_rx_frag() and triggers the error during boot. Fix it by always
      initializing "frag->last_in_page" to "false" in
      mlx5e_init_frags_partition().
      
      UBSAN: Undefined behaviour in
      drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:325:12
      load of value 170 is not a valid value for type 'bool' (aka '_Bool')
      Call trace:
       dump_backtrace+0x0/0x264
       show_stack+0x20/0x2c
       dump_stack+0xb0/0x104
       __ubsan_handle_load_invalid_value+0x104/0x128
       mlx5e_handle_rx_cqe+0x8e8/0x12cc [mlx5_core]
       mlx5e_poll_rx_cq+0xca8/0x1a94 [mlx5_core]
       mlx5e_napi_poll+0x17c/0xa30 [mlx5_core]
       net_rx_action+0x248/0x940
       __do_softirq+0x350/0x7b8
       irq_exit+0x200/0x26c
       __handle_domain_irq+0xc8/0x128
       gic_handle_irq+0x138/0x228
       el1_irq+0xb8/0x140
       arch_cpu_idle+0x1a4/0x348
       do_idle+0x114/0x1b0
       cpu_startup_entry+0x24/0x28
       rest_init+0x1ac/0x1dc
       arch_call_rest_init+0x10/0x18
       start_kernel+0x4d4/0x57c
      
      Fixes: 069d1146 ("net/mlx5e: RX, Enhance legacy Receive Queue memory scheme")
      Signed-off-by: NQian Cai <cai@lca.pw>
      Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      858f82c6
    • M
      mvpp2: refactor MTU change code · b3645a48
      Matteo Croce 提交于
      [ Upstream commit 230bd958c2c846ee292aa38bc6b006296c24ca01 ]
      
      The MTU change code can call napi_disable() with the device already down,
      leading to a deadlock. Also, lot of code is duplicated unnecessarily.
      
      Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
      
      Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: NMatteo Croce <mcroce@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3645a48
    • M
      mvpp2: fix panic on module removal · ffab47bf
      Matteo Croce 提交于
      [ Upstream commit 944a83a2669ae8aa2c7664e79376ca7468eb0a2b ]
      
      mvpp2 uses a delayed workqueue to gather traffic statistics.
      On module removal the workqueue can be destroyed before calling
      cancel_delayed_work_sync() on its works.
      Fix it by moving the destroy_workqueue() call after mvpp2_port_remove().
      Also remove an unneeded call to flush_workqueue()
      
          # rmmod mvpp2
          [ 2743.311722] mvpp2 f4000000.ethernet eth1: phy link down 10gbase-kr/10Gbps/Full
          [ 2743.320063] mvpp2 f4000000.ethernet eth1: Link is Down
          [ 2743.572263] mvpp2 f4000000.ethernet eth2: phy link down sgmii/1Gbps/Full
          [ 2743.580076] mvpp2 f4000000.ethernet eth2: Link is Down
          [ 2744.102169] mvpp2 f2000000.ethernet eth0: phy link down 10gbase-kr/10Gbps/Full
          [ 2744.110441] mvpp2 f2000000.ethernet eth0: Link is Down
          [ 2744.115614] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
          [ 2744.115615] Mem abort info:
          [ 2744.115616]   ESR = 0x96000005
          [ 2744.115617]   Exception class = DABT (current EL), IL = 32 bits
          [ 2744.115618]   SET = 0, FnV = 0
          [ 2744.115619]   EA = 0, S1PTW = 0
          [ 2744.115620] Data abort info:
          [ 2744.115621]   ISV = 0, ISS = 0x00000005
          [ 2744.115622]   CM = 0, WnR = 0
          [ 2744.115624] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000422681000
          [ 2744.115626] [0000000000000000] pgd=0000000000000000, pud=0000000000000000
          [ 2744.115630] Internal error: Oops: 96000005 [#1] SMP
          [ 2744.115632] Modules linked in: mvpp2(-) algif_hash af_alg nls_iso8859_1 nls_cp437 vfat fat xhci_plat_hcd m25p80 spi_nor xhci_hcd mtd usbcore i2c_mv64xxx sfp usb_common marvell10g phy_generic spi_orion mdio_i2c i2c_core mvmdio phylink sbsa_gwdt ip_tables x_tables autofs4 [last unloaded: mvpp2]
          [ 2744.115654] CPU: 3 PID: 8357 Comm: kworker/3:2 Not tainted 5.3.0-rc2 #1
          [ 2744.115655] Hardware name: Marvell 8040 MACCHIATOBin Double-shot (DT)
          [ 2744.115665] Workqueue: events_power_efficient phylink_resolve [phylink]
          [ 2744.115669] pstate: a0000085 (NzCv daIf -PAN -UAO)
          [ 2744.115675] pc : __queue_work+0x9c/0x4d8
          [ 2744.115677] lr : __queue_work+0x170/0x4d8
          [ 2744.115678] sp : ffffff801001bd50
          [ 2744.115680] x29: ffffff801001bd50 x28: ffffffc422597600
          [ 2744.115684] x27: ffffff80109ae6f0 x26: ffffff80108e4018
          [ 2744.115688] x25: 0000000000000003 x24: 0000000000000004
          [ 2744.115691] x23: ffffff80109ae6e0 x22: 0000000000000017
          [ 2744.115694] x21: ffffffc42c030000 x20: ffffffc42209e8f8
          [ 2744.115697] x19: 0000000000000000 x18: 0000000000000000
          [ 2744.115699] x17: 0000000000000000 x16: 0000000000000000
          [ 2744.115701] x15: 0000000000000010 x14: ffffffffffffffff
          [ 2744.115702] x13: ffffff8090e2b95f x12: ffffff8010e2b967
          [ 2744.115704] x11: ffffff8010906000 x10: 0000000000000040
          [ 2744.115706] x9 : ffffff80109223b8 x8 : ffffff80109223b0
          [ 2744.115707] x7 : ffffffc42bc00068 x6 : 0000000000000000
          [ 2744.115709] x5 : ffffffc42bc00000 x4 : 0000000000000000
          [ 2744.115710] x3 : 0000000000000000 x2 : 0000000000000000
          [ 2744.115712] x1 : 0000000000000008 x0 : ffffffc42c030000
          [ 2744.115714] Call trace:
          [ 2744.115716]  __queue_work+0x9c/0x4d8
          [ 2744.115718]  delayed_work_timer_fn+0x28/0x38
          [ 2744.115722]  call_timer_fn+0x3c/0x180
          [ 2744.115723]  expire_timers+0x60/0x168
          [ 2744.115724]  run_timer_softirq+0xbc/0x1e8
          [ 2744.115727]  __do_softirq+0x128/0x320
          [ 2744.115731]  irq_exit+0xa4/0xc0
          [ 2744.115734]  __handle_domain_irq+0x70/0xc0
          [ 2744.115735]  gic_handle_irq+0x58/0xa8
          [ 2744.115737]  el1_irq+0xb8/0x140
          [ 2744.115738]  console_unlock+0x3a0/0x568
          [ 2744.115740]  vprintk_emit+0x200/0x2a0
          [ 2744.115744]  dev_vprintk_emit+0x1c8/0x1e4
          [ 2744.115747]  dev_printk_emit+0x6c/0x7c
          [ 2744.115751]  __netdev_printk+0x104/0x1d8
          [ 2744.115752]  netdev_printk+0x60/0x70
          [ 2744.115756]  phylink_resolve+0x38c/0x3c8 [phylink]
          [ 2744.115758]  process_one_work+0x1f8/0x448
          [ 2744.115760]  worker_thread+0x54/0x500
          [ 2744.115762]  kthread+0x12c/0x130
          [ 2744.115764]  ret_from_fork+0x10/0x1c
          [ 2744.115768] Code: aa1403e0 97fffbbe aa0003f5 b4000700 (f9400261)
      
      Fixes: 118d6298 ("net: mvpp2: add ethtool GOP statistics")
      Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: NMatteo Croce <mcroce@redhat.com>
      Acked-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffab47bf
    • J
      mlxsw: spectrum: Fix error path in mlxsw_sp_module_init() · 3c46905f
      Jiri Pirko 提交于
      [ Upstream commit 28fe79000e9b0a6f99959869947f1ca305f14599 ]
      
      In case of sp2 pci driver registration fail, fix the error path to
      start with sp1 pci driver unregister.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c46905f
    • S
      bnx2x: Disable multi-cos feature. · 774358df
      Sudarsana Reddy Kalluru 提交于
      [ Upstream commit d1f0b5dce8fda09a7f5f04c1878f181d548e42f5 ]
      
      Commit 3968d389 ("bnx2x: Fix Multi-Cos.") which enabled multi-cos
      feature after prolonged time in driver added some regression causing
      numerous issues (sudden reboots, tx timeout etc.) reported by customers.
      We plan to backout this commit and submit proper fix once we have root
      cause of issues reported with this feature enabled.
      
      Fixes: 3968d389 ("bnx2x: Fix Multi-Cos.")
      Signed-off-by: NSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      774358df
  2. 07 8月, 2019 2 次提交
    • P
      mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed · d3e36788
      Petr Machata 提交于
      [ Upstream commit dedfde2fe1c4ccf27179fcb234e2112d065c39bb ]
      
      Spectrum systems use DSCP rewrite map to update DSCP field in egressing
      packets to correspond to priority that the packet has. Whether rewriting
      will take place is determined at the point when the packet ingresses the
      switch: if the port is in Trust L3 mode, packet priority is determined from
      the DSCP map at the port, and DSCP rewrite will happen. If the port is in
      Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
      rewrite will happen.
      
      The driver determines the port trust mode based on whether any DSCP
      prioritization rules are in effect at given port. If there are any, trust
      level is L3, otherwise it's L2. When the last DSCP rule is removed, the
      port is switched to trust L2. Under that scenario, if DSCP of a packet
      should be rewritten, it should be rewritten to 0.
      
      However, when switching to Trust L2, the driver neglects to also update the
      DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
      egressing through this port, if they have the right priority, will have
      their DSCP set according to this rule.
      
      Fix by first configuring the rewrite map, and only then switching to trust
      L2 and bailing out.
      
      Fixes: b2b1dab6 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d3e36788
    • B
      be2net: Signal that the device cannot transmit during reconfiguration · ade866ad
      Benjamin Poirier 提交于
      [ Upstream commit 7429c6c0d9cb086d8e79f0d2a48ae14851d2115e ]
      
      While changing the number of interrupt channels, be2net stops adapter
      operation (including netif_tx_disable()) but it doesn't signal that it
      cannot transmit. This may lead dev_watchdog() to falsely trigger during
      that time.
      
      Add the missing call to netif_carrier_off(), following the pattern used in
      many other drivers. netif_carrier_on() is already taken care of in
      be_open().
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ade866ad
  3. 04 8月, 2019 1 次提交
  4. 31 7月, 2019 1 次提交
    • A
      cxgb4: reduce kernel stack usage in cudbg_collect_mem_region() · 0d72bb85
      Arnd Bergmann 提交于
      [ Upstream commit 752c2ea2d8e7c23b0f64e2e7d4337f3604d44c9f ]
      
      The cudbg_collect_mem_region() and cudbg_read_fw_mem() both use several
      hundred kilobytes of kernel stack space. One gets inlined into the other,
      which causes the stack usage to be combined beyond the warning limit
      when building with clang:
      
      drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:1057:12: error: stack frame size of 1244 bytes in function 'cudbg_collect_mem_region' [-Werror,-Wframe-larger-than=]
      
      Restructuring cudbg_collect_mem_region() lets clang do the same
      optimization that gcc does and reuse the stack slots as it can
      see that the large variables are never used together.
      
      A better fix might be to avoid using cudbg_meminfo on the stack
      altogether, but that requires a larger rewrite.
      
      Fixes: a1c69520 ("cxgb4: collect MC memory dump")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0d72bb85
  5. 28 7月, 2019 13 次提交
  6. 26 7月, 2019 11 次提交
    • J
      net: mvmdio: allow up to four clocks to be specified for orion-mdio · 03e6a668
      Josua Mayer 提交于
      commit 4aabed699c400810981d3dda170f05fa4d782905 upstream.
      
      Allow up to four clocks to be specified and enabled for the orion-mdio
      interface, which are required by the Armada 8k and defined in
      armada-cp110.dtsi.
      
      Fixes a hang in probing the mvmdio driver that was encountered on the
      Clearfog GT 8K with all drivers built as modules, but also affects other
      boards such as the MacchiatoBIN.
      
      Cc: stable@vger.kernel.org
      Fixes: 96cb4342 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NJosua Mayer <josua@solid-run.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03e6a668
    • E
      iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices · 6825ff01
      Emmanuel Grumbach 提交于
      commit ed3e4c6d3cd8f093a3636cb05492429fe2af228d upstream.
      
      Newest devices have a new firmware load mechanism. This
      mechanism is called the context info. It means that the
      driver doesn't need to load the sections of the firmware.
      The driver rather prepares a place in DRAM, with pointers
      to the relevant sections of the firmware, and the firmware
      loads itself.
      At the end of the process, the firmware sends the ALIVE
      interrupt. This is different from the previous scheme in
      which the driver expected the FH_TX interrupt after each
      section being transferred over the DMA.
      
      In order to support this new flow, we enabled all the
      interrupts. This broke the assumption that we have in the
      code that the RF-Kill interrupt can't interrupt the firmware
      load flow.
      
      Change the context info flow to enable only the ALIVE
      interrupt, and re-enable all the other interrupts only
      after the firmware is alive. Then, we won't see the RF-Kill
      interrupt until then. Getting the RF-Kill interrupt while
      loading the firmware made us kill the firmware while it is
      loading and we ended up dumping garbage instead of the firmware
      state.
      
      Re-enable the ALIVE | RX interrupts from the ISR when we
      get the ALIVE interrupt to be able to get the RX interrupt
      that comes immediately afterwards for the ALIVE
      notification. This is needed for non MSI-X only.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6825ff01
    • E
      iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill · a32e2cec
      Emmanuel Grumbach 提交于
      commit 0d53cfd0cca3c729a089c39eef0e7d8ae7662974 upstream.
      
      iwl_mvm_send_cmd returns 0 when the command won't be sent
      because RF-Kill is asserted. Do the same when we call
      iwl_get_shared_mem_conf since it is not sent through
      iwl_mvm_send_cmd but directly calls the transport layer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a32e2cec
    • E
      iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X · d9ce0788
      Emmanuel Grumbach 提交于
      commit ec46ae30245ecb41d73f8254613db07c653fb498 upstream.
      
      We added code to restock the buffer upon ALIVE interrupt
      when MSI-X is disabled. This was added as part of the context
      info code. This code was added only if the ISR debug level
      is set which is very unlikely to be related.
      Move this code to run even when the ISR debug level is not
      set.
      
      Note that gen2 devices work with MSI-X in most cases so that
      this path is seldom used.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9ce0788
    • E
      iwlwifi: pcie: don't service an interrupt that was masked · 04c52c10
      Emmanuel Grumbach 提交于
      commit 3b57a10ca14c619707398dc58fe5ece18c95b20b upstream.
      
      Sometimes the register status can include interrupts that
      were masked. We can, for example, get the RF-Kill bit set
      in the interrupt status register although this interrupt
      was masked. Then if we get the ALIVE interrupt (for example)
      that was not masked, we need to *not* service the RF-Kill
      interrupt.
      Fix this in the MSI-X interrupt handler.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04c52c10
    • C
      iavf: fix dereference of null rx_buffer pointer · 7c16c5ea
      Colin Ian King 提交于
      [ Upstream commit 9fe06a51287b2d41baef7ece94df34b5abf19b90 ]
      
      A recent commit efa14c3985828d ("iavf: allow null RX descriptors") added
      a null pointer sanity check on rx_buffer, however, rx_buffer is being
      dereferenced before that check, which implies a null pointer dereference
      bug can potentially occur.  Fix this by only dereferencing rx_buffer
      until after the null pointer check.
      
      Addresses-Coverity: ("Dereference before null check")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c16c5ea
    • J
      net: mvmdio: defer probe of orion-mdio if a clock is not ready · e9896b29
      Josua Mayer 提交于
      [ Upstream commit 433a06d7d74e677c40b1148c70c48677ff62fb6b ]
      
      Defer probing of the orion-mdio interface when getting a clock returns
      EPROBE_DEFER. This avoids locking up the Armada 8k SoC when mdio is used
      before all clocks have been enabled.
      Signed-off-by: NJosua Mayer <josua@solid-run.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9896b29
    • T
      gtp: fix use-after-free in gtp_newlink() · 5f6c5f5a
      Taehee Yoo 提交于
      [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ]
      
      Current gtp_newlink() could be called after unregister_pernet_subsys().
      gtp_newlink() uses gtp_net but it can be destroyed by
      unregister_pernet_subsys().
      So unregister_pernet_subsys() should be called after
      rtnl_link_unregister().
      
      Test commands:
         #SHELL 1
         while :
         do
      	   for i in {1..5}
      	   do
      		./gtp-link add gtp$i &
      	   done
      	   killall gtp-link
         done
      
         #SHELL 2
         while :
         do
      	modprobe -rv gtp
         done
      
      Splat looks like:
      [  753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126
      [  753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G        W         5.2.0-rc6+ #50
      [  753.185801] Call Trace:
      [  753.186264]  dump_stack+0x7c/0xbb
      [  753.186863]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.187583]  print_address_description+0xc7/0x240
      [  753.188382]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.189097]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.189846]  __kasan_report+0x12a/0x16f
      [  753.190542]  ? gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.191298]  kasan_report+0xe/0x20
      [  753.191893]  gtp_newlink+0x9b4/0xa5c [gtp]
      [  753.192580]  ? __netlink_ns_capable+0xc3/0xf0
      [  753.193370]  __rtnl_newlink+0xb9f/0x11b0
      [ ... ]
      [  753.241201] Allocated by task 7186:
      [  753.241844]  save_stack+0x19/0x80
      [  753.242399]  __kasan_kmalloc.constprop.3+0xa0/0xd0
      [  753.243192]  __kmalloc+0x13e/0x300
      [  753.243764]  ops_init+0xd6/0x350
      [  753.244314]  register_pernet_operations+0x249/0x6f0
      [ ... ]
      [  753.251770] Freed by task 7178:
      [  753.252288]  save_stack+0x19/0x80
      [  753.252833]  __kasan_slab_free+0x111/0x150
      [  753.253962]  kfree+0xc7/0x280
      [  753.254509]  ops_free_list.part.11+0x1c4/0x2d0
      [  753.255241]  unregister_pernet_operations+0x262/0x390
      [ ... ]
      [  753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next.
      [  753.287241] ------------[ cut here ]------------
      [  753.287794] kernel BUG at lib/list_debug.c:25!
      [  753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G    B   W         5.2.0-rc6+ #50
      [  753.291036] RIP: 0010:__list_add_valid+0x74/0xd0
      [  753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b
      [  753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286
      [  753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000
      [  753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69
      [  753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21
      [  753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878
      [  753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458
      [  753.299564] FS:  00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000
      [  753.300533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0
      [  753.302183] Call Trace:
      [  753.302530]  gtp_newlink+0x5f6/0xa5c [gtp]
      [  753.303037]  ? __netlink_ns_capable+0xc3/0xf0
      [  753.303576]  __rtnl_newlink+0xb9f/0x11b0
      [  753.304092]  ? rtnl_link_unregister+0x230/0x230
      
      Fixes: 459aa660 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5f6c5f5a
    • T
      gtp: fix use-after-free in gtp_encap_destroy() · 14122221
      Taehee Yoo 提交于
      [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ]
      
      gtp_encap_destroy() is called twice.
      1. When interface is deleted.
      2. When udp socket is destroyed.
      either gtp->sk0 or gtp->sk1u could be freed by sock_put() in
      gtp_encap_destroy(). so, when gtp_encap_destroy() is called again,
      it would uses freed sk pointer.
      
      patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to
      null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected
      by rtnl_lock. so, rtnl_lock() is added.
      
      Test command:
         gtp-link add gtp1 &
         killall gtp-link
         ip link del gtp1
      
      Splat looks like:
      [   83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0
      [   83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008
      [   83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50
      [   83.188469] Call Trace:
      [ ... ]
      [   83.200126]  lock_acquire+0x141/0x380
      [   83.200575]  ? lock_sock_nested+0x3a/0xf0
      [   83.201069]  _raw_spin_lock_bh+0x38/0x70
      [   83.201551]  ? lock_sock_nested+0x3a/0xf0
      [   83.202044]  lock_sock_nested+0x3a/0xf0
      [   83.202520]  gtp_encap_destroy+0x18/0xe0 [gtp]
      [   83.203065]  gtp_encap_disable.isra.14+0x13/0x50 [gtp]
      [   83.203687]  gtp_dellink+0x56/0x170 [gtp]
      [   83.204190]  rtnl_delete_link+0xb4/0x100
      [ ... ]
      [   83.236513] Allocated by task 976:
      [   83.236925]  save_stack+0x19/0x80
      [   83.237332]  __kasan_kmalloc.constprop.3+0xa0/0xd0
      [   83.237894]  kmem_cache_alloc+0xd8/0x280
      [   83.238360]  sk_prot_alloc.isra.42+0x50/0x200
      [   83.238874]  sk_alloc+0x32/0x940
      [   83.239264]  inet_create+0x283/0xc20
      [   83.239684]  __sock_create+0x2dd/0x540
      [   83.240136]  __sys_socket+0xca/0x1a0
      [   83.240550]  __x64_sys_socket+0x6f/0xb0
      [   83.240998]  do_syscall_64+0x9c/0x450
      [   83.241466]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   83.242061]
      [   83.242249] Freed by task 0:
      [   83.242616]  save_stack+0x19/0x80
      [   83.243013]  __kasan_slab_free+0x111/0x150
      [   83.243498]  kmem_cache_free+0x89/0x250
      [   83.244444]  __sk_destruct+0x38f/0x5a0
      [   83.245366]  rcu_core+0x7e9/0x1c20
      [   83.245766]  __do_softirq+0x213/0x8fa
      
      Fixes: 1e3a3abd ("gtp: make GTP sockets in gtp_newlink optional")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      14122221
    • T
      gtp: fix Illegal context switch in RCU read-side critical section. · 0a5eca2c
      Taehee Yoo 提交于
      [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ]
      
      ipv4_pdp_add() is called in RCU read-side critical section.
      So GFP_KERNEL should not be used in the function.
      This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL.
      
      Test commands:
      gtp-link add gtp1 &
      gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2
      
      Splat looks like:
      [  130.618881] =============================
      [  130.626382] WARNING: suspicious RCU usage
      [  130.626994] 5.2.0-rc6+ #50 Not tainted
      [  130.627622] -----------------------------
      [  130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section!
      [  130.629684]
      [  130.629684] other info that might help us debug this:
      [  130.629684]
      [  130.631022]
      [  130.631022] rcu_scheduler_active = 2, debug_locks = 1
      [  130.632136] 4 locks held by gtp-tunnel/1025:
      [  130.632925]  #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40
      [  130.634159]  #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130
      [  130.635487]  #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp]
      [  130.636936]  #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp]
      [  130.638348]
      [  130.638348] stack backtrace:
      [  130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50
      [  130.641318] Call Trace:
      [  130.641707]  dump_stack+0x7c/0xbb
      [  130.642252]  ___might_sleep+0x2c0/0x3b0
      [  130.642862]  kmem_cache_alloc_trace+0x1cd/0x2b0
      [  130.643591]  gtp_genl_new_pdp+0x6c5/0x1150 [gtp]
      [  130.644371]  genl_family_rcv_msg+0x63a/0x1030
      [  130.645074]  ? mutex_lock_io_nested+0x1090/0x1090
      [  130.645845]  ? genl_unregister_family+0x630/0x630
      [  130.646592]  ? debug_show_all_locks+0x2d0/0x2d0
      [  130.647293]  ? check_flags.part.40+0x440/0x440
      [  130.648099]  genl_rcv_msg+0xa3/0x130
      [ ... ]
      
      Fixes: 459aa660 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0a5eca2c
    • T
      gtp: fix suspicious RCU usage · e117a041
      Taehee Yoo 提交于
      [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ]
      
      gtp_encap_enable_socket() and gtp_encap_destroy() are not protected
      by rcu_read_lock(). and it's not safe to write sk->sk_user_data.
      This patch make these functions to use lock_sock() instead of
      rcu_dereference_sk_user_data().
      
      Test commands:
          gtp-link add gtp1
      
      Splat looks like:
      [   83.238315] =============================
      [   83.239127] WARNING: suspicious RCU usage
      [   83.239702] 5.2.0-rc6+ #49 Not tainted
      [   83.240268] -----------------------------
      [   83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage!
      [   83.243828]
      [   83.243828] other info that might help us debug this:
      [   83.243828]
      [   83.246325]
      [   83.246325] rcu_scheduler_active = 2, debug_locks = 1
      [   83.247314] 1 lock held by gtp-link/1008:
      [   83.248523]  #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0
      [   83.251503]
      [   83.251503] stack backtrace:
      [   83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49
      [   83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   83.254562] Call Trace:
      [   83.254995]  dump_stack+0x7c/0xbb
      [   83.255567]  gtp_encap_enable_socket+0x2df/0x360 [gtp]
      [   83.256415]  ? gtp_find_dev+0x1a0/0x1a0 [gtp]
      [   83.257161]  ? memset+0x1f/0x40
      [   83.257843]  gtp_newlink+0x90/0xa21 [gtp]
      [   83.258497]  ? __netlink_ns_capable+0xc3/0xf0
      [   83.259260]  __rtnl_newlink+0xb9f/0x11b0
      [   83.260022]  ? rtnl_link_unregister+0x230/0x230
      [ ... ]
      
      Fixes: 1e3a3abd ("gtp: make GTP sockets in gtp_newlink optional")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e117a041