1. 07 May, 2020 15 commits
    • David S. Miller's avatar
      Merge branch 'wireguard-fixes' · d3f3e6ac
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard fixes for 5.7-rc5
      
      With Ubuntu and Debian having backported this into their kernels, we're
      finally seeing testing from places we hadn't seen prior, which is nice.
      With that comes more fixes:
      
      1) The CI for PPC64 was running with extremely small stacks for 64-bit,
         causing spurious crashes in surprising places.
      
      2) There's was an old leftover routing loop restriction, which no longer
         makes sense given the queueing architecture, and was causing problems
         for people who really did want nested routing.
      
      3) Not yielding our kthread on CONFIG_PREEMPT_VOLUNTARY systems caused
         RCU stalls and other issues, reported by Wang Jian, with the fix
         suggested by Sultan Alsawaf.
      
      4) Clang spewed warnings in a selftest for CONFIG_IPV6=n, reported by
         Arnd Bergmann.
      
      5) A complicated if statement was simplified to an assignment while also
         making the likely/unlikely hinting more correct and simple, and
         increasing readability, suggested by Sultan.
      
      Patches (2) and (3) have Fixes: lines and are probably good candidates
      for stable.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3f3e6ac
    • Jason A. Donenfeld's avatar
      wireguard: send/receive: use explicit unlikely branch instead of implicit coalescing · 243f2148
      Jason A. Donenfeld authored
      It's very unlikely that send will become true. It's nearly always false
      between 0 and 120 seconds of a session, and in most cases becomes true
      only between 120 and 121 seconds before becoming false again. So,
      unlikely(send) is clearly the right option here.
      
      What happened before was that we had this complex boolean expression
      with multiple likely and unlikely clauses nested. Since this is
      evaluated left-to-right anyway, the whole thing got converted to
      unlikely. So, we can clean this up to better represent what's going on.
      
      The generated code is the same.
      Suggested-by: default avatarSultan Alsawaf <sultan@kerneltoast.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      243f2148
    • Jason A. Donenfeld's avatar
      wireguard: selftests: initalize ipv6 members to NULL to squelch clang warning · 4fed818e
      Jason A. Donenfeld authored
      Without setting these to NULL, clang complains in certain
      configurations that have CONFIG_IPV6=n:
      
      In file included from drivers/net/wireguard/ratelimiter.c:223:
      drivers/net/wireguard/selftest/ratelimiter.c:173:34: error: variable 'skb6' is uninitialized when used here [-Werror,-Wuninitialized]
                      ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count);
                                                     ^~~~
      drivers/net/wireguard/selftest/ratelimiter.c:123:29: note: initialize the variable 'skb6' to silence this warning
              struct sk_buff *skb4, *skb6;
                                         ^
                                          = NULL
      drivers/net/wireguard/selftest/ratelimiter.c:173:40: error: variable 'hdr6' is uninitialized when used here [-Werror,-Wuninitialized]
                      ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count);
                                                           ^~~~
      drivers/net/wireguard/selftest/ratelimiter.c:125:22: note: initialize the variable 'hdr6' to silence this warning
              struct ipv6hdr *hdr6;
                                  ^
      
      We silence this warning by setting the variables to NULL as the warning
      suggests.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fed818e
    • Jason A. Donenfeld's avatar
      wireguard: send/receive: cond_resched() when processing worker ringbuffers · 4005f5c3
      Jason A. Donenfeld authored
      Users with pathological hardware reported CPU stalls on CONFIG_
      PREEMPT_VOLUNTARY=y, because the ringbuffers would stay full, meaning
      these workers would never terminate. That turned out not to be okay on
      systems without forced preemption, which Sultan observed. This commit
      adds a cond_resched() to the bottom of each loop iteration, so that
      these workers don't hog the core. Note that we don't need this on the
      napi poll worker, since that terminates after its budget is expended.
      Suggested-by: default avatarSultan Alsawaf <sultan@kerneltoast.com>
      Reported-by: default avatarWang Jian <larkwang@gmail.com>
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4005f5c3
    • Jason A. Donenfeld's avatar
      wireguard: socket: remove errant restriction on looping to self · b673e24a
      Jason A. Donenfeld authored
      It's already possible to create two different interfaces and loop
      packets between them. This has always been possible with tunnels in the
      kernel, and isn't specific to wireguard. Therefore, the networking stack
      already needs to deal with that. At the very least, the packet winds up
      exceeding the MTU and is discarded at that point. So, since this is
      already something that happens, there's no need to forbid the not very
      exceptional case of routing a packet back to the same interface; this
      loop is no different than others, and we shouldn't special case it, but
      rather rely on generic handling of loops in general. This also makes it
      easier to do interesting things with wireguard such as onion routing.
      
      At the same time, we add a selftest for this, ensuring that both onion
      routing works and infinite routing loops do not crash the kernel. We
      also add a test case for wireguard interfaces nesting packets and
      sending traffic between each other, as well as the loop in this case
      too. We make sure to send some throughput-heavy traffic for this use
      case, to stress out any possible recursion issues with the locks around
      workqueues.
      
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b673e24a
    • Jason A. Donenfeld's avatar
      wireguard: selftests: use normal kernel stack size on ppc64 · a0fd7cc8
      Jason A. Donenfeld authored
      While at some point it might have made sense to be running these tests
      on ppc64 with 4k stacks, the kernel hasn't actually used 4k stacks on
      64-bit powerpc in a long time, and more interesting things that we test
      don't really work when we deviate from the default (16k). So, we stop
      pushing our luck in this commit, and return to the default instead of
      the minimum.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0fd7cc8
    • Grygorii Strashko's avatar
      net: ethernet: ti: am65-cpsw-nuss: fix irqs type · 6f5c27f9
      Grygorii Strashko authored
      The K3 INTA driver, which is source TX/RX IRQs for CPSW NUSS, defines IRQs
      triggering type as EDGE by default, but triggering type for CPSW NUSS TX/RX
      IRQs has to be LEVEL as the EDGE triggering type may cause unnecessary IRQs
      triggering and NAPI scheduling for empty queues. It was discovered with
      RT-kernel.
      
      Fix it by explicitly specifying CPSW NUSS TX/RX IRQ type as
      IRQF_TRIGGER_HIGH.
      
      Fixes: 93a76530 ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f5c27f9
    • Geert Uytterhoeven's avatar
      ionic: Use debugfs_create_bool() to export bool · 0735ccc9
      Geert Uytterhoeven authored
      Currently bool ionic_cq.done_color is exported using
      debugfs_create_u8(), which requires a cast, preventing further compiler
      checks.
      
      Fix this by switching to debugfs_create_bool(), and dropping the cast.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0735ccc9
    • Florian Fainelli's avatar
      net: dsa: Do not leave DSA master with NULL netdev_ops · 050569fc
      Florian Fainelli authored
      When ndo_get_phys_port_name() for the CPU port was added we introduced
      an early check for when the DSA master network device in
      dsa_master_ndo_setup() already implements ndo_get_phys_port_name(). When
      we perform the teardown operation in dsa_master_ndo_teardown() we would
      not be checking that cpu_dp->orig_ndo_ops was successfully allocated and
      non-NULL initialized.
      
      With network device drivers such as virtio_net, this leads to a NPD as
      soon as the DSA switch hanging off of it gets torn down because we are
      now assigning the virtio_net device's netdev_ops a NULL pointer.
      
      Fixes: da7b9e9b ("net: dsa: Add ndo_get_phys_port_name() for CPU port")
      Reported-by: default avatarAllen Pais <allen.pais@oracle.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarAllen Pais <allen.pais@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      050569fc
    • Vladimir Oltean's avatar
      net: dsa: remove duplicate assignment in dsa_slave_add_cls_matchall_mirred · 65722159
      Vladimir Oltean authored
      This was caused by a poor merge conflict resolution on my side. The
      "act = &cls->rule->action.entries[0];" assignment was already present in
      the code prior to the patch mentioned below.
      
      Fixes: e13c2075 ("net: dsa: refactor matchall mirred action to separate function")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65722159
    • Willem de Bruijn's avatar
      net: stricter validation of untrusted gso packets · 9274124f
      Willem de Bruijn authored
      Syzkaller again found a path to a kernel crash through bad gso input:
      a packet with transport header extending beyond skb_headlen(skb).
      
      Tighten validation at kernel entry:
      
      - Verify that the transport header lies within the linear section.
      
          To avoid pulling linux/tcp.h, verify just sizeof tcphdr.
          tcp_gso_segment will call pskb_may_pull (th->doff * 4) before use.
      
      - Match the gso_type against the ip_proto found by the flow dissector.
      
      Fixes: bfd5f4a3 ("packet: Add GSO/csum offload support.")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9274124f
    • Ahmed Abdelsalam's avatar
      seg6: fix SRH processing to comply with RFC8754 · 0cb7498f
      Ahmed Abdelsalam authored
      The Segment Routing Header (SRH) which defines the SRv6 dataplane is defined
      in RFC8754.
      
      RFC8754 (section 4.1) defines the SR source node behavior which encapsulates
      packets into an outer IPv6 header and SRH. The SR source node encodes the
      full list of Segments that defines the packet path in the SRH. Then, the
      first segment from list of Segments is copied into the Destination address
      of the outer IPv6 header and the packet is sent to the first hop in its path
      towards the destination.
      
      If the Segment list has only one segment, the SR source node can omit the SRH
      as he only segment is added in the destination address.
      
      RFC8754 (section 4.1.1) defines the Reduced SRH, when a source does not
      require the entire SID list to be preserved in the SRH. A reduced SRH does
      not contain the first segment of the related SR Policy (the first segment is
      the one already in the DA of the IPv6 header), and the Last Entry field is
      set to n-2, where n is the number of elements in the SR Policy.
      
      RFC8754 (section 4.3.1.1) defines the SRH processing and the logic to
      validate the SRH (S09, S10, S11) which works for both reduced and
      non-reduced behaviors.
      
      This patch updates seg6_validate_srh() to validate the SRH as per RFC8754.
      Signed-off-by: default avatarAhmed Abdelsalam <ahabdels@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0cb7498f
    • David S. Miller's avatar
      Merge branch 'FDB-fixes-for-Felix-and-Ocelot-switches' · 6e0ddb65
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      FDB fixes for Felix and Ocelot switches
      
      This series fixes the following problems:
      - Dynamically learnt addresses never expiring (neither for Ocelot nor
        for Felix)
      - Half of the FDB not visible in 'bridge fdb show' (for Felix only)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e0ddb65
    • Vladimir Oltean's avatar
      net: mscc: ocelot: ANA_AUTOAGE_AGE_PERIOD holds a value in seconds, not ms · c0d7eccb
      Vladimir Oltean authored
      One may notice that automatically-learnt entries 'never' expire, even
      though the bridge configures the address age period at 300 seconds.
      
      Actually the value written to hardware corresponds to a time interval
      1000 times higher than intended, i.e. 83 hours.
      
      Fixes: a556c76a ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Faineli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0d7eccb
    • Vladimir Oltean's avatar
      net: dsa: ocelot: the MAC table on Felix is twice as large · 21ce7f3e
      Vladimir Oltean authored
      When running 'bridge fdb dump' on Felix, sometimes learnt and static MAC
      addresses would appear, sometimes they wouldn't.
      
      Turns out, the MAC table has 4096 entries on VSC7514 (Ocelot) and 8192
      entries on VSC9959 (Felix), so the existing code from the Ocelot common
      library only dumped half of Felix's MAC table. They are both organized
      as a 4-way set-associative TCAM, so we just need a single variable
      indicating the correct number of rows.
      
      Fixes: 56051948 ("net: dsa: ocelot: add driver for Felix switch family")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21ce7f3e
  2. 06 May, 2020 7 commits
  3. 05 May, 2020 2 commits
  4. 04 May, 2020 13 commits
    • Qiushi Wu's avatar
      nfp: abm: fix a memory leak bug · bd4af432
      Qiushi Wu authored
      In function nfp_abm_vnic_set_mac, pointer nsp is allocated by nfp_nsp_open.
      But when nfp_nsp_has_hwinfo_lookup fail, the pointer is not released,
      which can lead to a memory leak bug. Fix this issue by adding
      nfp_nsp_close(nsp) in the error path.
      
      Fixes: f6e71efd ("nfp: abm: look up MAC addresses via management FW")
      Signed-off-by: default avatarQiushi Wu <wu000273@umn.edu>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd4af432
    • Cong Wang's avatar
      atm: fix a memory leak of vcc->user_back · 8d9f73c0
      Cong Wang authored
      In lec_arp_clear_vccs() only entry->vcc is freed, but vcc
      could be installed on entry->recv_vcc too in lec_vcc_added().
      
      This fixes the following memory leak:
      
      unreferenced object 0xffff8880d9266b90 (size 16):
        comm "atm2", pid 425, jiffies 4294907980 (age 23.488s)
        hex dump (first 16 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 6b 6b 6b a5  ............kkk.
        backtrace:
          [<(____ptrval____)>] kmem_cache_alloc_trace+0x10e/0x151
          [<(____ptrval____)>] lane_ioctl+0x4b3/0x569
          [<(____ptrval____)>] do_vcc_ioctl+0x1ea/0x236
          [<(____ptrval____)>] svc_ioctl+0x17d/0x198
          [<(____ptrval____)>] sock_do_ioctl+0x47/0x12f
          [<(____ptrval____)>] sock_ioctl+0x2f9/0x322
          [<(____ptrval____)>] vfs_ioctl+0x1e/0x2b
          [<(____ptrval____)>] ksys_ioctl+0x61/0x80
          [<(____ptrval____)>] __x64_sys_ioctl+0x16/0x19
          [<(____ptrval____)>] do_syscall_64+0x57/0x65
          [<(____ptrval____)>] entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Cc: Gengming Liu <l.dmxcsnsbh@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d9f73c0
    • Cong Wang's avatar
      atm: fix a UAF in lec_arp_clear_vccs() · 93a2014a
      Cong Wang authored
      Gengming reported a UAF in lec_arp_clear_vccs(),
      where we add a vcc socket to an entry in a per-device
      list but free the socket without removing it from the
      list when vcc->dev is NULL.
      
      We need to call lec_vcc_close() to search and remove
      those entries contain the vcc being destroyed. This can
      be done by calling vcc->push(vcc, NULL) unconditionally
      in vcc_destroy_socket().
      
      Another issue discovered by Gengming's reproducer is
      the vcc->dev may point to the static device lecatm_dev,
      for which we don't need to register/unregister device,
      so we can just check for vcc->dev->ops->owner.
      Reported-by: default avatarGengming Liu <l.dmxcsnsbh@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93a2014a
    • Colin Ian King's avatar
      net: stmmac: gmac5+: fix potential integer overflow on 32 bit multiply · 44d95cc6
      Colin Ian King authored
      The multiplication of cfg->ctr[1] by 1000000000 is performed using a
      32 bit multiplication (since cfg->ctr[1] is a u32) and this can lead
      to a potential overflow. Fix this by making the constant a ULL to
      ensure a 64 bit multiply occurs.
      
      Fixes: 504723af ("net: stmmac: Add basic EST support for GMAC5+")
      Addresses-Coverity: ("Unintentional integer overflow")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44d95cc6
    • Cong Wang's avatar
      net_sched: fix tcm_parent in tc filter dump · a7df4870
      Cong Wang authored
      When we tell kernel to dump filters from root (ffff:ffff),
      those filters on ingress (ffff:0000) are matched, but their
      true parents must be dumped as they are. However, kernel
      dumps just whatever we tell it, that is either ffff:ffff
      or ffff:0000:
      
       $ nl-cls-list --dev=dummy0 --parent=root
       cls basic dev dummy0 id none parent root prio 49152 protocol ip match-all
       cls basic dev dummy0 id :1 parent root prio 49152 protocol ip match-all
       $ nl-cls-list --dev=dummy0 --parent=ffff:
       cls basic dev dummy0 id none parent ffff: prio 49152 protocol ip match-all
       cls basic dev dummy0 id :1 parent ffff: prio 49152 protocol ip match-all
      
      This is confusing and misleading, more importantly this is
      a regression since 4.15, so the old behavior must be restored.
      
      And, when tc filters are installed on a tc class, the parent
      should be the classid, rather than the qdisc handle. Commit
      edf6711c ("net: sched: remove classid and q fields from tcf_proto")
      removed the classid we save for filters, we can just restore
      this classid in tcf_block.
      
      Steps to reproduce this:
       ip li set dev dummy0 up
       tc qd add dev dummy0 ingress
       tc filter add dev dummy0 parent ffff: protocol arp basic action pass
       tc filter show dev dummy0 root
      
      Before this patch:
       filter protocol arp pref 49152 basic
       filter protocol arp pref 49152 basic handle 0x1
      	action order 1: gact action pass
      	 random type none pass val 0
      	 index 1 ref 1 bind 1
      
      After this patch:
       filter parent ffff: protocol arp pref 49152 basic
       filter parent ffff: protocol arp pref 49152 basic handle 0x1
       	action order 1: gact action pass
       	 random type none pass val 0
      	 index 1 ref 1 bind 1
      
      Fixes: a10fa201 ("net: sched: propagate q and parent from caller down to tcf_fill_node")
      Fixes: edf6711c ("net: sched: remove classid and q fields from tcf_proto")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7df4870
    • Arnd Bergmann's avatar
      cxgb4/chcr: avoid -Wreturn-local-addr warning · 071a43e6
      Arnd Bergmann authored
      gcc-10 warns about functions that return a pointer to a stack
      variable. In chcr_write_cpl_set_tcb_ulp(), this does not actually
      happen, but it's too hard to see for the compiler:
      
      drivers/crypto/chelsio/chcr_ktls.c: In function 'chcr_write_cpl_set_tcb_ulp.constprop':
      drivers/crypto/chelsio/chcr_ktls.c:760:9: error: function may return address of local variable [-Werror=return-local-addr]
        760 |  return pos;
            |         ^~~
      drivers/crypto/chelsio/chcr_ktls.c:712:5: note: declared here
        712 |  u8 buf[48] = {0};
            |     ^~~
      
      Split the middle part of the function out into a helper to make
      it easier to understand by both humans and compilers, which avoids
      the warning.
      
      Fixes: 5a4b9fe7 ("cxgb4/chcr: complete record tx handling")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      071a43e6
    • Julian Wiedmann's avatar
      s390/qeth: fix cancelling of TX timer on dev_close() · c649c41d
      Julian Wiedmann authored
      With the introduction of TX coalescing, .ndo_start_xmit now potentially
      starts the TX completion timer. So only kill the timer _after_ TX has
      been disabled.
      
      Fixes: ee1e52d1 ("s390/qeth: add TX IRQ coalescing support for IQD devices")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c649c41d
    • Dejin Zheng's avatar
      net: enetc: fix an issue about leak system resources · d975cb7e
      Dejin Zheng authored
      the related system resources were not released when enetc_hw_alloc()
      return error in the enetc_pci_mdio_probe(), add iounmap() for error
      handling label "err_hw_alloc" to fix it.
      
      Fixes: 6517798d ("enetc: Make MDIO accessors more generic and export to include/linux/fsl")
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarDejin Zheng <zhengdejin5@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d975cb7e
    • Tariq Toukan's avatar
      net/mlx4_core: Fix use of ENOSPC around mlx4_counter_alloc() · 40e47307
      Tariq Toukan authored
      When ENOSPC is set the idx is still valid and gets set to the global
      MLX4_SINK_COUNTER_INDEX.  However gcc's static analysis cannot tell that
      ENOSPC is impossible from mlx4_cmd_imm() and gives this warning:
      
      drivers/net/ethernet/mellanox/mlx4/main.c:2552:28: warning: 'idx' may be
      used uninitialized in this function [-Wmaybe-uninitialized]
       2552 |    priv->def_counter[port] = idx;
      
      Also, when ENOSPC is returned mlx4_allocate_default_counters should not
      fail.
      
      Fixes: 6de5f7f6 ("net/mlx4_core: Allocate default counter per port")
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40e47307
    • Aya Levin's avatar
      devlink: Fix reporter's recovery condition · bea0c5c9
      Aya Levin authored
      Devlink health core conditions the reporter's recovery with the
      expiration of the grace period. This is not relevant for the first
      recovery. Explicitly demand that the grace period will only apply to
      recoveries other than the first.
      
      Fixes: c8e1da0b ("devlink: Add health report functionality")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bea0c5c9
    • Maxim Petrov's avatar
      stmmac: fix pointer check after utilization in stmmac_interrupt · f42234ff
      Maxim Petrov authored
      The paranoidal pointer check in IRQ handler looks very strange - it
      really protects us only against bogus drivers which request IRQ line
      with null pointer dev_id. However, the code fragment is incorrect
      because the dev pointer is used before the actual check which leads
      to undefined behavior. Remove the check to avoid confusing people
      with incorrect code.
      Signed-off-by: default avatarMaxim Petrov <mmrmaximuzz@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f42234ff
    • Tuong Lien's avatar
      tipc: fix partial topology connection closure · 980d6927
      Tuong Lien authored
      When an application connects to the TIPC topology server and subscribes
      to some services, a new connection is created along with some objects -
      'tipc_subscription' to store related data correspondingly...
      However, there is one omission in the connection handling that when the
      connection or application is orderly shutdown (e.g. via SIGQUIT, etc.),
      the connection is not closed in kernel, the 'tipc_subscription' objects
      are not freed too.
      This results in:
      - The maximum number of subscriptions (65535) will be reached soon, new
      subscriptions will be rejected;
      - TIPC module cannot be removed (unless the objects  are somehow forced
      to release first);
      
      The commit fixes the issue by closing the connection if the 'recvmsg()'
      returns '0' i.e. when the peer is shutdown gracefully. It also includes
      the other unexpected cases.
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      980d6927
    • Florian Fainelli's avatar
      net: dsa: Do not make user port errors fatal · 86f8b1c0
      Florian Fainelli authored
      Prior to 1d27732f ("net: dsa: setup and teardown ports"), we would
      not treat failures to set-up an user port as fatal, but after this
      commit we would, which is a regression for some systems where interfaces
      may be declared in the Device Tree, but the underlying hardware may not
      be present (pluggable daughter cards for instance).
      
      Fixes: 1d27732f ("net: dsa: setup and teardown ports")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86f8b1c0
  5. 03 May, 2020 3 commits