1. 16 Jan, 2023 1 commit
    • Kurt Kanzenbach's avatar
      net: stmmac: Fix queue statistics reading · c296c77e
      Kurt Kanzenbach authored
      Correct queue statistics reading. All queue statistics are stored as unsigned
      long values. The retrieval for ethtool fetches these values as u64. However, on
      some systems the size of the counters are 32 bit. That yields wrong queue
      statistic counters e.g., on arm32 systems such as the stm32mp157. Fix it by
      using the correct data type.
      
      Tested on Olimex STMP157-OLinuXino-LIME2 by simple running linuxptp for a short
      period of time:
      
      Non-patched kernel:
      |root@st1:~# ethtool -S eth0 | grep q0
      |     q0_tx_pkt_n: 3775276254951 # ???
      |     q0_tx_irq_n: 879
      |     q0_rx_pkt_n: 1194000908909 # ???
      |     q0_rx_irq_n: 278
      
      Patched kernel:
      |root@st1:~# ethtool -S eth0 | grep q0
      |     q0_tx_pkt_n: 2434
      |     q0_tx_irq_n: 1274
      |     q0_rx_pkt_n: 1604
      |     q0_rx_irq_n: 846
      
      Fixes: 68e9c5de ("net: stmmac: add ethtool per-queue statistic framework")
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Cc: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
      Cc: Wong Vee Khee <vee.khee.wong@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c296c77e
  2. 14 Jan, 2023 9 commits
    • Rahul Rameshbabu's avatar
      sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb · a22b7388
      Rahul Rameshbabu authored
      Peek at old qdisc and graft only when deleting a leaf class in the htb,
      rather than when deleting the htb itself. Do not peek at the qdisc of the
      netdev queue when destroying the htb. The caller may already have grafted a
      new qdisc that is not part of the htb structure being destroyed.
      
      This fix resolves two use cases.
      
        1. Using tc to destroy the htb.
          - Netdev was being prematurely activated before the htb was fully
            destroyed.
        2. Using tc to replace the htb with another qdisc (which also leads to
           the htb being destroyed).
          - Premature netdev activation like previous case. Newly grafted qdisc
            was also getting accidentally overwritten when destroying the htb.
      
      Fixes: d03b195b ("sch_htb: Hierarchical QoS hardware offload")
      Signed-off-by: default avatarRahul Rameshbabu <rrameshbabu@nvidia.com>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Reviewed-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Link: https://lore.kernel.org/r/20230113005528.302625-1-rrameshbabu@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a22b7388
    • Jakub Kicinski's avatar
      Merge branch 'mptcp-userspace-pm-create-sockets-for-the-right-family' · da263fcb
      Jakub Kicinski authored
      Matthieu Baerts says:
      
      ====================
      mptcp: userspace pm: create sockets for the right family
      
      Before these patches, the Userspace Path Manager would allow the
      creation of subflows with wrong families: taking the one of the MPTCP
      socket instead of the provided ones and resulting in the creation of
      subflows with likely not the right source and/or destination IPs. It
      would also allow the creation of subflows between different families or
      not respecting v4/v6-only socket attributes.
      
      Patch 1 lets the userspace PM select the proper family to avoid creating
      subflows with the wrong source and/or destination addresses because the
      family is not the expected one.
      
      Patch 2 makes sure the userspace PM doesn't allow the userspace to
      create subflows for a family that is not allowed.
      
      Patch 3 validates scenarios with a mix of v4 and v6 subflows for the
      same MPTCP connection.
      
      These patches fix issues introduced in v5.19 when the userspace path
      manager has been introduced.
      ====================
      
      Link: https://lore.kernel.org/r/20230112-upstream-net-20230112-netlink-v4-v6-v1-0-6a8363a221d2@tessares.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      da263fcb
    • Matthieu Baerts's avatar
      selftests: mptcp: userspace: validate v4-v6 subflows mix · 4656d72c
      Matthieu Baerts authored
      MPTCP protocol supports having subflows in both IPv4 and IPv6. In Linux,
      it is possible to have that if the MPTCP socket has been created with
      AF_INET6 family without the IPV6_V6ONLY option.
      
      Here, a new IPv4 subflow is being added to the initial IPv6 connection,
      then being removed using Netlink commands.
      
      Cc: stable@vger.kernel.org # v5.19+
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4656d72c
    • Matthieu Baerts's avatar
      mptcp: netlink: respect v4/v6-only sockets · fb00ee4f
      Matthieu Baerts authored
      If an MPTCP socket has been created with AF_INET6 and the IPV6_V6ONLY
      option has been set, the userspace PM would allow creating subflows
      using IPv4 addresses, e.g. mapped in v6.
      
      The kernel side of userspace PM will also accept creating subflows with
      local and remote addresses having different families. Depending on the
      subflow socket's family, different behaviours are expected:
       - If AF_INET is forced with a v6 address, the kernel will take the last
         byte of the IP and try to connect to that: a new subflow is created
         but to a non expected address.
       - If AF_INET6 is forced with a v4 address, the kernel will try to
         connect to a v4 address (v4-mapped-v6). A -EBADF error from the
         connect() part is then expected.
      
      It is then required to check the given families can be accepted. This is
      done by using a new helper for addresses family matching, taking care of
      IPv4 vs IPv4-mapped-IPv6 addresses. This helper will be re-used later by
      the in-kernel path-manager to use mixed IPv4 and IPv6 addresses.
      
      While at it, a clear error message is now reported if there are some
      conflicts with the families that have been passed by the userspace.
      
      Fixes: 702c2f64 ("mptcp: netlink: allow userspace-driven subflow establishment")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fb00ee4f
    • Paolo Abeni's avatar
      mptcp: explicitly specify sock family at subflow creation time · 6bc1fe7d
      Paolo Abeni authored
      Let the caller specify the to-be-created subflow family.
      
      For a given MPTCP socket created with the AF_INET6 family, the current
      userspace PM can already ask the kernel to create subflows in v4 and v6.
      If "plain" IPv4 addresses are passed to the kernel, they are
      automatically mapped in v6 addresses "by accident". This can be
      problematic because the userspace will need to pass different addresses,
      now the v4-mapped-v6 addresses to destroy this new subflow.
      
      On the other hand, if the MPTCP socket has been created with the AF_INET
      family, the command to create a subflow in v6 will be accepted but the
      result will not be the one as expected as new subflow will be created in
      IPv4 using part of the v6 addresses passed to the kernel: not creating
      the expected subflow then.
      
      No functional change intended for the in-kernel PM where an explicit
      enforcement is currently in place. This arbitrary enforcement will be
      leveraged by other patches in a future version.
      
      Fixes: 702c2f64 ("mptcp: netlink: allow userspace-driven subflow establishment")
      Cc: stable@vger.kernel.org
      Co-developed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6bc1fe7d
    • Clément Léger's avatar
      net: lan966x: add missing fwnode_handle_put() for ports node · 925f3deb
      Clément Léger authored
      Since the "ethernet-ports" node is retrieved using
      device_get_named_child_node(), it should be release after using it. Add
      missing fwnode_handle_put() and move the code that retrieved the node
      from device-tree to avoid complicated handling in case of error.
      
      Fixes: db8bcaad ("net: lan966x: add the basic lan966x driver")
      Signed-off-by: default avatarClément Léger <clement.leger@bootlin.com>
      Reviewed-by: default avatarAlexander Duyck <alexanderduyck@fb.com>
      Link: https://lore.kernel.org/r/20230112161311.495124-1-clement.leger@bootlin.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      925f3deb
    • Vladimir Oltean's avatar
      net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() · 3c463721
      Vladimir Oltean authored
      This lockdep splat says it better than I could:
      
      ================================
      WARNING: inconsistent lock state
      6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
      --------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
      ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
      {IN-SOFTIRQ-W} state was registered at:
        _raw_spin_lock+0x5c/0xc0
        sch_direct_xmit+0x148/0x37c
        __dev_queue_xmit+0x528/0x111c
        ip6_finish_output2+0x5ec/0xb7c
        ip6_finish_output+0x240/0x3f0
        ip6_output+0x78/0x360
        ndisc_send_skb+0x33c/0x85c
        ndisc_send_rs+0x54/0x12c
        addrconf_rs_timer+0x154/0x260
        call_timer_fn+0xb8/0x3a0
        __run_timers.part.0+0x214/0x26c
        run_timer_softirq+0x3c/0x74
        __do_softirq+0x14c/0x5d8
        ____do_softirq+0x10/0x20
        call_on_irq_stack+0x2c/0x5c
        do_softirq_own_stack+0x1c/0x30
        __irq_exit_rcu+0x168/0x1a0
        irq_exit_rcu+0x10/0x40
        el1_interrupt+0x38/0x64
      irq event stamp: 7825
      hardirqs last  enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130
      hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8
      softirqs last  enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8
      softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(_xmit_ETHER#2);
        <Interrupt>
          lock(_xmit_ETHER#2);
      
       *** DEADLOCK ***
      
      3 locks held by kworker/1:3/179:
       #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
       #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
       #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
      
      Workqueue: events enetc_tx_onestep_tstamp
      Call trace:
       print_usage_bug.part.0+0x208/0x22c
       mark_lock+0x7f0/0x8b0
       __lock_acquire+0x7c4/0x1ce0
       lock_acquire.part.0+0xe0/0x220
       lock_acquire+0x68/0x84
       _raw_spin_lock+0x5c/0xc0
       netif_freeze_queues+0x5c/0xc0
       netif_tx_lock+0x24/0x34
       enetc_tx_onestep_tstamp+0x20/0x100
       process_one_work+0x28c/0x6c0
       worker_thread+0x74/0x450
       kthread+0x118/0x11c
      
      but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in
      process context, therefore with softirqs enabled (i.o.w., it can be
      interrupted by a softirq). If we hold the netif_tx_lock() when there is
      an interrupt, and the NET_TX softirq then gets scheduled, this will take
      the netif_tx_lock() a second time and deadlock the kernel.
      
      To solve this, use netif_tx_lock_bh(), which blocks softirqs from
      running.
      
      Fixes: 7294380c ("enetc: support PTP Sync packet one-step timestamping")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAlexander Duyck <alexanderduyck@fb.com>
      Link: https://lore.kernel.org/r/20230112105440.1786799-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3c463721
    • Esina Ekaterina's avatar
      net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs · 488e0bf7
      Esina Ekaterina authored
      If uhdlc_priv_tsa != 1 then utdm is not initialized.
      And if ret != NULL then goto undo_uhdlc_init, where
      utdm is dereferenced. Same if dev == NULL.
      
      Found by Astra Linux on behalf of Linux Verification Center
      (linuxtesting.org) with SVACE.
      
      Fixes: 8d68100a ("soc/fsl/qe: fix err handling of ucc_of_parse_tdm")
      Signed-off-by: default avatarEsina Ekaterina <eesina@astralinux.ru>
      Link: https://lore.kernel.org/r/20230112074703.13558-1-eesina@astralinux.ruSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      488e0bf7
    • Jisoo Jang's avatar
      net: nfc: Fix use-after-free in local_cleanup() · 4bb4db7f
      Jisoo Jang authored
      Fix a use-after-free that occurs in kfree_skb() called from
      local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
      after detaching an nfc device.
      When detaching an nfc device, local_cleanup() called from
      nfc_llcp_unregister_device() frees local->rx_pending and decreases
      local->ref by kref_put() in nfc_llcp_local_put().
      In the terminating process, nfc daemon releases all sockets and it leads
      to decreasing local->ref. After the last release of local->ref,
      local_cleanup() called from local_release() frees local->rx_pending
      again, which leads to the bug.
      
      Setting local->rx_pending to NULL in local_cleanup() could prevent
      use-after-free when local_cleanup() is called twice.
      
      Found by a modified version of syzkaller.
      
      BUG: KASAN: use-after-free in kfree_skb()
      
      Call Trace:
      dump_stack_lvl (lib/dump_stack.c:106)
      print_address_description.constprop.0.cold (mm/kasan/report.c:306)
      kasan_check_range (mm/kasan/generic.c:189)
      kfree_skb (net/core/skbuff.c:955)
      local_cleanup (net/nfc/llcp_core.c:159)
      nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
      nfc_llcp_local_put (net/nfc/llcp_core.c:181)
      llcp_sock_destruct (net/nfc/llcp_sock.c:959)
      __sk_destruct (net/core/sock.c:2133)
      sk_destruct (net/core/sock.c:2181)
      __sk_free (net/core/sock.c:2192)
      sk_free (net/core/sock.c:2203)
      llcp_sock_release (net/nfc/llcp_sock.c:646)
      __sock_release (net/socket.c:650)
      sock_close (net/socket.c:1365)
      __fput (fs/file_table.c:306)
      task_work_run (kernel/task_work.c:179)
      ptrace_notify (kernel/signal.c:2354)
      syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
      syscall_exit_to_user_mode (kernel/entry/common.c:296)
      do_syscall_64 (arch/x86/entry/common.c:86)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
      
      Allocated by task 4719:
      kasan_save_stack (mm/kasan/common.c:45)
      __kasan_slab_alloc (mm/kasan/common.c:325)
      slab_post_alloc_hook (mm/slab.h:766)
      kmem_cache_alloc_node (mm/slub.c:3497)
      __alloc_skb (net/core/skbuff.c:552)
      pn533_recv_response (drivers/nfc/pn533/usb.c:65)
      __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
      usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
      tasklet_action_common.isra.0 (kernel/softirq.c:797)
      __do_softirq (kernel/softirq.c:571)
      
      Freed by task 1901:
      kasan_save_stack (mm/kasan/common.c:45)
      kasan_set_track (mm/kasan/common.c:52)
      kasan_save_free_info (mm/kasan/genericdd.c:518)
      __kasan_slab_free (mm/kasan/common.c:236)
      kmem_cache_free (mm/slub.c:3809)
      kfree_skbmem (net/core/skbuff.c:874)
      kfree_skb (net/core/skbuff.c:931)
      local_cleanup (net/nfc/llcp_core.c:159)
      nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
      nfc_unregister_device (net/nfc/core.c:1179)
      pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
      pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
      usb_unbind_interface (drivers/usb/core/driver.c:458)
      device_release_driver_internal (drivers/base/dd.c:1279)
      bus_remove_device (drivers/base/bus.c:529)
      device_del (drivers/base/core.c:3665)
      usb_disable_device (drivers/usb/core/message.c:1420)
      usb_disconnect (drivers/usb/core.c:2261)
      hub_event (drivers/usb/core/hub.c:5833)
      process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
      worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
      kthread (kernel/kthread.c:319)
      ret_from_fork (arch/x86/entry/entry_64.S:301)
      
      Fixes: 3536da06 ("NFC: llcp: Clean local timers and works when removing a device")
      Signed-off-by: default avatarJisoo Jang <jisoo.jang@yonsei.ac.kr>
      Link: https://lore.kernel.org/r/20230111131914.3338838-1-jisoo.jang@yonsei.ac.krSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4bb4db7f
  3. 13 Jan, 2023 7 commits
  4. 12 Jan, 2023 16 commits
  5. 11 Jan, 2023 7 commits
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v6.2-2-2023-01-11' of... · e8f60cd7
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v6.2-2-2023-01-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - Make 'perf kmem' cope with the removal of some
         kmem:kmem_cache_alloc_node and kmem:kmalloc_node in the
         11e9734b ("mm/slab_common: unify NUMA and UMA version of
         tracepoints") commit, making sure it works with Linux >= 6.2 as well
         as with older kernels where those tracepoints are present.
      
       - Also make it handle the new "node" kmem:kmalloc and
         kmem:kmem_cache_alloc tracepoint field introduced in that same
         commit.
      
       - Fix hardware tracing PMU address filter duplicate symbol selection,
         that was preventing to match with static functions with the same name
         present in different object files.
      
       - Fix regression on what linux/types.h file gets used to build the "BPF
         prologue" 'perf test' entry, the system one lacks the fmode_t
         definition used in this test, so provide that type in the test
         itself.
      
       - Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1. If the
         user asks for linking with the libbpf package provided by the distro,
         then it has to be >= 0.8.0. Using the libbpf supplied with the kernel
         would be a fallback in that case.
      
       - Fix the build when libbpf isn't available or explicitly disabled via
         NO_LIBBPF=1.
      
       - Don't try to install libtraceevent plugins as its not anymore in the
         kernel sources and will thus always fail.
      
      * tag 'perf-tools-fixes-for-v6.2-2-2023-01-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        perf auxtrace: Fix address filter duplicate symbol selection
        perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1
        perf build: Fix build error when NO_LIBBPF=1
        perf tools: Don't install libtraceevent plugins as its not anymore in the kernel sources
        perf kmem: Support field "node" in evsel__process_alloc_event() coping with recent tracepoint restructuring
        perf kmem: Support legacy tracepoints
        perf build: Properly guard libbpf includes
        perf tests bpf prologue: Fix bpf-script-test-prologue test compile issue with clang
      e8f60cd7
    • Heiko Carstens's avatar
      s390: update defconfigs · 1ecf7bd9
      Heiko Carstens authored
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      1ecf7bd9
    • Adrian Hunter's avatar
      perf auxtrace: Fix address filter duplicate symbol selection · cf129830
      Adrian Hunter authored
      When a match has been made to the nth duplicate symbol, return
      success not error.
      
      Example:
      
        Before:
      
          $ cat file.c
          cat: file.c: No such file or directory
          $ cat file1.c
          #include <stdio.h>
      
          static void func(void)
          {
                  printf("First func\n");
          }
      
          void other(void);
      
          int main()
          {
                  func();
                  other();
                  return 0;
          }
          $ cat file2.c
          #include <stdio.h>
      
          static void func(void)
          {
                  printf("Second func\n");
          }
      
          void other(void)
          {
                  func();
          }
      
          $ gcc -Wall -Wextra -o test file1.c file2.c
          $ perf record -e intel_pt//u --filter 'filter func @ ./test' -- ./test
          Multiple symbols with name 'func'
          #1      0x1149  l       func
                          which is near           main
          #2      0x1179  l       func
                          which is near           other
          Disambiguate symbol name by inserting #n after the name e.g. func #2
          Or select a global symbol by inserting #0 or #g or #G
          Failed to parse address filter: 'filter func @ ./test'
          Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
          Where multiple filters are separated by space or comma.
          $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
          Failed to parse address filter: 'filter func #2 @ ./test'
          Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
          Where multiple filters are separated by space or comma.
      
        After:
      
          $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
          First func
          Second func
          [ perf record: Woken up 1 times to write data ]
          [ perf record: Captured and wrote 0.016 MB perf.data ]
          $ perf script --itrace=b -Ftime,flags,ip,sym,addr --ns
          1231062.526977619:   tr strt                               0 [unknown] =>     558495708179 func
          1231062.526977619:   tr end  call               558495708188 func =>     558495708050 _init
          1231062.526979286:   tr strt                               0 [unknown] =>     55849570818d func
          1231062.526979286:   tr end  return             55849570818f func =>     55849570819d other
      
      Fixes: 1b36c03e ("perf record: Add support for using symbols in address filters")
      Reported-by: default avatarDmitrii Dolgov <9erthalion6@gmail.com>
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarDmitry Dolgov <9erthalion6@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20230110185659.15979-1-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      cf129830
    • Heiko Carstens's avatar
      KVM: s390: interrupt: use READ_ONCE() before cmpxchg() · 42400d99
      Heiko Carstens authored
      Use READ_ONCE() before cmpxchg() to prevent that the compiler generates
      code that fetches the to be compared old value several times from memory.
      Reviewed-by: default avatarChristian Borntraeger <borntraeger@linux.ibm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@linux.ibm.com>
      Reviewed-by: default avatarClaudio Imbrenda <imbrenda@linux.ibm.com>
      Link: https://lore.kernel.org/r/20230109145456.2895385-1-hca@linux.ibm.comSigned-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      42400d99
    • Heiko Carstens's avatar
      s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple() · e3f360db
      Heiko Carstens authored
      Make sure that *ptr__ within arch_this_cpu_to_op_simple() is only
      dereferenced once by using READ_ONCE(). Otherwise the compiler could
      generate incorrect code.
      
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      e3f360db
    • Heiko Carstens's avatar
      s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops · 82d3edb5
      Heiko Carstens authored
      The current cmpxchg_double() loops within the perf hw sampling code do not
      have READ_ONCE() semantics to read the old value from memory. This allows
      the compiler to generate code which reads the "old" value several times
      from memory, which again allows for inconsistencies.
      
      For example:
      
              /* Reset trailer (using compare-double-and-swap) */
              do {
                      te_flags = te->flags & ~SDB_TE_BUFFER_FULL_MASK;
                      te_flags |= SDB_TE_ALERT_REQ_MASK;
              } while (!cmpxchg_double(&te->flags, &te->overflow,
                       te->flags, te->overflow,
                       te_flags, 0ULL));
      
      The compiler could generate code where te->flags used within the
      cmpxchg_double() call may be refetched from memory and which is not
      necessarily identical to the previous read version which was used to
      generate te_flags. Which in turn means that an incorrect update could
      happen.
      
      Fix this by adding READ_ONCE() semantics to all cmpxchg_double()
      loops. Given that READ_ONCE() cannot generate code on s390 which atomically
      reads 16 bytes, use a private compare-and-swap-double implementation to
      achieve that.
      
      Also replace cmpxchg_double() with the private implementation to be able to
      re-use the old value within the loops.
      
      As a side effect this converts the whole code to only use bit fields
      to read and modify bits within the hws trailer header.
      Reported-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Acked-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Acked-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Reviewed-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/linux-s390/Y71QJBhNTIatvxUT@osiris/T/#ma14e2a5f7aa8ed4b94b6f9576799b3ad9c60f333Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      82d3edb5
    • Mark Brown's avatar
      spi: Merge rename of spi-cs-setup-ns DT property · b442990d
      Mark Brown authored
      The newly added spi-cs-setup-ns doesn't really fit with the existing
      property names for delays, rename it so that it does before it makes it
      into a release and becomes ABI.
      b442990d