1. 18 Oct, 2019 7 commits
    • Eric Dumazet's avatar
      net: ensure correct skb->tstamp in various fragmenters · 9669fffc
      Eric Dumazet authored
      Thomas found that some forwarded packets would be stuck
      in FQ packet scheduler because their skb->tstamp contained
      timestamps far in the future.
      
      We thought we addressed this point in commit 8203e2d8
      ("net: clear skb->tstamp in forwarding paths") but there
      is still an issue when/if a packet needs to be fragmented.
      
      In order to meet EDT requirements, we have to make sure all
      fragments get the original skb->tstamp.
      
      Note that this original skb->tstamp should be zero in
      forwarding path, but might have a non zero value in
      output path if user decided so.
      
      Fixes: fb420d5d ("tcp/fq: move back to CLOCK_MONOTONIC")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarThomas Bartschies <Thomas.Bartschies@cvk.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9669fffc
    • David S. Miller's avatar
      Merge branch 'net-bcmgenet-restore-internal-EPHY-support' · 63158ac0
      David S. Miller authored
      Doug Berger says:
      
      ====================
      net: bcmgenet: restore internal EPHY support
      
      I managed to get my hands on an old BCM97435SVMB board to do some
      testing with the latest kernel and uncovered a number of things
      that managed to get broken over the years (some by me ;).
      
      This commit set attempts to correct the errors I observed in my
      testing.
      
      The first commit applies to all internal PHYs to restore proper
      reporting of link status when a link comes up.
      
      The second commit restores the soft reset to the initialization of
      the older internal EPHYs used by 40nm Set-Top Box devices.
      
      The third corrects a bug I introduced when removing excessive soft
      resets by altering the initialization sequence in a way that keeps
      the GENETv3 MAC interface happy.
      
      Finally, I observed a number of issues when manually configuring
      the network interface of the older EPHYs that appear to be resolved
      by the fourth commit.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63158ac0
    • Doug Berger's avatar
      net: bcmgenet: reset 40nm EPHY on energy detect · 25382b99
      Doug Berger authored
      The EPHY integrated into the 40nm Set-Top Box devices can falsely
      detect energy when connected to a disabled peer interface. When the
      peer interface is enabled the EPHY will detect and report the link
      as active, but on occasion may get into a state where it is not
      able to exchange data with the connected GENET MAC. This issue has
      not been observed when the link parameters are auto-negotiated;
      however, it has been observed with a manually configured link.
      
      It has been empirically determined that issuing a soft reset to the
      EPHY when energy is detected prevents it from getting into this bad
      state.
      
      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>
      25382b99
    • Doug Berger's avatar
      net: bcmgenet: soft reset 40nm EPHYs before MAC init · 1f515486
      Doug Berger authored
      It turns out that the "Workaround for putting the PHY in IDDQ mode"
      used by the internal EPHYs on 40nm Set-Top Box chips when powering
      down puts the interface to the GENET MAC in a state that can cause
      subsequent MAC resets to be incomplete.
      
      Rather than restore the forced soft reset when powering up internal
      PHYs, this commit moves the invocation of phy_init_hw earlier in
      the MAC initialization sequence to just before the MAC reset in the
      open and resume functions. This allows the interface to be stable
      and allows the MAC resets to be successful.
      
      The bcmgenet_mii_probe() function is split in two to accommodate
      this. The new function bcmgenet_mii_connect() handles the first
      half of the functionality before the MAC initialization, and the
      bcmgenet_mii_config() function is extended to provide the remaining
      PHY configuration following the MAC initialization.
      
      Fixes: 484bfa15 ("Revert "net: bcmgenet: Software reset EPHY after power on"")
      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>
      1f515486
    • Doug Berger's avatar
      net: phy: bcm7xxx: define soft_reset for 40nm EPHY · fe586b82
      Doug Berger authored
      The internal 40nm EPHYs use a "Workaround for putting the PHY in
      IDDQ mode." These PHYs require a soft reset to restore functionality
      after they are powered back up.
      
      This commit defines the soft_reset function to use genphy_soft_reset
      during phy_init_hw to accommodate this.
      
      Fixes: 6e2d85ec ("net: phy: Stop with excessive soft reset")
      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>
      fe586b82
    • Doug Berger's avatar
      net: bcmgenet: don't set phydev->link from MAC · 7de48402
      Doug Berger authored
      When commit 28b2e0d2 ("net: phy: remove parameter new_link from
      phy_mac_interrupt()") removed the new_link parameter it set the
      phydev->link state from the MAC before invoking phy_mac_interrupt().
      
      However, once commit 88d6272a ("net: phy: avoid unneeded MDIO
      reads in genphy_read_status") was added this initialization prevents
      the proper determination of the connection parameters by the function
      genphy_read_status().
      
      This commit removes that initialization to restore the proper
      functionality.
      
      Fixes: 88d6272a ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
      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>
      7de48402
    • Sean Wang's avatar
      net: Update address for MediaTek ethernet driver in MAINTAINERS · 0cc76d2b
      Sean Wang authored
      Update maintainers for MediaTek ethernet driver with Mark Lee.
      He is familiar with MediaTek mt762x series ethernet devices and
      will keep following maintenance from the vendor side.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMark Lee <Mark-MC.Lee@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0cc76d2b
  2. 17 Oct, 2019 11 commits
    • Wei Wang's avatar
      ipv4: fix race condition between route lookup and invalidation · 5018c596
      Wei Wang authored
      Jesse and Ido reported the following race condition:
      <CPU A, t0> - Received packet A is forwarded and cached dst entry is
      taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set()
      
      <t1> - Given Jesse has busy routers ("ingesting full BGP routing tables
      from multiple ISPs"), route is added / deleted and rt_cache_flush() is
      called
      
      <CPU B, t2> - Received packet B tries to use the same cached dst entry
      from t0, but rt_cache_valid() is no longer true and it is replaced in
      rt_cache_route() by the newer one. This calls dst_dev_put() on the
      original dst entry which assigns the blackhole netdev to 'dst->dev'
      
      <CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due
      to 'dst->dev' being the blackhole netdev
      
      There are 2 issues in the v4 routing code:
      1. A per-netns counter is used to do the validation of the route. That
      means whenever a route is changed in the netns, users of all routes in
      the netns needs to redo lookup. v6 has an implementation of only
      updating fn_sernum for routes that are affected.
      2. When rt_cache_valid() returns false, rt_cache_route() is called to
      throw away the current cache, and create a new one. This seems
      unnecessary because as long as this route does not change, the route
      cache does not need to be recreated.
      
      To fully solve the above 2 issues, it probably needs quite some code
      changes and requires careful testing, and does not suite for net branch.
      
      So this patch only tries to add the deleted cached rt into the uncached
      list, so user could still be able to use it to receive packets until
      it's done.
      
      Fixes: 95c47f9c ("ipv4: call dst_dev_put() properly")
      Signed-off-by: default avatarWei Wang <weiwan@google.com>
      Reported-by: default avatarIdo Schimmel <idosch@idosch.org>
      Reported-by: default avatarJesse Hathaway <jesse@mbuki-mvuki.org>
      Tested-by: default avatarJesse Hathaway <jesse@mbuki-mvuki.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5018c596
    • Stefano Brivio's avatar
      ipv4: Return -ENETUNREACH if we can't create route but saddr is valid · 595e0651
      Stefano Brivio authored
      ...instead of -EINVAL. An issue was found with older kernel versions
      while unplugging a NFS client with pending RPCs, and the wrong error
      code here prevented it from recovering once link is back up with a
      configured address.
      
      Incidentally, this is not an issue anymore since commit 4f8943f8
      ("SUNRPC: Replace direct task wakeups from softirq context"), included
      in 5.2-rc7, had the effect of decoupling the forwarding of this error
      by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin
      Coddington.
      
      To the best of my knowledge, this isn't currently causing any further
      issue, but the error code doesn't look appropriate anyway, and we
      might hit this in other paths as well.
      
      In detail, as analysed by Gonzalo Siero, once the route is deleted
      because the interface is down, and can't be resolved and we return
      -EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(),
      as the socket error seen by tcp_write_err(), called by
      tcp_retransmit_timer().
      
      In turn, tcp_write_err() indirectly calls xs_error_report(), which
      wakes up the RPC pending tasks with a status of -EINVAL. This is then
      seen by call_status() in the SUN RPC implementation, which aborts the
      RPC call calling rpc_exit(), instead of handling this as a
      potentially temporary condition, i.e. as a timeout.
      
      Return -EINVAL only if the input parameters passed to
      ip_route_output_key_hash_rcu() are actually invalid (this is the case
      if the specified source address is multicast, limited broadcast or
      all zeroes), but return -ENETUNREACH in all cases where, at the given
      moment, the given source address doesn't allow resolving the route.
      
      While at it, drop the initialisation of err to -ENETUNREACH, which
      was added to __ip_route_output_key() back then by commit
      0315e382 ("net: Fix behaviour of unreachable, blackhole and
      prohibit routes"), but actually had no effect, as it was, and is,
      overwritten by the fib_lookup() return code assignment, and anyway
      ignored in all other branches, including the if (fl4->saddr) one:
      I find this rather confusing, as it would look like -ENETUNREACH is
      the "default" error, while that statement has no effect.
      
      Also note that after commit fc75fc83 ("ipv4: dont create routes
      on down devices"), we would get -ENETUNREACH if the device is down,
      but -EINVAL if the source address is specified and we can't resolve
      the route, and this appears to be rather inconsistent.
      Reported-by: default avatarStefan Walter <walteste@inf.ethz.ch>
      Analysed-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Analysed-by: default avatarGonzalo Siero <gsierohu@redhat.com>
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      595e0651
    • Marek Vasut's avatar
      net: phy: micrel: Update KSZ87xx PHY name · 1d951ba3
      Marek Vasut authored
      The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
      Update the PHY ID and name to reflect that, as this family of switches
      is commonly refered to as KSZ87xx
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d951ba3
    • Marek Vasut's avatar
      net: phy: micrel: Discern KSZ8051 and KSZ8795 PHYs · 8b95599c
      Marek Vasut authored
      The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
      same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
      in the micrel PHY driver, it is used even with the KSZ87xx switch. This
      is wrong, since the KSZ8051 configures registers of the PHY which are
      not present on the simplified KSZ87xx switch PHYs and misconfigures
      other registers of the KSZ87xx switch PHYs.
      
      Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the
      KSZ87xx switch by checking the Basic Status register Bit 0, which is
      read-only and indicates presence of the Extended Capability Registers.
      The KSZ8051 PHY has those registers while the KSZ87xx switch does not.
      
      This patch implements simple check for the presence of this bit for
      both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct
      PHY driver instance.
      
      Fixes: 9d162ed6 ("net: phy: micrel: add support for KSZ8795")
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b95599c
    • Marek Vasut's avatar
      net: dsa: microchip: Add shared regmap mutex · 013572a2
      Marek Vasut authored
      The KSZ driver uses one regmap per register width (8/16/32), each with
      it's own lock, but accessing the same set of registers. In theory, it
      is possible to create a race condition between these regmaps, although
      the underlying bus (SPI or I2C) locking should assure nothing bad will
      really happen and the accesses would be correct.
      
      To make the driver do the right thing, add one single shared mutex for
      all the regmaps used by the driver instead. This assures that even if
      some future hardware is on a bus which does not serialize the accesses
      the same way SPI or I2C does, nothing bad will happen.
      
      Note that the status_mutex was unused and only initied, hence it was
      renamed and repurposed as the regmap mutex.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      013572a2
    • Marek Vasut's avatar
      net: dsa: microchip: Do not reinit mutexes on KSZ87xx · 7f238ca9
      Marek Vasut authored
      The KSZ87xx driver calls mutex_init() on mutexes already inited in
      ksz_common.c ksz_switch_register(). Do not do it twice, drop the
      reinitialization.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: George McCollister <george.mccollister@gmail.com>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f238ca9
    • Ben Dooks (Codethink)'s avatar
      net: stmmac: fix argument to stmmac_pcs_ctrl_ane() · c9ad4c10
      Ben Dooks (Codethink) authored
      The stmmac_pcs_ctrl_ane() expects a register address as
      argument 1, but for some reason the mac_device_info is
      being passed.
      
      Fix the warning (and possible bug) from sparse:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:    expected void [noderef] <asn:2> *ioaddr
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:    got struct mac_device_info *hw
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9ad4c10
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-misc-fixes' · 693aa7dd
      David S. Miller authored
      Ioana Ciornei says:
      
      ====================
      dpaa2-eth: misc fixes
      
      This patch set adds a couple of fixes around updating configuration on MAC
      change.  Depending on when MC connects the DPNI to a MAC, both the MAC
      address and TX FQIDs should be updated everytime there is a change in
      configuration.
      
      Changes in v2:
       - used reverse christmas tree ordering in patch 2/2
      Changes in v3:
       - add a missing new line
       - go back to FQ based enqueueing after a transient error
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      693aa7dd
    • Ioana Radulescu's avatar
      dpaa2-eth: Fix TX FQID values · a690af4f
      Ioana Radulescu authored
      Depending on when MC connects the DPNI to a MAC, Tx FQIDs may
      not be available during probe time.
      
      Read the FQIDs each time the link goes up to avoid using invalid
      values. In case an error occurs or an invalid value is retrieved,
      fall back to QDID-based enqueueing.
      
      Fixes: 1fa0f68c ("dpaa2-eth: Use FQ-based DPIO enqueue API")
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a690af4f
    • Florin Chiculita's avatar
      dpaa2-eth: add irq for the dpmac connect/disconnect event · 8398b375
      Florin Chiculita authored
      Add IRQ for the DPNI endpoint change event, resolving the issue
      when a dynamically created DPNI gets a randomly generated hw address
      when the endpoint is a DPMAC object.
      Signed-off-by: default avatarFlorin Chiculita <florinlaurentiu.chiculita@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8398b375
    • Oliver Neukum's avatar
      usb: hso: obey DMA rules in tiocmget · af0de130
      Oliver Neukum authored
      The serial state information must not be embedded into another
      data structure, as this interferes with cache handling for DMA
      on architectures without cache coherence..
      That would result in data corruption on some architectures
      Allocating it separately.
      
      v2: fix syntax error
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af0de130
  3. 16 Oct, 2019 20 commits
    • Biao Huang's avatar
      net: stmmac: disable/enable ptp_ref_clk in suspend/resume flow · e497c20e
      Biao Huang authored
      disable ptp_ref_clk in suspend flow, and enable it in resume flow.
      
      Fixes: f573c0b9 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e497c20e
    • Yonglong Liu's avatar
      net: phy: Fix "link partner" information disappear issue · 3de5ae54
      Yonglong Liu authored
      Some drivers just call phy_ethtool_ksettings_set() to set the
      links, for those phy drivers that use genphy_read_status(), if
      autoneg is on, and the link is up, than execute "ethtool -s
      ethx autoneg on" will cause "link partner" information disappear.
      
      The call trace is phy_ethtool_ksettings_set()->phy_start_aneg()
      ->linkmode_zero(phydev->lp_advertising)->genphy_read_status(),
      the link didn't change, so genphy_read_status() just return, and
      phydev->lp_advertising is zero now.
      
      This patch moves the clear operation of lp_advertising from
      phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and
      if autoneg on and autoneg not complete, just clear what the
      generic functions care about.
      
      Fixes: 88d6272a ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Reviewed-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3de5ae54
    • Eric Dumazet's avatar
      rxrpc: use rcu protection while reading sk->sk_user_data · 2ca4f6ca
      Eric Dumazet authored
      We need to extend the rcu_read_lock() section in rxrpc_error_report()
      and use rcu_dereference_sk_user_data() instead of plain access
      to sk->sk_user_data to make sure all rules are respected.
      
      The compiler wont reload sk->sk_user_data at will, and RCU rules
      prevent memory beeing freed too soon.
      
      Fixes: f0308fb0 ("rxrpc: Fix possible NULL pointer access in ICMP handling")
      Fixes: 17926a79 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ca4f6ca
    • Mahesh Bandewar's avatar
      Revert "blackhole_netdev: fix syzkaller reported issue" · bd74708c
      Mahesh Bandewar authored
      This reverts commit b0818f80.
      
      Started seeing weird behavior after this patch especially in
      the IPv6 code path. Haven't root caused it, but since this was
      applied to net branch, taking a precautionary measure to revert
      it and look / analyze those failures
      
      Revert this now and I'll send a better fix after analysing / fixing
      the weirdness observed.
      
      CC: Eric Dumazet <edumazet@google.com>
      CC: Wei Wang <weiwan@google.com>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd74708c
    • Valentin Vidic's avatar
      net: usb: sr9800: fix uninitialized local variable · 77b6d09f
      Valentin Vidic authored
      Make sure res does not contain random value if the call to
      sr_read_cmd fails for some reason.
      
      Reported-by: syzbot+f1842130bbcfb335bac1@syzkaller.appspotmail.com
      Signed-off-by: default avatarValentin Vidic <vvidic@valentin-vidic.from.hr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77b6d09f
    • Florian Fainelli's avatar
      net: bcmgenet: Fix RGMII_MODE_EN value for GENET v1/2/3 · efb86fed
      Florian Fainelli authored
      The RGMII_MODE_EN bit value was 0 for GENET versions 1 through 3, and
      became 6 for GENET v4 and above, account for that difference.
      
      Fixes: aa09677c ("net: bcmgenet: add MDIO routines")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: default avatarDoug Berger <opendmb@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      efb86fed
    • Ben Dooks (Codethink)'s avatar
      net: stmmac: make tc_flow_parsers static · bad28d88
      Ben Dooks (Codethink) authored
      The tc_flow_parsers is not used outside of the driver, so
      make it static to avoid the following sparse warning:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c:516:3: warning: symbol 'tc_flow_parsers' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bad28d88
    • Ben Dooks (Codethink)'s avatar
      davinci_cpdma: make cpdma_chan_split_pool static · 539825a5
      Ben Dooks (Codethink) authored
      The cpdma_chan_split_pool() function is not used outside of
      the driver, so make it static to avoid the following sparse
      warning:
      
      drivers/net/ethernet/ti/davinci_cpdma.c:725:5: warning: symbol 'cpdma_chan_split_pool' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      539825a5
    • Thomas Bogendoerfer's avatar
      net: i82596: fix dma_alloc_attr for sni_82596 · 61c1d33d
      Thomas Bogendoerfer authored
      Commit 7f683b92 ("i825xx: switch to switch to dma_alloc_attrs")
      switched dma allocation over to dma_alloc_attr, but didn't convert
      the SNI part to request consistent DMA memory. This broke sni_82596
      since driver doesn't do dma_cache_sync for performance reasons.
      Fix this by using different DMA_ATTRs for lasi_82596 and sni_82596.
      
      Fixes: 7f683b92 ("i825xx: switch to switch to dma_alloc_attrs")
      Signed-off-by: default avatarThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61c1d33d
    • Xin Long's avatar
      sctp: change sctp_prot .no_autobind with true · 63dfb793
      Xin Long authored
      syzbot reported a memory leak:
      
        BUG: memory leak, unreferenced object 0xffff888120b3d380 (size 64):
        backtrace:
      
          [...] slab_alloc mm/slab.c:3319 [inline]
          [...] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
          [...] sctp_bucket_create net/sctp/socket.c:8523 [inline]
          [...] sctp_get_port_local+0x189/0x5a0 net/sctp/socket.c:8270
          [...] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402
          [...] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497
          [...] sctp_setsockopt_bindx+0x156/0x1b0 net/sctp/socket.c:1022
          [...] sctp_setsockopt net/sctp/socket.c:4641 [inline]
          [...] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611
          [...] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3147
          [...] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
          [...] __do_sys_setsockopt net/socket.c:2100 [inline]
      
      It was caused by when sending msgs without binding a port, in the path:
      inet_sendmsg() -> inet_send_prepare() -> inet_autobind() ->
      .get_port/sctp_get_port(), sp->bind_hash will be set while bp->port is
      not. Later when binding another port by sctp_setsockopt_bindx(), a new
      bucket will be created as bp->port is not set.
      
      sctp's autobind is supposed to call sctp_autobind() where it does all
      things including setting bp->port. Since sctp_autobind() is called in
      sctp_sendmsg() if the sk is not yet bound, it should have skipped the
      auto bind.
      
      THis patch is to avoid calling inet_autobind() in inet_send_prepare()
      by changing sctp_prot .no_autobind with true, also remove the unused
      .get_port.
      
      Reported-by: syzbot+d44f7bbebdea49dbc84a@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63dfb793
    • Vinicius Costa Gomes's avatar
      sched: etf: Fix ordering of packets with same txtime · 28aa7c86
      Vinicius Costa Gomes authored
      When a application sends many packets with the same txtime, they may
      be transmitted out of order (different from the order in which they
      were enqueued).
      
      This happens because when inserting elements into the tree, when the
      txtime of two packets are the same, the new packet is inserted at the
      left side of the tree, causing the reordering. The only effect of this
      change should be that packets with the same txtime will be transmitted
      in the order they are enqueued.
      
      The application in question (the AVTP GStreamer plugin, still in
      development) is sending video traffic, in which each video frame have
      a single presentation time, the problem is that when packetizing,
      multiple packets end up with the same txtime.
      
      The receiving side was rejecting packets because they were being
      received out of order.
      
      Fixes: 25db26a9 ("net/sched: Introduce the ETF Qdisc")
      Reported-by: default avatarEderson de Souza <ederson.desouza@intel.com>
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28aa7c86
    • Eric Dumazet's avatar
      net: avoid potential infinite loop in tc_ctl_action() · 39f13ea2
      Eric Dumazet authored
      tc_ctl_action() has the ability to loop forever if tcf_action_add()
      returns -EAGAIN.
      
      This special case has been done in case a module needed to be loaded,
      but it turns out that tcf_add_notify() could also return -EAGAIN
      if the socket sk_rcvbuf limit is hit.
      
      We need to separate the two cases, and only loop for the module
      loading case.
      
      While we are at it, add a limit of 10 attempts since unbounded
      loops are always scary.
      
      syzbot repro was something like :
      
      socket(PF_NETLINK, SOCK_RAW|SOCK_NONBLOCK, NETLINK_ROUTE) = 3
      write(3, ..., 38) = 38
      setsockopt(3, SOL_SOCKET, SO_RCVBUF, [0], 4) = 0
      sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{..., 388}], msg_controllen=0, msg_flags=0x10}, ...)
      
      NMI backtrace for cpu 0
      CPU: 0 PID: 1054 Comm: khungtaskd Not tainted 5.4.0-rc1+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
       check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
       watchdog+0x9d0/0xef0 kernel/hung_task.c:289
       kthread+0x361/0x430 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 8859 Comm: syz-executor910 Not tainted 5.4.0-rc1+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:arch_local_save_flags arch/x86/include/asm/paravirt.h:751 [inline]
      RIP: 0010:lockdep_hardirqs_off+0x1df/0x2e0 kernel/locking/lockdep.c:3453
      Code: 5c 08 00 00 5b 41 5c 41 5d 5d c3 48 c7 c0 58 1d f3 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 d3 00 00 00 <48> 83 3d 21 9e 99 07 00 0f 84 b9 00 00 00 9c 58 0f 1f 44 00 00 f6
      RSP: 0018:ffff8880a6f3f1b8 EFLAGS: 00000046
      RAX: 1ffffffff11e63ab RBX: ffff88808c9c6080 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff88808c9c6914
      RBP: ffff8880a6f3f1d0 R08: ffff88808c9c6080 R09: fffffbfff16be5d1
      R10: fffffbfff16be5d0 R11: 0000000000000003 R12: ffffffff8746591f
      R13: ffff88808c9c6080 R14: ffffffff8746591f R15: 0000000000000003
      FS:  00000000011e4880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffff600400 CR3: 00000000a8920000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       trace_hardirqs_off+0x62/0x240 kernel/trace/trace_preemptirq.c:45
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
       _raw_spin_lock_irqsave+0x6f/0xcd kernel/locking/spinlock.c:159
       __wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122
       __wake_up+0xe/0x10 kernel/sched/wait.c:142
       netlink_unlock_table net/netlink/af_netlink.c:466 [inline]
       netlink_unlock_table net/netlink/af_netlink.c:463 [inline]
       netlink_broadcast_filtered+0x705/0xb80 net/netlink/af_netlink.c:1514
       netlink_broadcast+0x3a/0x50 net/netlink/af_netlink.c:1534
       rtnetlink_send+0xdd/0x110 net/core/rtnetlink.c:714
       tcf_add_notify net/sched/act_api.c:1343 [inline]
       tcf_action_add+0x243/0x370 net/sched/act_api.c:1362
       tc_ctl_action+0x3b5/0x4bc net/sched/act_api.c:1410
       rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5386
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5404
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:637 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:657
       ___sys_sendmsg+0x803/0x920 net/socket.c:2311
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2356
       __do_sys_sendmsg net/socket.c:2365 [inline]
       __se_sys_sendmsg net/socket.c:2363 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
       do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x440939
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: syzbot+cf0adbb9c28c8866c788@syzkaller.appspotmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39f13ea2
    • Nishad Kamdar's avatar
      net: dsa: sja1105: Use the correct style for SPDX License Identifier · b790b554
      Nishad Kamdar authored
      This patch corrects the SPDX License Identifier style
      in header files related to Distributed Switch Architecture
      drivers for NXP SJA1105 series Ethernet switch support.
      It uses an expilict block comment for the SPDX License
      Identifier.
      
      Changes made by using a script provided by Joe Perches here:
      https://lkml.org/lkml/2019/2/7/46.
      Suggested-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarNishad Kamdar <nishadkamdar@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b790b554
    • Eric Dumazet's avatar
      tcp: fix a possible lockdep splat in tcp_done() · cab209e5
      Eric Dumazet authored
      syzbot found that if __inet_inherit_port() returns an error,
      we call tcp_done() after inet_csk_prepare_forced_close(),
      meaning the socket lock is no longer held.
      
      We might fix this in a different way in net-next, but
      for 5.4 it seems safer to relax the lockdep check.
      
      Fixes: d983ea6f ("tcp: add rcu protection around tp->fastopen_rsk")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cab209e5
    • David S. Miller's avatar
      Merge branch 'Update-MT7629-to-support-PHYLINK-API' · c9b96eb6
      David S. Miller authored
      MarkLee says:
      
      ====================
      Update MT7629 to support PHYLINK API
      
      This patch set has two goals :
      	1. Fix mt7629 GMII mode issue after apply mediatek
      	   PHYLINK support patch.
      	2. Update mt7629 dts to reflect the latest dt-binding
      	   with PHYLINK support.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9b96eb6
    • MarkLee's avatar
      arm: dts: mediatek: Update mt7629 dts to reflect the latest dt-binding · 2618500d
      MarkLee authored
      * Removes mediatek,physpeed property from dtsi that is useless in PHYLINK
      * Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit.
      * Set gmac1 to gmii mode that connect to a internal gphy
      Signed-off-by: default avatarMarkLee <Mark-MC.Lee@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2618500d
    • MarkLee's avatar
      net: ethernet: mediatek: Fix MT7629 missing GMII mode support · 4e3eff5b
      MarkLee authored
      In the original design, mtk_phy_connect function will set ge_mode=1
      if phy-mode is GMII(PHY_INTERFACE_MODE_GMII) and then set the correct
      ge_mode to ETHSYS_SYSCFG0 register. This logic was broken after apply
      mediatek PHYLINK patch(Fixes tag), the new mtk_mac_config function will
      not set ge_mode=1 for GMII mode hence the final ETHSYS_SYSCFG0 setting
      will be incorrect for mt7629 GMII mode. This patch add the missing logic
      back to fix it.
      
      Fixes: b8fc9f30 ("net: ethernet: mediatek: Add basic PHYLINK support")
      Signed-off-by: default avatarMarkLee <Mark-MC.Lee@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e3eff5b
    • David S. Miller's avatar
      Merge branch 'mpls-push-pop-fix' · 8d045995
      David S. Miller authored
      Davide Caratti says:
      
      ====================
      net/sched: fix wrong behavior of MPLS push/pop action
      
      this series contains two fixes for TC 'act_mpls', that try to address
      two problems that can be observed configuring simple 'push' / 'pop'
      operations:
      - patch 1/2 avoids dropping non-MPLS packets that pass through the MPLS
        'pop' action.
      - patch 2/2 fixes corruption of the L2 header that occurs when 'push'
        or 'pop' actions are configured in TC egress path.
      
      v2: - change commit message in patch 1/2 to better describe that the
            patch impacts only TC, thanks to Simon Horman
          - fix missing documentation of 'mac_len' in patch 2/2
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d045995
    • Davide Caratti's avatar
      net/sched: fix corrupted L2 header with MPLS 'push' and 'pop' actions · fa4e0f88
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev eth0 clsact
       # tc filter add dev eth0 egress protocol ip matchall \
       > action mpls push protocol mpls_uc label 0x355aa bos 1
      
      causes corruption of all IP packets transmitted by eth0. On TC egress, we
      can't rely on the value of skb->mac_len, because it's 0 and a MPLS 'push'
      operation will result in an overwrite of the first 4 octets in the packet
      L2 header (e.g. the Destination Address if eth0 is an Ethernet); the same
      error pattern is present also in the MPLS 'pop' operation. Fix this error
      in act_mpls data plane, computing 'mac_len' as the difference between the
      network header and the mac header (when not at TC ingress), and use it in
      MPLS 'push'/'pop' core functions.
      
      v2: unbreak 'make htmldocs' because of missing documentation of 'mac_len'
          in skb_mpls_pop(), reported by kbuild test robot
      
      CC: Lorenzo Bianconi <lorenzo@kernel.org>
      Fixes: 2a2ea508 ("net: sched: add mpls manipulation actions to TC")
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa4e0f88
    • Davide Caratti's avatar
      net: avoid errors when trying to pop MLPS header on non-MPLS packets · dedc5a08
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev eth0 clsact
       # tc filter add dev eth0 egress matchall action mpls pop
      
      implicitly makes the kernel drop all packets transmitted by eth0, if they
      don't have a MPLS header. This behavior is uncommon: other encapsulations
      (like VLAN) just let the packet pass unmodified. Since the result of MPLS
      'pop' operation would be the same regardless of the presence / absence of
      MPLS header(s) in the original packet, we can let skb_mpls_pop() return 0
      when dealing with non-MPLS packets.
      
      For the OVS use-case, this is acceptable because __ovs_nla_copy_actions()
      already ensures that MPLS 'pop' operation only occurs with packets having
      an MPLS Ethernet type (and there are no other callers in current code, so
      the semantic change should be ok).
      
      v2: better documentation of use-cases for skb_mpls_pop(), thanks to Simon
          Horman
      
      Fixes: 2a2ea508 ("net: sched: add mpls manipulation actions to TC")
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dedc5a08
  4. 15 Oct, 2019 2 commits