1. 20 Mar, 2020 4 commits
    • 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
  2. 19 Mar, 2020 6 commits
    • David S. Miller's avatar
      Merge branch 'wireguard-fixes' · 3c025b63
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard fixes for 5.6-rc7
      
      I originally intended to spend this cycle working on fun optimizations
      and architecture for WireGuard for 5.7, but I've been a bit neurotic
      about having 5.6 ship without any show stopper bugs. WireGuard has been
      stable for a long time now, but that doesn't make me any less nervous
      about the real deal in 5.6. To that end, I've been doing code reviews
      and having discussions, and we also had a security firm audit the code.
      That audit didn't turn up any vulnerabilities, but they did make a good
      defense-in-depth suggestion. This series contains:
      
      1) Removal of a duplicated header, from YueHaibing.
      2) Testing with 64-bit time in our test suite.
      3) Account for skb->protocol==0 due to AF_PACKET sockets, suggested
         by Florian Fainelli.
      4) Clean up some code in an unreachable switch/case branch, suggested
         by Florian Fainelli.
      5) Better handling of low-order points, discussed with Mathias
         Hall-Andersen.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c025b63
    • Jason A. Donenfeld's avatar
      wireguard: noise: error out precomputed DH during handshake rather than config · 11a7686a
      Jason A. Donenfeld authored
      We precompute the static-static ECDH during configuration time, in order
      to save an expensive computation later when receiving network packets.
      However, not all ECDH computations yield a contributory result. Prior,
      we were just not letting those peers be added to the interface. However,
      this creates a strange inconsistency, since it was still possible to add
      other weird points, like a valid public key plus a low-order point, and,
      like points that result in zeros, a handshake would not complete. In
      order to make the behavior more uniform and less surprising, simply
      allow all peers to be added. Then, we'll error out later when doing the
      crypto if there's an issue. This also adds more separation between the
      crypto layer and the configuration layer.
      
      Discussed-with: Mathias Hall-Andersen <mathias@hall-andersen.dk>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11a7686a
    • Jason A. Donenfeld's avatar
      wireguard: receive: remove dead code from default packet type case · 2b8765c5
      Jason A. Donenfeld authored
      The situation in which we wind up hitting the default case here
      indicates a major bug in earlier parsing code. It is not a usual thing
      that should ever happen, which means a "friendly" message for it doesn't
      make sense. Rather, replace this with a WARN_ON, just like we do earlier
      in the file for a similar situation, so that somebody sends us a bug
      report and we can fix it.
      Reported-by: default avatarFabian Freyer <fabianfreyer@radicallyopensecurity.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b8765c5
    • Jason A. Donenfeld's avatar
      wireguard: queueing: account for skb->protocol==0 · a5588604
      Jason A. Donenfeld authored
      We carry out checks to the effect of:
      
        if (skb->protocol != wg_examine_packet_protocol(skb))
          goto err;
      
      By having wg_skb_examine_untrusted_ip_hdr return 0 on failure, this
      means that the check above still passes in the case where skb->protocol
      is zero, which is possible to hit with AF_PACKET:
      
        struct sockaddr_pkt saddr = { .spkt_device = "wg0" };
        unsigned char buffer[5] = { 0 };
        sendto(socket(AF_PACKET, SOCK_PACKET, /* skb->protocol = */ 0),
               buffer, sizeof(buffer), 0, (const struct sockaddr *)&saddr, sizeof(saddr));
      
      Additional checks mean that this isn't actually a problem in the code
      base, but I could imagine it becoming a problem later if the function is
      used more liberally.
      
      I would prefer to fix this by having wg_examine_packet_protocol return a
      32-bit ~0 value on failure, which will never match any value of
      skb->protocol, which would simply change the generated code from a mov
      to a movzx. However, sparse complains, and adding __force casts doesn't
      seem like a good idea, so instead we just add a simple helper function
      to check for the zero return value. Since wg_examine_packet_protocol
      itself gets inlined, this winds up not adding an additional branch to
      the generated code, since the 0 return value already happens in a
      mergable branch.
      Reported-by: default avatarFabian Freyer <fabianfreyer@radicallyopensecurity.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5588604
    • Jason A. Donenfeld's avatar
      wireguard: selftests: test using new 64-bit time_t · 551599ed
      Jason A. Donenfeld authored
      In case this helps expose bugs with the newer 64-bit time_t types, we do
      our testing with the newer musl that supports this as well as
      CONFIG_COMPAT_32BIT_TIME=n. This matters to us, since wireguard does in
      fact deal with timestamps.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      551599ed
    • YueHaibing's avatar
      wireguard: selftests: remove duplicated include <sys/types.h> · 16639115
      YueHaibing authored
      This commit removes a duplicated include.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16639115
  3. 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
  4. 17 Mar, 2020 1 commit
  5. 16 Mar, 2020 13 commits
    • Jisheng Zhang's avatar
      net: mvneta: Fix the case where the last poll did not process all rx · 065fd83e
      Jisheng Zhang authored
      For the case where the last mvneta_poll did not process all
      RX packets, we need to xor the pp->cause_rx_tx or port->cause_rx_tx
      before claculating the rx_queue.
      
      Fixes: 2dcf75e2 ("net: mvneta: Associate RX queues with each CPU")
      Signed-off-by: default avatarJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      065fd83e
    • Zheng Wei's avatar
      net: vxge: fix wrong __VA_ARGS__ usage · b317538c
      Zheng Wei authored
      printk in macro vxge_debug_ll uses __VA_ARGS__ without "##" prefix,
      it causes a build error when there is no variable
      arguments(e.g. only fmt is specified.).
      Signed-off-by: default avatarZheng Wei <wei.zheng@vivo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b317538c
    • David S. Miller's avatar
      Merge branch 'QorIQ-DPAA-ARM-RDBs-need-internal-delay-on-RGMII' · 83d00106
      David S. Miller authored
      Madalin Bucur says:
      
      ====================
      QorIQ DPAA ARM RDBs need internal delay on RGMII
      
      v2: used phy_interface_mode_is_rgmii() to identify RGMII
      
      The QorIQ DPAA 1 based RDB boards require internal delay on
      both Tx and Rx to be set. The patch set ensures all RGMII
      modes are treated correctly by the FMan driver and sets the
      phy-connection-type to "rgmii-id" to restore functionality.
      Previously Rx internal delay was set by board pull-ups and
      was left untouched by the PHY driver. Since commit
      1b3047b5 ("net: phy: realtek: add support for
      configuring the RX delay on RTL8211F") the Realtek 8211F PHY
      driver has control over the RGMII RX delay and it is
      disabling it for other modes than RGMII_RXID and RGMII_ID.
      
      Please note that u-boot in particular performs a fix-up of
      the PHY connection type and will overwrite the values from
      the Linux device tree. Another patch set was sent for u-boot
      and one needs to apply that [1] to the boot loader, to ensure
      this fix is complete, unless a different bootloader is used.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83d00106
    • Madalin Bucur's avatar
      arm64: dts: ls1046ardb: set RGMII interfaces to RGMII_ID mode · d79e9d7c
      Madalin Bucur authored
      The correct setting for the RGMII ports on LS1046ARDB is to
      enable delay on both Rx and Tx so the interface mode used must
      be PHY_INTERFACE_MODE_RGMII_ID.
      
      Since commit 1b3047b5 ("net: phy: realtek: add support for
      configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver
      has control over the RGMII RX delay and it is disabling it for
      RGMII_TXID. The LS1046ARDB uses two such PHYs in RGMII_ID mode but
      in the device tree the mode was described as "rgmii".
      
      Changing the phy-connection-type to "rgmii-id" to address the issue.
      
      Fixes: 3fa395d2 ("arm64: dts: add LS1046A DPAA FMan nodes")
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@oss.nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d79e9d7c
    • Madalin Bucur's avatar
      arm64: dts: ls1043a-rdb: correct RGMII delay mode to rgmii-id · 4022d808
      Madalin Bucur authored
      The correct setting for the RGMII ports on LS1043ARDB is to
      enable delay on both Rx and Tx so the interface mode used must
      be PHY_INTERFACE_MODE_RGMII_ID.
      
      Since commit 1b3047b5 ("net: phy: realtek: add support for
      configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver
      has control over the RGMII RX delay and it is disabling it for
      RGMII_TXID. The LS1043ARDB uses two such PHYs in RGMII_ID mode but
      in the device tree the mode was described as "rgmii_txid".
      This issue was not apparent at the time as the PHY driver took the
      same action for RGMII_TXID and RGMII_ID back then but it became
      visible (RX no longer working) after the above patch.
      
      Changing the phy-connection-type to "rgmii-id" to address the issue.
      
      Fixes: bf02f2ff ("arm64: dts: add LS1043A DPAA FMan support")
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@oss.nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4022d808
    • Madalin Bucur's avatar
      net: fsl/fman: treat all RGMII modes in memac_adjust_link() · 0fe15680
      Madalin Bucur authored
      Treat all internal delay variants the same as RGMII.
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@oss.nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fe15680
    • David S. Miller's avatar
      Merge branch 'ethtool-fail-with-error-if-request-has-unknown-flags' · 23c39481
      David S. Miller authored
      Michal Kubecek says:
      
      ====================
      ethtool: fail with error if request has unknown flags
      
      Jakub Kicinski pointed out that if unrecognized flags are set in netlink
      header request, kernel shoud fail with an error rather than silently
      ignore them so that we have more freedom in future flags semantics.
      
      To help userspace with handling such errors, inform the client which
      flags are supported by kernel. For that purpose, we need to allow
      passing cookies as part of extack also in case of error (they can be
      only passed on success now).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23c39481
    • Michal Kubecek's avatar
      ethtool: reject unrecognized request flags · 2363d73a
      Michal Kubecek authored
      As pointed out by Jakub Kicinski, we ethtool netlink code should respond
      with an error if request head has flags set which are not recognized by
      kernel, either as a mistake or because it expects functionality introduced
      in later kernel versions.
      
      To avoid unnecessary roundtrips, use extack cookie to provide the
      information about supported request flags.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2363d73a
    • Michal Kubecek's avatar
      netlink: add nl_set_extack_cookie_u32() · f1388ec4
      Michal Kubecek authored
      Similar to existing nl_set_extack_cookie_u64(), add new helper
      nl_set_extack_cookie_u32() which sets extack cookie to a u32 value.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1388ec4
    • Michal Kubecek's avatar
      netlink: allow extack cookie also for error messages · fe2a31d7
      Michal Kubecek authored
      Commit ba0dc5f6 ("netlink: allow sending extended ACK with cookie on
      success") introduced a cookie which can be sent to userspace as part of
      extended ack message in the form of NLMSGERR_ATTR_COOKIE attribute.
      Currently the cookie is ignored if error code is non-zero but there is
      no technical reason for such limitation and it can be useful to provide
      machine parseable information as part of an error message.
      
      Include NLMSGERR_ATTR_COOKIE whenever the cookie has been set,
      regardless of error code.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe2a31d7
    • Cong Wang's avatar
      net_sched: cls_route: remove the right filter from hashtable · ef299cc3
      Cong Wang authored
      route4_change() allocates a new filter and copies values from
      the old one. After the new filter is inserted into the hash
      table, the old filter should be removed and freed, as the final
      step of the update.
      
      However, the current code mistakenly removes the new one. This
      looks apparently wrong to me, and it causes double "free" and
      use-after-free too, as reported by syzbot.
      
      Reported-and-tested-by: syzbot+f9b32aaacd60305d9687@syzkaller.appspotmail.com
      Reported-and-tested-by: syzbot+2f8c233f131943d6056d@syzkaller.appspotmail.com
      Reported-and-tested-by: syzbot+9c2df9fd5e9445b74e01@syzkaller.appspotmail.com
      Fixes: 1109c005 ("net: sched: RCU cls_route")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef299cc3
    • David S. Miller's avatar
      Merge branch 'hsr-fix-several-bugs-in-generic-netlink-callback' · 4ae649e8
      David S. Miller authored
      Taehee Yoo says:
      
      ====================
      hsr: fix several bugs in generic netlink callback
      
      This patchset is to fix several bugs they are related in
      generic netlink callback in hsr module.
      
      1. The first patch is to add missing rcu_read_lock() in
      hsr_get_node_{list/status}().
      The hsr_get_node_{list/status}() are not protected by RTNL because
      they are callback functions of generic netlink.
      But it calls __dev_get_by_index() without acquiring RTNL.
      So, it would use unsafe data.
      
      2. The second patch is to avoid failure of hsr_get_node_list().
      hsr_get_node_list() is a callback of generic netlink and
      it is used to get node information in userspace.
      But, if there are so many nodes, it fails because of buffer size.
      So, in this patch, restart routine is added.
      
      3. The third patch is to set .netnsok flag to true.
      If .netnsok flag is false, non-init_net namespace is not allowed to
      operate generic netlink operations.
      So, currently, non-init_net namespace has no way to get node information
      because .netnsok is false in the current hsr code.
      
      Change log:
      v1->v2:
       - Preserve reverse christmas tree variable ordering in the second patch.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ae649e8
    • Taehee Yoo's avatar
      hsr: set .netnsok flag · 09e91dbe
      Taehee Yoo authored
      The hsr module has been supporting the list and status command.
      (HSR_C_GET_NODE_LIST and HSR_C_GET_NODE_STATUS)
      These commands send node information to the user-space via generic netlink.
      But, in the non-init_net namespace, these commands are not allowed
      because .netnsok flag is false.
      So, there is no way to get node information in the non-init_net namespace.
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09e91dbe