1. 19 Oct, 2019 5 commits
  2. 18 Oct, 2019 12 commits
  3. 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
  4. 16 Oct, 2019 12 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