1. 23 Jun, 2023 21 commits
  2. 22 Jun, 2023 19 commits
    • Paolo Bonzini's avatar
      Merge tag 'kvmarm-fixes-6.4-4' of... · 2623b3dc
      Paolo Bonzini authored
      Merge tag 'kvmarm-fixes-6.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
      
      KVM/arm64 fixes for 6.4, take #4
      
      - Correctly save/restore PMUSERNR_EL0 when host userspace is using
        PMU counters directly
      
      - Fix GICv2 emulation on GICv3 after the locking rework
      
      - Don't use smp_processor_id() in kvm_pmu_probe_armpmu(), and
        document why...
      2623b3dc
    • Gavin Shan's avatar
      KVM: Avoid illegal stage2 mapping on invalid memory slot · 2230f9e1
      Gavin Shan authored
      We run into guest hang in edk2 firmware when KSM is kept as running on
      the host. The edk2 firmware is waiting for status 0x80 from QEMU's pflash
      device (TYPE_PFLASH_CFI01) during the operation of sector erasing or
      buffered write. The status is returned by reading the memory region of
      the pflash device and the read request should have been forwarded to QEMU
      and emulated by it. Unfortunately, the read request is covered by an
      illegal stage2 mapping when the guest hang issue occurs. The read request
      is completed with QEMU bypassed and wrong status is fetched. The edk2
      firmware runs into an infinite loop with the wrong status.
      
      The illegal stage2 mapping is populated due to same page sharing by KSM
      at (C) even the associated memory slot has been marked as invalid at (B)
      when the memory slot is requested to be deleted. It's notable that the
      active and inactive memory slots can't be swapped when we're in the middle
      of kvm_mmu_notifier_change_pte() because kvm->mn_active_invalidate_count
      is elevated, and kvm_swap_active_memslots() will busy loop until it reaches
      to zero again. Besides, the swapping from the active to the inactive memory
      slots is also avoided by holding &kvm->srcu in __kvm_handle_hva_range(),
      corresponding to synchronize_srcu_expedited() in kvm_swap_active_memslots().
      
        CPU-A                    CPU-B
        -----                    -----
                                 ioctl(kvm_fd, KVM_SET_USER_MEMORY_REGION)
                                 kvm_vm_ioctl_set_memory_region
                                 kvm_set_memory_region
                                 __kvm_set_memory_region
                                 kvm_set_memslot(kvm, old, NULL, KVM_MR_DELETE)
                                   kvm_invalidate_memslot
                                     kvm_copy_memslot
                                     kvm_replace_memslot
                                     kvm_swap_active_memslots        (A)
                                     kvm_arch_flush_shadow_memslot   (B)
        same page sharing by KSM
        kvm_mmu_notifier_invalidate_range_start
              :
        kvm_mmu_notifier_change_pte
          kvm_handle_hva_range
          __kvm_handle_hva_range
          kvm_set_spte_gfn            (C)
              :
        kvm_mmu_notifier_invalidate_range_end
      
      Fix the issue by skipping the invalid memory slot at (C) to avoid the
      illegal stage2 mapping so that the read request for the pflash's status
      is forwarded to QEMU and emulated by it. In this way, the correct pflash's
      status can be returned from QEMU to break the infinite loop in the edk2
      firmware.
      
      We tried a git-bisect and the first problematic commit is cd4c7183 ("
      KVM: arm64: Convert to the gfn-based MMU notifier callbacks"). With this,
      clean_dcache_guest_page() is called after the memory slots are iterated
      in kvm_mmu_notifier_change_pte(). clean_dcache_guest_page() is called
      before the iteration on the memory slots before this commit. This change
      literally enlarges the racy window between kvm_mmu_notifier_change_pte()
      and memory slot removal so that we're able to reproduce the issue in a
      practical test case. However, the issue exists since commit d5d8184d
      ("KVM: ARM: Memory virtualization setup").
      
      Cc: stable@vger.kernel.org # v3.9+
      Fixes: d5d8184d ("KVM: ARM: Memory virtualization setup")
      Reported-by: default avatarShuai Hu <hshuai@redhat.com>
      Reported-by: default avatarZhenyu Zhang <zhenyzha@redhat.com>
      Signed-off-by: default avatarGavin Shan <gshan@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarOliver Upton <oliver.upton@linux.dev>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarSean Christopherson <seanjc@google.com>
      Reviewed-by: default avatarShaoqin Huang <shahuang@redhat.com>
      Message-Id: <20230615054259.14911-1-gshan@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2230f9e1
    • Paolo Abeni's avatar
      Merge tag 'nf-23-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · 2ba7e7eb
      Paolo Abeni authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS fixes for net
      
      This is v3, including a crash fix for patch 01/14.
      
      The following patchset contains Netfilter/IPVS fixes for net:
      
      1) Fix UDP segmentation with IPVS tunneled traffic, from Terin Stock.
      
      2) Fix chain binding transaction logic, add a bound flag to rule
         transactions. Remove incorrect logic in nft_data_hold() and
         nft_data_release().
      
      3) Add a NFT_TRANS_PREPARE_ERROR deactivate state to deal with releasing
         the set/chain as a follow up to 1240eb93 ("netfilter: nf_tables:
         incorrect error path handling with NFT_MSG_NEWRULE")
      
      4) Drop map element references from preparation phase instead of
         set destroy path, otherwise bogus EBUSY with transactions such as:
      
              flush chain ip x y
              delete chain ip x w
      
         where chain ip x y contains jump/goto from set elements.
      
      5) Pipapo set type does not regard generation mask from the walk
         iteration.
      
      6) Fix reference count underflow in set element reference to
         stateful object.
      
      7) Several patches to tighten the nf_tables API:
         - disallow set element updates of bound anonymous set
         - disallow unbound anonymous set/chain at the end of transaction.
         - disallow updates of anonymous set.
         - disallow timeout configuration for anonymous sets.
      
      8) Fix module reference leak in chain updates.
      
      9) Fix nfnetlink_osf module autoload.
      
      10) Fix deletion of basechain when NFTA_CHAIN_HOOK is specified as
          in iptables-nft.
      
      This Netfilter batch is larger than usual at this stage, I am aware we
      are fairly late in the -rc cycle, if you prefer to route them through
      net-next, please let me know.
      
      netfilter pull request 23-06-21
      
      * tag 'nf-23-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
        netfilter: nf_tables: Fix for deleting base chains with payload
        netfilter: nfnetlink_osf: fix module autoload
        netfilter: nf_tables: drop module reference after updating chain
        netfilter: nf_tables: disallow timeout for anonymous sets
        netfilter: nf_tables: disallow updates of anonymous sets
        netfilter: nf_tables: reject unbound chain set before commit phase
        netfilter: nf_tables: reject unbound anonymous set before commit phase
        netfilter: nf_tables: disallow element updates of bound anonymous sets
        netfilter: nf_tables: fix underflow in object reference counter
        netfilter: nft_set_pipapo: .walk does not deal with generations
        netfilter: nf_tables: drop map element references from preparation phase
        netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain
        netfilter: nf_tables: fix chain binding transaction logic
        ipvs: align inner_mac_header for encapsulation
      ====================
      
      Link: https://lore.kernel.org/r/20230621100731.68068-1-pablo@netfilter.orgSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      2ba7e7eb
    • Maciej Żenczykowski's avatar
      revert "net: align SO_RCVMARK required privileges with SO_MARK" · a9628e88
      Maciej Żenczykowski authored
      This reverts commit 1f86123b ("net: align SO_RCVMARK required
      privileges with SO_MARK") because the reasoning in the commit message
      is not really correct:
        SO_RCVMARK is used for 'reading' incoming skb mark (via cmsg), as such
        it is more equivalent to 'getsockopt(SO_MARK)' which has no priv check
        and retrieves the socket mark, rather than 'setsockopt(SO_MARK) which
        sets the socket mark and does require privs.
      
        Additionally incoming skb->mark may already be visible if
        sysctl_fwmark_reflect and/or sysctl_tcp_fwmark_accept are enabled.
      
        Furthermore, it is easier to block the getsockopt via bpf
        (either cgroup setsockopt hook, or via syscall filters)
        then to unblock it if it requires CAP_NET_RAW/ADMIN.
      
      On Android the socket mark is (among other things) used to store
      the network identifier a socket is bound to.  Setting it is privileged,
      but retrieving it is not.  We'd like unprivileged userspace to be able
      to read the network id of incoming packets (where mark is set via
      iptables [to be moved to bpf])...
      
      An alternative would be to add another sysctl to control whether
      setting SO_RCVMARK is privilged or not.
      (or even a MASK of which bits in the mark can be exposed)
      But this seems like over-engineering...
      
      Note: This is a non-trivial revert, due to later merged commit e42c7bee
      ("bpf: net: Consider has_current_bpf_ctx() when testing capable() in sk_setsockopt()")
      which changed both 'ns_capable' into 'sockopt_ns_capable' calls.
      
      Fixes: 1f86123b ("net: align SO_RCVMARK required privileges with SO_MARK")
      Cc: Larysa Zaremba <larysa.zaremba@intel.com>
      Cc: Simon Horman <simon.horman@corigine.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Eyal Birger <eyal.birger@gmail.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Patrick Rohr <prohr@google.com>
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Reviewed-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Link: https://lore.kernel.org/r/20230618103130.51628-1-maze@google.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      a9628e88
    • Kees Cook's avatar
      net: wwan: iosm: Convert single instance struct member to flexible array · dec24b3b
      Kees Cook authored
      struct mux_adth actually ends with multiple struct mux_adth_dg members.
      This is seen both in the comments about the member:
      
      /**
       * struct mux_adth - Structure of the Aggregated Datagram Table Header.
       ...
       * @dg:		datagramm table with variable length
       */
      
      and in the preparation for populating it:
      
                              adth_dg_size = offsetof(struct mux_adth, dg) +
                                              ul_adb->dg_count[i] * sizeof(*dg);
      			...
                              adth_dg_size -= offsetof(struct mux_adth, dg);
                              memcpy(&adth->dg, ul_adb->dg[i], adth_dg_size);
      
      This was reported as a run-time false positive warning:
      
      memcpy: detected field-spanning write (size 16) of single field "&adth->dg" at drivers/net/wwan/iosm/iosm_ipc_mux_codec.c:852 (size 8)
      
      Adjust the struct mux_adth definition and associated sizeof() math; no binary
      output differences are observed in the resulting object file.
      Reported-by: default avatarFlorian Klink <flokli@flokli.de>
      Closes: https://lore.kernel.org/lkml/dbfa25f5-64c8-5574-4f5d-0151ba95d232@gmail.com/
      Fixes: 1f52d7b6 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
      Cc: M Chetan Kumar <m.chetan.kumar@intel.com>
      Cc: Bagas Sanjaya <bagasdotme@gmail.com>
      Cc: Intel Corporation <linuxwwan@intel.com>
      Cc: Loic Poulain <loic.poulain@linaro.org>
      Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/20230620194234.never.023-kees@kernel.orgSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      dec24b3b
    • Eric Dumazet's avatar
      sch_netem: acquire qdisc lock in netem_change() · 2174a08d
      Eric Dumazet authored
      syzbot managed to trigger a divide error [1] in netem.
      
      It could happen if q->rate changes while netem_enqueue()
      is running, since q->rate is read twice.
      
      It turns out netem_change() always lacked proper synchronization.
      
      [1]
      divide error: 0000 [#1] SMP KASAN
      CPU: 1 PID: 7867 Comm: syz-executor.1 Not tainted 6.1.30-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
      RIP: 0010:div64_u64 include/linux/math64.h:69 [inline]
      RIP: 0010:packet_time_ns net/sched/sch_netem.c:357 [inline]
      RIP: 0010:netem_enqueue+0x2067/0x36d0 net/sched/sch_netem.c:576
      Code: 89 e2 48 69 da 00 ca 9a 3b 42 80 3c 28 00 4c 8b a4 24 88 00 00 00 74 0d 4c 89 e7 e8 c3 4f 3b fd 48 8b 4c 24 18 48 89 d8 31 d2 <49> f7 34 24 49 01 c7 4c 8b 64 24 48 4d 01 f7 4c 89 e3 48 c1 eb 03
      RSP: 0018:ffffc9000dccea60 EFLAGS: 00010246
      RAX: 000001a442624200 RBX: 000001a442624200 RCX: ffff888108a4f000
      RDX: 0000000000000000 RSI: 000000000000070d RDI: 000000000000070d
      RBP: ffffc9000dcceb90 R08: ffffffff849c5e26 R09: fffffbfff10e1297
      R10: 0000000000000000 R11: dffffc0000000001 R12: ffff888108a4f358
      R13: dffffc0000000000 R14: 0000001a8cd9a7ec R15: 0000000000000000
      FS: 00007fa73fe18700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa73fdf7718 CR3: 000000011d36e000 CR4: 0000000000350ee0
      Call Trace:
      <TASK>
      [<ffffffff84714385>] __dev_xmit_skb net/core/dev.c:3931 [inline]
      [<ffffffff84714385>] __dev_queue_xmit+0xcf5/0x3370 net/core/dev.c:4290
      [<ffffffff84d22df2>] dev_queue_xmit include/linux/netdevice.h:3030 [inline]
      [<ffffffff84d22df2>] neigh_hh_output include/net/neighbour.h:531 [inline]
      [<ffffffff84d22df2>] neigh_output include/net/neighbour.h:545 [inline]
      [<ffffffff84d22df2>] ip_finish_output2+0xb92/0x10d0 net/ipv4/ip_output.c:235
      [<ffffffff84d21e63>] __ip_finish_output+0xc3/0x2b0
      [<ffffffff84d10a81>] ip_finish_output+0x31/0x2a0 net/ipv4/ip_output.c:323
      [<ffffffff84d10f14>] NF_HOOK_COND include/linux/netfilter.h:298 [inline]
      [<ffffffff84d10f14>] ip_output+0x224/0x2a0 net/ipv4/ip_output.c:437
      [<ffffffff84d123b5>] dst_output include/net/dst.h:444 [inline]
      [<ffffffff84d123b5>] ip_local_out net/ipv4/ip_output.c:127 [inline]
      [<ffffffff84d123b5>] __ip_queue_xmit+0x1425/0x2000 net/ipv4/ip_output.c:542
      [<ffffffff84d12fdc>] ip_queue_xmit+0x4c/0x70 net/ipv4/ip_output.c:556
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Reviewed-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/20230620184425.1179809-1-edumazet@google.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      2174a08d
    • Shyam Sundar S K's avatar
      platform/x86/amd/pmf: Register notify handler only if SPS is enabled · 146b6f68
      Shyam Sundar S K authored
      Power source notify handler is getting registered even when none of the
      PMF feature in enabled leading to a crash.
      
      ...
      [   22.592162] Call Trace:
      [   22.592164]  <TASK>
      [   22.592164]  ? rcu_note_context_switch+0x5e0/0x660
      [   22.592166]  ? __warn+0x81/0x130
      [   22.592171]  ? rcu_note_context_switch+0x5e0/0x660
      [   22.592172]  ? report_bug+0x171/0x1a0
      [   22.592175]  ? prb_read_valid+0x1b/0x30
      [   22.592177]  ? handle_bug+0x3c/0x80
      [   22.592178]  ? exc_invalid_op+0x17/0x70
      [   22.592179]  ? asm_exc_invalid_op+0x1a/0x20
      [   22.592182]  ? rcu_note_context_switch+0x5e0/0x660
      [   22.592183]  ? acpi_ut_delete_object_desc+0x86/0xb0
      [   22.592186]  ? acpi_ut_update_ref_count.part.0+0x22d/0x930
      [   22.592187]  __schedule+0xc0/0x1410
      [   22.592189]  ? ktime_get+0x3c/0xa0
      [   22.592191]  ? lapic_next_event+0x1d/0x30
      [   22.592193]  ? hrtimer_start_range_ns+0x25b/0x350
      [   22.592196]  schedule+0x5e/0xd0
      [   22.592197]  schedule_hrtimeout_range_clock+0xbe/0x140
      [   22.592199]  ? __pfx_hrtimer_wakeup+0x10/0x10
      [   22.592200]  usleep_range_state+0x64/0x90
      [   22.592203]  amd_pmf_send_cmd+0x106/0x2a0 [amd_pmf bddfe0fe3712aaa99acce3d5487405c5213c6616]
      [   22.592207]  amd_pmf_update_slider+0x56/0x1b0 [amd_pmf bddfe0fe3712aaa99acce3d5487405c5213c6616]
      [   22.592210]  amd_pmf_set_sps_power_limits+0x72/0x80 [amd_pmf bddfe0fe3712aaa99acce3d5487405c5213c6616]
      [   22.592213]  amd_pmf_pwr_src_notify_call+0x49/0x90 [amd_pmf bddfe0fe3712aaa99acce3d5487405c5213c6616]
      [   22.592216]  notifier_call_chain+0x5a/0xd0
      [   22.592218]  atomic_notifier_call_chain+0x32/0x50
      ...
      
      Fix this by moving the registration of source change notify handler only
      when SPS(Static Slider) is advertised as supported.
      Reported-by: default avatarAllen Zhong <allen@atr.me>
      Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217571
      Fixes: 4c71ae41 ("platform/x86/amd/pmf: Add support SPS PMF feature")
      Tested-by: default avatarPatil Rajesh Reddy <Patil.Reddy@amd.com>
      Reviewed-by: default avatarMario Limonciello <mario.limonciello@amd.com>
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Link: https://lore.kernel.org/r/20230622060309.310001-1-Shyam-sundar.S-k@amd.comReviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      146b6f68
    • Danielle Ratson's avatar
      selftests: forwarding: Fix race condition in mirror installation · c7c059fb
      Danielle Ratson authored
      When mirroring to a gretap in hardware the device expects to be
      programmed with the egress port and all the encapsulating headers. This
      requires the driver to resolve the path the packet will take in the
      software data path and program the device accordingly.
      
      If the path cannot be resolved (in this case because of an unresolved
      neighbor), then mirror installation fails until the path is resolved.
      This results in a race that causes the test to sometimes fail.
      
      Fix this by setting the neighbor's state to permanent in a couple of
      tests, so that it is always valid.
      
      Fixes: 35c31d5c ("selftests: forwarding: Test mirror-to-gretap w/ UL 802.1d")
      Fixes: 239e754a ("selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q")
      Signed-off-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Link: https://lore.kernel.org/r/268816ac729cb6028c7a34d4dda6f4ec7af55333.1687264607.git.petrm@nvidia.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      c7c059fb
    • Benjamin Berg's avatar
      wifi: mac80211: report all unusable beacon frames · 7f4e0970
      Benjamin Berg authored
      Properly check for RX_DROP_UNUSABLE now that the new drop reason
      infrastructure is used. Without this change, the comparison will always
      be false as a more specific reason is given in the lower bits of result.
      
      Fixes: baa951a1 ("mac80211: use the new drop reasons infrastructure")
      Signed-off-by: default avatarBenjamin Berg <benjamin.berg@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Link: https://lore.kernel.org/r/20230621120543.412920-2-johannes@sipsolutions.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7f4e0970
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-expose-more-info-and-small-improvements' · 98e95872
      Jakub Kicinski authored
      Matthieu Baerts says:
      
      ====================
      mptcp: expose more info and small improvements
      
      Patch 1-3/9 track and expose some aggregated data counters at the MPTCP
      level: the number of retransmissions and the bytes that have been
      transferred. The first patch prepares the work by moving where snd_una
      is updated for fallback sockets while the last patch adds some tests to
      cover the new code.
      
      Patch 4-6/9 introduce a new getsockopt for SOL_MPTCP: MPTCP_FULL_INFO.
      This new socket option allows to combine info from MPTCP_INFO,
      MPTCP_TCPINFO and MPTCP_SUBFLOW_ADDRS socket options into one. It can be
      needed to have all info in one because the path-manager can close and
      re-create subflows between getsockopt() and fooling the accounting. The
      first patch introduces a unique subflow ID to easily detect when
      subflows are being re-created with the same 5-tuple while the last patch
      adds some tests to cover the new code.
      
      Please note that patch 5/9 ("mptcp: introduce MPTCP_FULL_INFO getsockopt")
      can reveal a bug that were there for a bit of time, see [1]. A fix has
      recently been fixed to netdev for the -net tree: "mptcp: ensure listener
      is unhashed before updating the sk status", see [2]. There is no
      conflicts between the two patches but it might be better to apply this
      series after the one for -net and after having merged "net" into
      "net-next".
      
      Patch 7/9 is similar to commit 47867f0a ("selftests: mptcp: join:
      skip check if MIB counter not supported") recently applied in the -net
      tree but here it adapts the new code that is only in net-next (and it
      fixes a merge conflict resolution which didn't have any impact).
      
      Patch 8 and 9/9 are two simple refactoring. One to consolidate the
      transition to TCP_CLOSE in mptcp_do_fastclose() and avoid duplicated
      code. The other one reduces the scope of an argument passed to
      mptcp_pm_alloc_anno_list() function.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/407 [1]
      Link: https://lore.kernel.org/netdev/20230620-upstream-net-20230620-misc-fixes-for-v6-4-v1-0-f36aa5eae8b9@tessares.net/ [2]
      ====================
      
      Link: https://lore.kernel.org/r/20230620-upstream-net-next-20230620-mptcp-expose-more-info-and-misc-v1-0-62b9444bfd48@tessares.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      98e95872
    • Geliang Tang's avatar
      mptcp: pass addr to mptcp_pm_alloc_anno_list · 528cb5f2
      Geliang Tang authored
      Pass addr parameter to mptcp_pm_alloc_anno_list() instead of entry. We
      can reduce the scope, e.g. in mptcp_pm_alloc_anno_list(), we only access
      "entry->addr", we can then restrict to the pointer to "addr" then.
      Signed-off-by: default avatarGeliang Tang <geliang.tang@suse.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      528cb5f2
    • Paolo Abeni's avatar
      mptcp: consolidate transition to TCP_CLOSE in mptcp_do_fastclose() · bbd49d11
      Paolo Abeni authored
      The MPTCP code always set the msk state to TCP_CLOSE before
      calling performing the fast-close. Move such state transition in
      mptcp_do_fastclose() to avoid some code duplication.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bbd49d11
    • Matthieu Baerts's avatar
      selftests: mptcp: join: skip check if MIB counter not supported (part 2) · 00079f18
      Matthieu Baerts authored
      Selftests are supposed to run on any kernels, including the old ones not
      supporting all MPTCP features.
      
      One of them is the MPTCP MIB counters introduced in commit fc518953
      ("mptcp: add and use MIB counter infrastructure") and more later. The
      MPTCP Join selftest heavily relies on these counters.
      
      If a counter is not supported by the kernel, it is not displayed when
      using 'nstat -z'. We can then detect that and skip the verification. A
      new helper (get_counter()) has been added recently in the -net tree to
      do the required checks and return an error if the counter is not
      available.
      
      This commit is similar to the one with the same title applied in the
      -net tree but it modifies code only present in net-next for the moment,
      see the Fixes commit below.
      
      While at it, we can also remove the use of ${extra_msg} variable which
      is never assigned in chk_rm_tx_nr() function and use 'echo' without '-n'
      parameter.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: 0639fa23 ("selftests: mptcp: add explicit check for new mibs")
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      00079f18
    • Paolo Abeni's avatar
      selftests: mptcp: add MPTCP_FULL_INFO testcase · aa723d5b
      Paolo Abeni authored
      Add a testcase explicitly triggering the newly introduce
      MPTCP_FULL_INFO getsockopt.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/388Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Co-developed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      aa723d5b
    • Paolo Abeni's avatar
      mptcp: introduce MPTCP_FULL_INFO getsockopt · 49243207
      Paolo Abeni authored
      Some user-space applications want to monitor the subflows utilization.
      
      Dumping the per subflow tcp_info is not enough, as the PM could close
      and re-create the subflows under-the-hood, fooling the accounting.
      Even checking the src/dst addresses used by each subflow could not
      be enough, because new subflows could re-use the same address/port of
      the just closed one.
      
      This patch introduces a new socket option, allow dumping all the relevant
      information all-at-once (everything, everywhere...), in a consistent
      manner.
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/388Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      49243207
    • Paolo Abeni's avatar
      mptcp: add subflow unique id · 6f06b4d4
      Paolo Abeni authored
      The user-space need to properly account the data received/sent by
      individual subflows. When additional subflows are created and/or
      closed during the MPTCP socket lifetime, the information currently
      exposed via MPTCP_TCPINFO are not enough: subflows are identified only
      by the sequential position inside the info dumps, and that will change
      with the above mentioned events.
      
      To solve the above problem, this patch introduces a new subflow
      identifier that is unique inside the given MPTCP socket scope.
      
      The initial subflow get the id 1 and the other subflows get incremental
      values at join time.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/388Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6f06b4d4
    • Paolo Abeni's avatar
      selftests: mptcp: explicitly tests aggregate counters · 5dcff89e
      Paolo Abeni authored
      Update the existing sockopt test-case to do some basic checks
      on the newly added counters.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/385Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5dcff89e
    • Paolo Abeni's avatar
      mptcp: track some aggregate data counters · 38967f42
      Paolo Abeni authored
      Currently there are no data transfer counters accounting for all
      the subflows used by a given MPTCP socket. The user-space can compute
      such figures aggregating the subflow info, but that is inaccurate
      if any subflow is closed before the MPTCP socket itself.
      
      Add the new counters in the MPTCP socket itself and expose them
      via the existing diag and sockopt. While touching mptcp_diag_fill_info(),
      acquire the relevant locks before fetching the msk data, to ensure
      better data consistency
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/385Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      38967f42
    • Paolo Abeni's avatar
      mptcp: move snd_una update earlier for fallback socket · c026d33b
      Paolo Abeni authored
      That will avoid an unneeded conditional in both the fast-path
      and in the fallback case and will simplify a bit the next
      patch.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c026d33b