1. 22 Mar, 2020 3 commits
  2. 21 Mar, 2020 2 commits
  3. 20 Mar, 2020 6 commits
    • Eric Dumazet's avatar
      tcp: ensure skb->dev is NULL before leaving TCP stack · b738a185
      Eric Dumazet authored
      skb->rbnode is sharing three skb fields : next, prev, dev
      
      When a packet is sent, TCP keeps the original skb (master)
      in a rtx queue, which was converted to rbtree a while back.
      
      __tcp_transmit_skb() is responsible to clone the master skb,
      and add the TCP header to the clone before sending it
      to network layer.
      
      skb_clone() already clears skb->next and skb->prev, but copies
      the master oskb->dev into the clone.
      
      We need to clear skb->dev, otherwise lower layers could interpret
      the value as a pointer to a netdev.
      
      This old bug surfaced recently when commit 28f8bfd1
      ("netfilter: Support iif matches in POSTROUTING") was merged.
      
      Before this netfilter commit, skb->dev value was ignored and
      changed before reaching dev_queue_xmit()
      
      Fixes: 75c119af ("tcp: implement rb-tree based retransmit queue")
      Fixes: 28f8bfd1 ("netfilter: Support iif matches in POSTROUTING")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMartin Zaharinov <micron10@gmail.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Pablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b738a185
    • Rahul Lakkireddy's avatar
      cxgb4: fix Txq restart check during backpressure · f1f20a86
      Rahul Lakkireddy authored
      Driver reclaims descriptors in much smaller batches, even if hardware
      indicates more to reclaim, during backpressure. So, fix the check to
      restart the Txq during backpressure, by looking at how many
      descriptors hardware had indicated to reclaim, and not on how many
      descriptors that driver had actually reclaimed. Once the Txq is
      restarted, driver will reclaim even more descriptors when Tx path
      is entered again.
      
      Fixes: d429005f ("cxgb4/cxgb4vf: Add support for SGE doorbell queue timer")
      Signed-off-by: default avatarRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1f20a86
    • Rahul Lakkireddy's avatar
      cxgb4: fix throughput drop during Tx backpressure · 7affd808
      Rahul Lakkireddy authored
      commit 7c3bebc3 ("cxgb4: request the TX CIDX updates to status page")
      reverted back to getting Tx CIDX updates via DMA, instead of interrupts,
      introduced by commit d429005f ("cxgb4/cxgb4vf: Add support for SGE
      doorbell queue timer")
      
      However, it missed reverting back several code changes where Tx CIDX
      updates are not explicitly requested during backpressure when using
      interrupt mode. These missed changes cause slow recovery during
      backpressure because the corresponding interrupt no longer comes and
      hence results in Tx throughput drop.
      
      So, revert back these missed code changes, as well, which will allow
      explicitly requesting Tx CIDX updates when backpressure happens.
      This enables the corresponding interrupt with Tx CIDX update message
      to get generated and hence speed up recovery and restore back
      throughput.
      
      Fixes: 7c3bebc3 ("cxgb4: request the TX CIDX updates to status page")
      Fixes: d429005f ("cxgb4/cxgb4vf: Add support for SGE doorbell queue timer")
      Signed-off-by: default avatarRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7affd808
    • René van Dorst's avatar
      net: dsa: mt7530: Change the LINK bit to reflect the link status · 22259471
      René van Dorst authored
      Andrew reported:
      
      After a number of network port link up/down changes, sometimes the switch
      port gets stuck in a state where it thinks it is still transmitting packets
      but the cpu port is not actually transmitting anymore. In this state you
      will see a message on the console
      "mtk_soc_eth 1e100000.ethernet eth0: transmit timed out" and the Tx counter
      in ifconfig will be incrementing on virtual port, but not incrementing on
      cpu port.
      
      The issue is that MAC TX/RX status has no impact on the link status or
      queue manager of the switch. So the queue manager just queues up packets
      of a disabled port and sends out pause frames when the queue is full.
      
      Change the LINK bit to reflect the link status.
      
      Fixes: b8f126a8 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
      Reported-by: default avatarAndrew Smith <andrew.smith@digi.com>
      Signed-off-by: default avatarRené van Dorst <opensource@vdorst.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22259471
    • David S. Miller's avatar
      Merge tag 'rxrpc-fixes-20200319' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 3ac9eb42
      David S. Miller authored
      David Howells says:
      
      ====================
      rxrpc, afs: Interruptibility fixes
      
      Here are a number of fixes for AF_RXRPC and AFS that make AFS system calls
      less interruptible and so less likely to leave the filesystem in an
      uncertain state.  There's also a miscellaneous patch to make tracing
      consistent.
      
       (1) Firstly, abstract out the Tx space calculation in sendmsg.  Much the
           same code is replicated in a number of places that subsequent patches
           are going to alter, including adding another copy.
      
       (2) Fix Tx interruptibility by allowing a kernel service, such as AFS, to
           request that a call be interruptible only when waiting for a call slot
           to become available (ie. the call has not taken place yet) or that a
           call be not interruptible at all (e.g. when we want to do writeback
           and don't want a signal interrupting a VM-induced writeback).
      
       (3) Increase the minimum delay on MSG_WAITALL for userspace sendmsg() when
           waiting for Tx buffer space as a 2*RTT delay is really small over 10G
           ethernet and a 1 jiffy timeout might be essentially 0 if at the end of
           the jiffy period.
      
       (4) Fix some tracing output in AFS to make it consistent with rxrpc.
      
       (5) Make sure aborted asynchronous AFS operations are tidied up properly
           so we don't end up with stuck rxrpc calls.
      
       (6) Make AFS client calls uninterruptible in the Rx phase.  If we don't
           wait for the reply to be fully gathered, we can't update the local VFS
           state and we end up in an indeterminate state with respect to the
           server.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ac9eb42
    • Ido Schimmel's avatar
      mlxsw: pci: Only issue reset when system is ready · 6002059d
      Ido Schimmel authored
      During initialization the driver issues a software reset command and
      then waits for the system status to change back to "ready" state.
      
      However, before issuing the reset command the driver does not check that
      the system is actually in "ready" state. On Spectrum-{1,2} systems this
      was always the case as the hardware initialization time is very short.
      On Spectrum-3 systems this is no longer the case. This results in the
      software reset command timing-out and the driver failing to load:
      
      [ 6.347591] mlxsw_spectrum3 0000:06:00.0: Cmd exec timed-out (opcode=40(ACCESS_REG),opcode_mod=0,in_mod=0)
      [ 6.358382] mlxsw_spectrum3 0000:06:00.0: Reg cmd access failed (reg_id=9023(mrsr),type=write)
      [ 6.368028] mlxsw_spectrum3 0000:06:00.0: cannot register bus device
      [ 6.375274] mlxsw_spectrum3: probe of 0000:06:00.0 failed with error -110
      
      Fix this by waiting for the system to become ready both before issuing
      the reset command and afterwards. In case of failure, print the last
      system status to aid in debugging.
      
      Fixes: da382875 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6002059d
  4. 19 Mar, 2020 10 commits
  5. 18 Mar, 2020 16 commits
    • Taehee Yoo's avatar
      vxlan: check return value of gro_cells_init() · 384d91c2
      Taehee Yoo authored
      gro_cells_init() returns error if memory allocation is failed.
      But the vxlan module doesn't check the return value of gro_cells_init().
      
      Fixes: 58ce31cc ("vxlan: GRO support at tunnel layer")`
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      384d91c2
    • Paul Blakey's avatar
      net/sched: act_ct: Fix leak of ct zone template on replace · dd2af104
      Paul Blakey authored
      Currently, on replace, the previous action instance params
      is swapped with a newly allocated params. The old params is
      only freed (via kfree_rcu), without releasing the allocated
      ct zone template related to it.
      
      Call tcf_ct_params_free (via call_rcu) for the old params,
      so it will release it.
      
      Fixes: b57dc7c1 ("net/sched: Introduce action ct")
      Signed-off-by: default avatarPaul Blakey <paulb@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd2af104
    • Mauro Carvalho Chehab's avatar
      net: core: dev.c: fix a documentation warning · 2de9780f
      Mauro Carvalho Chehab authored
      There's a markup for link with is "foo_". On this kernel-doc
      comment, we don't want this, but instead, place a literal
      reference. So, escape the literal with ``foo``, in order to
      avoid this warning:
      
      	./net/core/dev.c:5195: WARNING: Unknown target name: "page_is".
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2de9780f
    • Mauro Carvalho Chehab's avatar
      net: phy: sfp-bus.c: get rid of docs warnings · 6497ca07
      Mauro Carvalho Chehab authored
      The indentation for the returned values are weird, causing those
      warnings:
      
      	./drivers/net/phy/sfp-bus.c:579: WARNING: Unexpected indentation.
      	./drivers/net/phy/sfp-bus.c:619: WARNING: Unexpected indentation.
      
      Use a list and change the identation for it to be properly
      parsed by the documentation toolchain.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6497ca07
    • David S. Miller's avatar
      Merge branch 'ENA-driver-bug-fixes' · 15538575
      David S. Miller authored
      Arthur Kiyanovski says:
      
      ====================
      ENA driver bug fixes
      ====================
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15538575
    • Arthur Kiyanovski's avatar
      net: ena: fix continuous keep-alive resets · dfdde134
      Arthur Kiyanovski authored
      last_keep_alive_jiffies is updated in probe and when a keep-alive
      event is received.  In case the driver times-out on a keep-alive event,
      it has high chances of continuously timing-out on keep-alive events.
      This is because when the driver recovers from the keep-alive-timeout reset
      the value of last_keep_alive_jiffies is very old, and if a keep-alive
      event is not received before the next timer expires, the value of
      last_keep_alive_jiffies will cause another keep-alive-timeout reset
      and so forth in a loop.
      
      Solution:
      Update last_keep_alive_jiffies whenever the device is restored after
      reset.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarNoam Dagan <ndagan@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfdde134
    • Arthur Kiyanovski's avatar
      net: ena: avoid memory access violation by validating req_id properly · 30623e1e
      Arthur Kiyanovski authored
      Rx req_id is an index in struct ena_eth_io_rx_cdesc_base.
      The driver should validate that the Rx req_id it received from
      the device is in range [0, ring_size -1].  Failure to do so could
      yield to potential memory access violoation.
      The validation was mistakenly done when refilling
      the Rx submission queue and not in Rx completion queue.
      
      Fixes: ad974bae ("net: ena: add support for out of order rx buffers refill")
      Signed-off-by: default avatarNoam Dagan <ndagan@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30623e1e
    • Arthur Kiyanovski's avatar
      net: ena: fix request of incorrect number of IRQ vectors · e02ae6ed
      Arthur Kiyanovski authored
      Bug:
      In short the main issue is caused by the fact that the number of queues
      is changed using ethtool after ena_probe() has been called and before
      ena_up() was executed. Here is the full scenario in detail:
      
      * ena_probe() is called when the driver is loaded, the driver is not up
        yet at the end of ena_probe().
      * The number of queues is changed -> io_queue_count is changed as well -
        ena_up() is not called since the "dev_was_up" boolean in
        ena_update_queue_count() is false.
      * ena_up() is called by the kernel (it's called asynchronously some
        time after ena_probe()). ena_setup_io_intr() is called by ena_up() and
        it uses io_queue_count to get the suitable irq lines for each msix
        vector. The function ena_request_io_irq() is called right after that
        and it uses msix_vecs - This value only changes during ena_probe() and
        ena_restore() - to request the irq vectors. This results in "Failed to
        request I/O IRQ" error for i > io_queue_count.
      
      Numeric example:
      * After ena_probe() io_queue_count = 8, msix_vecs = 9.
      * The number of queues changes to 4 -> io_queue_count = 4, msix_vecs = 9.
      * ena_up() is executed for the first time:
        ** ena_setup_io_intr() inits the vectors only up to io_queue_count.
        ** ena_request_io_irq() calls request_irq() and fails for i = 5.
      
      How to reproduce:
      simply run the following commands:
          sudo rmmod ena && sudo insmod ena.ko;
          sudo ethtool -L eth1 combined 3;
      
      Fix:
      Use ENA_MAX_MSIX_VEC(adapter->num_io_queues + adapter->xdp_num_queues)
      instead of adapter->msix_vecs. We need to take XDP queues into
      consideration as they need to have msix vectors assigned to them as well.
      Note that the XDP cannot be attached before the driver is up and running
      but in XDP mode the issue might occur when the number of queues changes
      right after a reset trigger.
      The ENA_MAX_MSIX_VEC simply adds one to the argument since the first msix
      vector is reserved for management queue.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarSameeh Jubran <sameehj@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e02ae6ed
    • Arthur Kiyanovski's avatar
      net: ena: fix incorrect setting of the number of msix vectors · ce1f3521
      Arthur Kiyanovski authored
      Overview:
      We don't frequently change the msix vectors throughout the life cycle of
      the driver. We do so in two functions: ena_probe() and ena_restore().
      ena_probe() is only called when the driver is loaded. ena_restore() on the
      other hand is called during device reset / resume operations.
      
      We use num_io_queues for calculating and allocating the number of msix
      vectors. At ena_probe() this value is equal to max_num_io_queues and thus
      this is not an issue, however ena_restore() might be called after the
      number of io queues has changed.
      
      A possible bug scenario is as follows:
      
      * Change number of queues from 8 to 4.
        (num_io_queues = 4, max_num_io_queues = 8, msix_vecs = 9,)
      * Trigger reset occurs -> ena_restore is called.
        (num_io_queues = 4, max_num_io_queues =8 , msix_vecs = 5)
      * Change number of queues from 4 to 6.
        (num_io_queues = 6, max_num_io_queues = 8, msix_vecs = 5)
      * The driver will reset due to failure of check_for_rx_interrupt_queue()
      
      Fix:
      This can be easily fixed by always using max_num_io_queues to init the
      msix_vecs, since this number won't change as opposed to num_io_queues.
      
      Fixes: 4d192660 ("net: ena: multiple queue creation related cleanups")
      Signed-off-by: default avatarSameeh Jubran <sameehj@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce1f3521
    • Rayagonda Kokatanur's avatar
      net: phy: mdio-mux-bcm-iproc: check clk_prepare_enable() return value · 872307ab
      Rayagonda Kokatanur authored
      Check clk_prepare_enable() return value.
      
      Fixes: 2c723044 ("net: phy: Add pm support to Broadcom iProc mdio mux driver")
      Signed-off-by: default avatarRayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      872307ab
    • David S. Miller's avatar
      Merge branch 'net-bcmgenet-revisit-MAC-reset' · af4e6671
      David S. Miller authored
      Doug Berger says:
      
      ====================
      net: bcmgenet: revisit MAC reset
      
      Commit 3a55402c ("net: bcmgenet: use RGMII loopback for MAC
      reset") was intended to resolve issues with reseting the UniMAC
      core within the GENET block by providing better control over the
      clocks used by the UniMAC core. Unfortunately, it is not
      compatible with all of the supported system configurations so an
      alternative method must be applied.
      
      This commit set provides such an alternative. The first commit
      reverts the previous change and the second commit provides the
      alternative reset sequence that addresses the concerns observed
      with the previous implementation.
      
      This replacement implementation should be applied to the stable
      branches wherever commit 3a55402c ("net: bcmgenet: use RGMII
      loopback for MAC reset") has been applied.
      
      Unfortunately, reverting that commit may conflict with some
      restructuring changes introduced by commit 4f8d81b7 ("net:
      bcmgenet: Refactor register access in bcmgenet_mii_config").
      The first commit in this set has been manually edited to
      resolve the conflict on net/master. I would be happy to help
      stable maintainers with resolving any such conflicts if they
      occur. However, I do not expect that commit to have been
      backported to stable branch so hopefully the revert can be
      applied cleanly.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af4e6671
    • Doug Berger's avatar
      net: bcmgenet: keep MAC in reset until PHY is up · 88f6c8bf
      Doug Berger authored
      As noted in commit 28c2d1a7 ("net: bcmgenet: enable loopback
      during UniMAC sw_reset") the UniMAC must be clocked at least 5
      cycles while the sw_reset is asserted to ensure a clean reset.
      
      That commit enabled local loopback to provide an Rx clock from the
      GENET sourced Tx clk. However, when connected in MII mode the Tx
      clk is sourced by the PHY so if an EPHY is not supplying clocks
      (e.g. when the link is down) the UniMAC does not receive the
      necessary clocks.
      
      This commit extends the sw_reset window until the PHY reports that
      the link is up thereby ensuring that the clocks are being provided
      to the MAC to produce a clean reset.
      
      One consequence is that if the system attempts to enter a Wake on
      LAN suspend state when the PHY link has not been active the MAC
      may not have had a chance to initialize cleanly. In this case, we
      remove the sw_reset and enable the WoL reception path as normal
      with the hope that the PHY will provide the necessary clocks to
      drive the WoL blocks if the link becomes active after the system
      has entered suspend.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88f6c8bf
    • Doug Berger's avatar
      Revert "net: bcmgenet: use RGMII loopback for MAC reset" · 612eb1c3
      Doug Berger authored
      This reverts commit 3a55402c.
      
      This is not a good solution when connecting to an external switch
      that may not support the isolation of the TXC signal resulting in
      output driver contention on the pin.
      
      A different solution is necessary.
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      612eb1c3
    • David S. Miller's avatar
      Merge branch 'net-mvmdio-avoid-error-message-for-optional-IRQ' · d36963b8
      David S. Miller authored
      Chris Packham says:
      
      ====================
      net: mvmdio: avoid error message for optional IRQ
      
      I've gone ahead an sent a revert. This is the same as the original v1 except
      I've added Andrew's review to the commit message.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d36963b8
    • Chris Packham's avatar
      net: mvmdio: avoid error message for optional IRQ · fa2632f7
      Chris Packham authored
      Per the dt-binding the interrupt is optional so use
      platform_get_irq_optional() instead of platform_get_irq(). Since
      commit 7723f4c5 ("driver core: platform: Add an error message to
      platform_get_irq*()") platform_get_irq() produces an error message
      
        orion-mdio f1072004.mdio: IRQ index 0 not found
      
      which is perfectly normal if one hasn't specified the optional property
      in the device tree.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa2632f7
    • Chris Packham's avatar
      Revert "net: mvmdio: avoid error message for optional IRQ" · 028fd76b
      Chris Packham authored
      This reverts commit e1f550dc.
      platform_get_irq_optional() will still return -ENXIO when no interrupt
      is provided so the additional error handling caused the driver prone to
      fail when no interrupt was specified. Revert the change so we can apply
      the correct minimal fix.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      028fd76b
  6. 17 Mar, 2020 1 commit
  7. 16 Mar, 2020 2 commits