1. 19 Nov, 2019 21 commits
  2. 17 Nov, 2019 5 commits
  3. 16 Nov, 2019 14 commits
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5ffaf037
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Misc fixes: a handful of AUX event handling related fixes, a Sparse
        fix and two ABI fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/core: Fix missing static inline on perf_cgroup_switch()
        perf/core: Consistently fail fork on allocation failures
        perf/aux: Disallow aux_output for kernel events
        perf/core: Reattach a misplaced comment
        perf/aux: Fix the aux_output group inheritance fix
        perf/core: Disallow uncore-cgroup events
      5ffaf037
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 8be636dd
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix memory leak in xfrm_state code, from Steffen Klassert.
      
       2) Fix races between devlink reload operations and device
          setup/cleanup, from Jiri Pirko.
      
       3) Null deref in NFC code, from Stephan Gerhold.
      
       4) Refcount fixes in SMC, from Ursula Braun.
      
       5) Memory leak in slcan open error paths, from Jouni Hogander.
      
       6) Fix ETS bandwidth validation in hns3, from Yonglong Liu.
      
       7) Info leak on short USB request answers in ax88172a driver, from
          Oliver Neukum.
      
       8) Release mem region properly in ep93xx_eth, from Chuhong Yuan.
      
       9) PTP config timestamp flags validation, from Richard Cochran.
      
      10) Dangling pointers after SKB data realloc in seg6, from Andrea Mayer.
      
      11) Missing free_netdev() in gemini driver, from Chuhong Yuan.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (56 commits)
        ipmr: Fix skb headroom in ipmr_get_route().
        net: hns3: cleanup of stray struct hns3_link_mode_mapping
        net/smc: fix fastopen for non-blocking connect()
        rds: ib: update WR sizes when bringing up connection
        net: gemini: add missed free_netdev
        net: dsa: tag_8021q: Fix dsa_8021q_restore_pvid for an absent pvid
        seg6: fix skb transport_header after decap_and_validate()
        seg6: fix srh pointer in get_srh()
        net: stmmac: Use the correct style for SPDX License Identifier
        octeontx2-af: Use the correct style for SPDX License Identifier
        ptp: Extend the test program to check the external time stamp flags.
        mlx5: Reject requests to enable time stamping on both edges.
        igb: Reject requests that fail to enable time stamping on both edges.
        dp83640: Reject requests to enable time stamping on both edges.
        mv88e6xxx: Reject requests to enable time stamping on both edges.
        ptp: Introduce strict checking of external time stamp options.
        renesas: reject unsupported external timestamp flags
        mlx5: reject unsupported external timestamp flags
        igb: reject unsupported external timestamp flags
        dp83640: reject unsupported external timestamp flags
        ...
      8be636dd
    • kbuild test robot's avatar
      mscc.c: fix semicolon.cocci warnings · 1e8795b1
      kbuild test robot authored
      drivers/net/phy/mscc.c:1683:3-4: Unneeded semicolon
      
       Remove unneeded semicolon.
      
      Generated by: scripts/coccinelle/misc/semicolon.cocci
      
      Fixes: 75a1ccfe ("mscc.c: Add support for additional VSC PHYs")
      CC: Bryan Whitehead <Bryan.Whitehead@microchip.com>
      Signed-off-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e8795b1
    • Eric Dumazet's avatar
      selftests: net: avoid ptl lock contention in tcp_mmap · 597b01ed
      Eric Dumazet authored
      tcp_mmap is used as a reference program for TCP rx zerocopy,
      so it is important to point out some potential issues.
      
      If multiple threads are concurrently using getsockopt(...
      TCP_ZEROCOPY_RECEIVE), there is a chance the low-level mm
      functions compete on shared ptl lock, if vma are arbitrary placed.
      
      Instead of letting the mm layer place the chunks back to back,
      this patch enforces an alignment so that each thread uses
      a different ptl lock.
      
      Performance measured on a 100 Gbit NIC, with 8 tcp_mmap clients
      launched at the same time :
      
      $ for f in {1..8}; do ./tcp_mmap -H 2002:a05:6608:290:: & done
      
      In the following run, we reproduce the old behavior by requesting no alignment :
      
      $ tcp_mmap -sz -C $((128*1024)) -a 4096
      received 32768 MB (100 % mmap'ed) in 9.69532 s, 28.3516 Gbit
        cpu usage user:0.08634 sys:3.86258, 120.511 usec per MB, 171839 c-switches
      received 32768 MB (100 % mmap'ed) in 25.4719 s, 10.7914 Gbit
        cpu usage user:0.055268 sys:21.5633, 659.745 usec per MB, 9065 c-switches
      received 32768 MB (100 % mmap'ed) in 28.5419 s, 9.63069 Gbit
        cpu usage user:0.057401 sys:23.8761, 730.392 usec per MB, 14987 c-switches
      received 32768 MB (100 % mmap'ed) in 28.655 s, 9.59268 Gbit
        cpu usage user:0.059689 sys:23.8087, 728.406 usec per MB, 18509 c-switches
      received 32768 MB (100 % mmap'ed) in 28.7808 s, 9.55074 Gbit
        cpu usage user:0.066042 sys:23.4632, 718.056 usec per MB, 24702 c-switches
      received 32768 MB (100 % mmap'ed) in 28.8259 s, 9.5358 Gbit
        cpu usage user:0.056547 sys:23.6628, 723.858 usec per MB, 23518 c-switches
      received 32768 MB (100 % mmap'ed) in 28.8808 s, 9.51767 Gbit
        cpu usage user:0.059357 sys:23.8515, 729.703 usec per MB, 14691 c-switches
      received 32768 MB (100 % mmap'ed) in 28.8879 s, 9.51534 Gbit
        cpu usage user:0.047115 sys:23.7349, 725.769 usec per MB, 21773 c-switches
      
      New behavior (automatic alignment based on Hugepagesize),
      we can see the system overhead being dramatically reduced.
      
      $ tcp_mmap -sz -C $((128*1024))
      received 32768 MB (100 % mmap'ed) in 13.5339 s, 20.3103 Gbit
        cpu usage user:0.122644 sys:3.4125, 107.884 usec per MB, 168567 c-switches
      received 32768 MB (100 % mmap'ed) in 16.0335 s, 17.1439 Gbit
        cpu usage user:0.132428 sys:3.55752, 112.608 usec per MB, 188557 c-switches
      received 32768 MB (100 % mmap'ed) in 17.5506 s, 15.6621 Gbit
        cpu usage user:0.155405 sys:3.24889, 103.891 usec per MB, 226652 c-switches
      received 32768 MB (100 % mmap'ed) in 19.1924 s, 14.3222 Gbit
        cpu usage user:0.135352 sys:3.35583, 106.542 usec per MB, 207404 c-switches
      received 32768 MB (100 % mmap'ed) in 22.3649 s, 12.2906 Gbit
        cpu usage user:0.142429 sys:3.53187, 112.131 usec per MB, 250225 c-switches
      received 32768 MB (100 % mmap'ed) in 22.5336 s, 12.1986 Gbit
        cpu usage user:0.140654 sys:3.61971, 114.757 usec per MB, 253754 c-switches
      received 32768 MB (100 % mmap'ed) in 22.5483 s, 12.1906 Gbit
        cpu usage user:0.134035 sys:3.55952, 112.718 usec per MB, 252997 c-switches
      received 32768 MB (100 % mmap'ed) in 22.6442 s, 12.139 Gbit
        cpu usage user:0.126173 sys:3.71251, 117.147 usec per MB, 253728 c-switches
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Cc: Arjun Roy <arjunroy@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      597b01ed
    • Heiner Kallweit's avatar
      r8169: load firmware for RTL8168fp/RTL8117 · 229c1e0d
      Heiner Kallweit authored
      Load Realtek-provided firmware for RTL8168fp/RTL8117. Unlike the
      firmware for other chip versions which is for the PHY, firmware for
      RTL8168fp/RTL8117 is for the MAC.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      229c1e0d
    • Heiner Kallweit's avatar
      r8169: improve conditional firmware loading for RTL8168d · 718af5bc
      Heiner Kallweit authored
      Using constant MII_EXPANSION is misleading here because register 0x06
      has a different meaning on page 0x0005. Here a proprietary PHY
      parameter is read by writing the parameter id to register 0x05 on page
      0x0005, followed by reading the parameter value from register 0x06.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      718af5bc
    • Russell King's avatar
      net: phylink: update to use phy_support_asym_pause() · 725ea4bf
      Russell King authored
      Use phy_support_asym_pause() rather than open-coding it.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      725ea4bf
    • Guillaume Nault's avatar
      ipmr: Fix skb headroom in ipmr_get_route(). · 7901cd97
      Guillaume Nault authored
      In route.c, inet_rtm_getroute_build_skb() creates an skb with no
      headroom. This skb is then used by inet_rtm_getroute() which may pass
      it to rt_fill_info() and, from there, to ipmr_get_route(). The later
      might try to reuse this skb by cloning it and prepending an IPv4
      header. But since the original skb has no headroom, skb_push() triggers
      skb_under_panic():
      
      skbuff: skb_under_panic: text:00000000ca46ad8a len:80 put:20 head:00000000cd28494e data:000000009366fd6b tail:0x3c end:0xec0 dev:veth0
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:108!
      invalid opcode: 0000 [#1] SMP KASAN PTI
      CPU: 6 PID: 587 Comm: ip Not tainted 5.4.0-rc6+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
      RIP: 0010:skb_panic+0xbf/0xd0
      Code: 41 a2 ff 8b 4b 70 4c 8b 4d d0 48 c7 c7 20 76 f5 8b 44 8b 45 bc 48 8b 55 c0 48 8b 75 c8 41 54 41 57 41 56 41 55 e8 75 dc 7a ff <0f> 0b 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
      RSP: 0018:ffff888059ddf0b0 EFLAGS: 00010286
      RAX: 0000000000000086 RBX: ffff888060a315c0 RCX: ffffffff8abe4822
      RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88806c9a79cc
      RBP: ffff888059ddf118 R08: ffffed100d9361b1 R09: ffffed100d9361b0
      R10: ffff88805c68aee3 R11: ffffed100d9361b1 R12: ffff88805d218000
      R13: ffff88805c689fec R14: 000000000000003c R15: 0000000000000ec0
      FS:  00007f6af184b700(0000) GS:ffff88806c980000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffc8204a000 CR3: 0000000057b40006 CR4: 0000000000360ee0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       skb_push+0x7e/0x80
       ipmr_get_route+0x459/0x6fa
       rt_fill_info+0x692/0x9f0
       inet_rtm_getroute+0xd26/0xf20
       rtnetlink_rcv_msg+0x45d/0x630
       netlink_rcv_skb+0x1a5/0x220
       rtnetlink_rcv+0x15/0x20
       netlink_unicast+0x305/0x3a0
       netlink_sendmsg+0x575/0x730
       sock_sendmsg+0xb5/0xc0
       ___sys_sendmsg+0x497/0x4f0
       __sys_sendmsg+0xcb/0x150
       __x64_sys_sendmsg+0x48/0x50
       do_syscall_64+0xd2/0xac0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Actually the original skb used to have enough headroom, but the
      reserve_skb() call was lost with the introduction of
      inet_rtm_getroute_build_skb() by commit 404eb77e ("ipv4: support
      sport, dport and ip_proto in RTM_GETROUTE").
      
      We could reserve some headroom again in inet_rtm_getroute_build_skb(),
      but this function shouldn't be responsible for handling the special
      case of ipmr_get_route(). Let's handle that directly in
      ipmr_get_route() by calling skb_realloc_headroom() instead of
      skb_clone().
      
      Fixes: 404eb77e ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7901cd97
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-2019-11-15' of... · 50bef719
      David S. Miller authored
      Merge tag 'wireless-drivers-next-2019-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for v5.5
      
      Second set of patches for v5.5. Nothing special this time, smaller
      features to various drivers and of course fixes all over.
      
      Major changes:
      
      iwlwifi
      
      * update scan FW API
      
      * bump the supported FW API version
      
      * add debug dump collection on assert in WoWLAN
      
      * enable adaptive dwell on P2P interfaces
      
      ath10k
      
      * request for PM_QOS_CPU_DMA_LATENCY to improve firmware initialisation time
      
      qtnfmac
      
      * add support for getting/setting transmit power
      
      * handle MIC failure event from firmware
      
      rtl8xxxu
      
      * add support for Edimax EW-7611ULB
      
      wil6210
      
      * add SPDX license identifiers
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      50bef719
    • Salil Mehta's avatar
      net: hns3: cleanup of stray struct hns3_link_mode_mapping · b696083d
      Salil Mehta authored
      This patch cleans-up the stray left over code. It has no
      functionality impact.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b696083d
    • Ursula Braun's avatar
      net/smc: fix fastopen for non-blocking connect() · 8204df72
      Ursula Braun authored
      FASTOPEN does not work with SMC-sockets. Since SMC allows fallback to
      TCP native during connection start, the FASTOPEN setsockopts trigger
      this fallback, if the SMC-socket is still in state SMC_INIT.
      But if a FASTOPEN setsockopt is called after a non-blocking connect(),
      this is broken, and fallback does not make sense.
      This change complements
      commit cd206360 ("net/smc: avoid fallback in case of non-blocking connect")
      and fixes the syzbot reported problem "WARNING in smc_unhash_sk".
      
      Reported-by: syzbot+8488cc4cf1c9e09b8b86@syzkaller.appspotmail.com
      Fixes: e1bbdd57 ("net/smc: reduce sock_put() for fallback sockets")
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8204df72
    • Matteo Croce's avatar
      bonding: symmetric ICMP transmit · df98be06
      Matteo Croce authored
      A bonding with layer2+3 or layer3+4 hashing uses the IP addresses and the ports
      to balance packets between slaves. With some network errors, we receive an ICMP
      error packet by the remote host or a router. If sent by a router, the source IP
      can differ from the remote host one. Additionally the ICMP protocol has no port
      numbers, so a layer3+4 bonding will get a different hash than the previous one.
      These two conditions could let the packet go through a different interface than
      the other packets of the same flow:
      
          # tcpdump -qltnni veth0 |sed 's/^/0: /' &
          # tcpdump -qltnni veth1 |sed 's/^/1: /' &
          # hping3 -2 192.168.0.2 -p 9
          0: IP 192.168.0.1.2251 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          1: IP 192.168.0.1.2252 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          1: IP 192.168.0.1.2253 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          0: IP 192.168.0.1.2254 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
      
      An ICMP error packet contains the header of the packet which caused the network
      error, so inspect it and match the flow against it, so we can send the ICMP via
      the same interface of the previous packet in the flow.
      Move the IP and port dissect code into a generic function bond_flow_ip() and if
      we are dissecting an ICMP error packet, call it again with the adjusted offset.
      
          # hping3 -2 192.168.0.2 -p 9
          1: IP 192.168.0.1.1224 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          1: IP 192.168.0.1.1225 > 192.168.0.2.9: UDP, length 0
          1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          0: IP 192.168.0.1.1226 > 192.168.0.2.9: UDP, length 0
          0: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
          0: IP 192.168.0.1.1227 > 192.168.0.2.9: UDP, length 0
          0: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df98be06
    • Horatiu Vultur's avatar
      net: mscc: ocelot: omit error check from of_get_phy_mode · 4214fa1e
      Horatiu Vultur authored
      The commit 0c65b2b9 ("net: of_get_phy_mode: Change API to solve
      int/unit warnings") updated the function of_get_phy_mode declaration.
      Now it returns an error code and in case the node doesn't contain the
      property 'phy-mode' or 'phy-connection-type' it returns -EINVAL and would
      set the phy_interface_t to PHY_INTERFACE_MODE_NA.
      
      Ocelot VSC7514 has 4 internal phys which have the phy interface
      PHY_INTERFACE_MODE_NA. So because of_get_phy_mode would assign
      PHY_INTERFACE_MODE_NA to phy_mode when there is an error, there is no need
      to add the error check.
      
      Updates for v2:
       - drop error check because of_get_phy_mode already assigns phy_interface
         to PHY_INTERFACE_MODE in case of error.
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4214fa1e
    • Alexander Lobakin's avatar
      net: core: allow fast GRO for skbs with Ethernet header in head · 8aef998d
      Alexander Lobakin authored
      Commit 78d3fd0b ("gro: Only use skb_gro_header for completely
      non-linear packets") back in May'09 (v2.6.31-rc1) has changed the
      original condition '!skb_headlen(skb)' to
      'skb->mac_header == skb->tail' in gro_reset_offset() saying: "Since
      the drivers that need this optimisation all provide completely
      non-linear packets" (note that this condition has become the current
      'skb_mac_header(skb) == skb_tail_pointer(skb)' later with commmit
      ced14f68 ("net: Correct comparisons and calculations using
      skb->tail and skb-transport_header") without any functional changes).
      
      For now, we have the following rough statistics for v5.4-rc7:
      1) napi_gro_frags: 14
      2) napi_gro_receive with skb->head containing (most of) payload: 83
      3) napi_gro_receive with skb->head containing all the headers: 20
      4) napi_gro_receive with skb->head containing only Ethernet header: 2
      
      With the current condition, fast GRO with the usage of
      NAPI_GRO_CB(skb)->frag0 is available only in the [1] case.
      Packets pushed by [2] and [3] go through the 'slow' path, but
      it's not a problem for them as they already contain all the needed
      headers in skb->head, so pskb_may_pull() only moves skb->data.
      
      The layout of skbs in the fourth [4] case at the moment of
      dev_gro_receive() is identical to skbs that have come through [1],
      as napi_frags_skb() pulls Ethernet header to skb->head. The only
      difference is that the mentioned condition is always false for them,
      because skb_put() and friends irreversibly alter the tail pointer.
      They also go through the 'slow' path, but now every single
      pskb_may_pull() in every single .gro_receive() will call the *really*
      slow __pskb_pull_tail() to pull headers to head. This significantly
      decreases the overall performance for no visible reasons.
      
      The only two users of method [4] is:
      * drivers/staging/qlge
      * drivers/net/wireless/iwlwifi (all three variants: dvm, mvm, mvm-mq)
      
      Note that in case with wireless drivers we can't use [1]
      (napi_gro_frags()) at least for now and mac80211 stack always
      performs pushes and pulls anyways, so performance hit is inavoidable.
      
      At the moment of v2.6.31 the mentioned change was necessary (that's
      why I don't add the "Fixes:" tag), but it became obsolete since
      skb_gro_mac_header() has gone in commit a50e233c ("net-gro:
      restore frag0 optimization"), so we can simply revert the condition
      in gro_reset_offset() to allow skbs from [4] go through the 'fast'
      path just like in case [1].
      
      This was tested on a 600 MHz MIPS CPU and a custom driver and this
      patch gave boosts up to 40 Mbps to method [4] in both directions
      comparing to net-next, which made overall performance relatively
      close to [1] (without it, [4] is the slowest).
      
      v2:
      - Add more references and explanations to commit message
      - Fix some typos ibid
      - No functional changes
      Signed-off-by: default avatarAlexander Lobakin <alobakin@dlink.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8aef998d