1. 19 Mar, 2022 30 commits
  2. 16 Mar, 2022 10 commits
    • Oleksandr Natalenko's avatar
      Merge tag 'v5.16.15' into pf-5.16 · 1aeaa72c
      Oleksandr Natalenko authored
      This is the 5.16.15 stable release
      1aeaa72c
    • Oleksandr Natalenko's avatar
      f2559940
    • Greg Kroah-Hartman's avatar
    • Jason Wang's avatar
      vhost: allow batching hint without size · ad7aa686
      Jason Wang authored
      commit 95932ab2 upstream.
      
      Commit e2ae38cf ("vhost: fix hung thread due to erroneous iotlb
      entries") tries to reject the IOTLB message whose size is zero. But
      the size is not necessarily meaningful, one example is the batching
      hint, so the commit breaks that.
      
      Fixing this be reject zero size message only if the message is used to
      update/invalidate the IOTLB.
      
      Fixes: e2ae38cf
      
       ("vhost: fix hung thread due to erroneous iotlb entries")
      Reported-by: default avatarEli Cohen <elic@nvidia.com>
      Cc: Anirudh Rayabharam <mail@anirudhrb.com>
      Signed-off-by: Jason Wang's avatarJason Wang <jasowang@redhat.com>
      Link: https://lore.kernel.org/r/20220310075211.4801-1-jasowang@redhat.com
      
      Signed-off-by: MST's avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarEli Cohen <elic@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad7aa686
    • Niklas Cassel's avatar
      riscv: dts: k210: fix broken IRQs on hart1 · 2777252d
      Niklas Cassel authored
      commit 74583f1b upstream.
      
      Commit 67d96729 ("riscv: Update Canaan Kendryte K210 device tree")
      incorrectly removed two entries from the PLIC interrupt-controller node's
      interrupts-extended property.
      
      The PLIC driver cannot know the mapping between hart contexts and hart ids,
      so this information has to be provided by device tree, as specified by the
      PLIC device tree binding.
      
      The PLIC driver uses the interrupts-extended property, and initializes the
      hart context registers in the exact same order as provided by the
      interrupts-extended property.
      
      In other words, if we don't specify the S-mode interrupts, the PLIC driver
      will simply initialize the hart0 S-mode hart context with the hart1 M-mode
      configuration. It is therefore essential to specify the S-mode IRQs even
      though the system itself will only ever be running in M-mode.
      
      Re-add the S-mode interrupts, so that we get working IRQs on hart1 again.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 67d96729
      
       ("riscv: Update Canaan Kendryte K210 device tree")
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@wdc.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2777252d
    • Filipe Manana's avatar
      btrfs: make send work with concurrent block group relocation · 00a74293
      Filipe Manana authored
      commit d96b3424 upstream.
      
      We don't allow send and balance/relocation to run in parallel in order
      to prevent send failing or silently producing some bad stream. This is
      because while send is using an extent (specially metadata) or about to
      read a metadata extent and expecting it belongs to a specific parent
      node, relocation can run, the transaction used for the relocation is
      committed and the extent gets reallocated while send is still using the
      extent, so it ends up with a different content than expected. This can
      result in just failing to read a metadata extent due to failure of the
      validation checks (parent transid, level, etc), failure to find a
      backreference for a data extent, and other unexpected failures. Besides
      reallocation, there's also a similar problem of an extent getting
      discarded when it's unpinned after the transaction used for block group
      relocation is committed.
      
      The restriction between balance and send was added in commit 9e967495
      ("Btrfs: prevent send failures and crashes due to concurrent relocation"),
      kernel 5.3, while the more general restriction between send and relocation
      was added in commit 1cea5cf0
      
       ("btrfs: ensure relocation never runs
      while we have send operations running"), kernel 5.14.
      
      Both send and relocation can be very long running operations. Relocation
      because it has to do a lot of IO and expensive backreference lookups in
      case there are many snapshots, and send due to read IO when operating on
      very large trees. This makes it inconvenient for users and tools to deal
      with scheduling both operations.
      
      For zoned filesystem we also have automatic block group relocation, so
      send can fail with -EAGAIN when users least expect it or send can end up
      delaying the block group relocation for too long. In the future we might
      also get the automatic block group relocation for non zoned filesystems.
      
      This change makes it possible for send and relocation to run in parallel.
      This is achieved the following way:
      
      1) For all tree searches, send acquires a read lock on the commit root
         semaphore;
      
      2) After each tree search, and before releasing the commit root semaphore,
         the leaf is cloned and placed in the search path (struct btrfs_path);
      
      3) After releasing the commit root semaphore, the changed_cb() callback
         is invoked, which operates on the leaf and writes commands to the pipe
         (or file in case send/receive is not used with a pipe). It's important
         here to not hold a lock on the commit root semaphore, because if we did
         we could deadlock when sending and receiving to the same filesystem
         using a pipe - the send task blocks on the pipe because it's full, the
         receive task, which is the only consumer of the pipe, triggers a
         transaction commit when attempting to create a subvolume or reserve
         space for a write operation for example, but the transaction commit
         blocks trying to write lock the commit root semaphore, resulting in a
         deadlock;
      
      4) Before moving to the next key, or advancing to the next change in case
         of an incremental send, check if a transaction used for relocation was
         committed (or is about to finish its commit). If so, release the search
         path(s) and restart the search, to where we were before, so that we
         don't operate on stale extent buffers. The search restarts are always
         possible because both the send and parent roots are RO, and no one can
         add, remove of update keys (change their offset) in RO trees - the
         only exception is deduplication, but that is still not allowed to run
         in parallel with send;
      
      5) Periodically check if there is contention on the commit root semaphore,
         which means there is a transaction commit trying to write lock it, and
         release the semaphore and reschedule if there is contention, so as to
         avoid causing any significant delays to transaction commits.
      
      This leaves some room for optimizations for send to have less path
      releases and re searching the trees when there's relocation running, but
      for now it's kept simple as it performs quite well (on very large trees
      with resulting send streams in the order of a few hundred gigabytes).
      
      Test case btrfs/187, from fstests, stresses relocation, send and
      deduplication attempting to run in parallel, but without verifying if send
      succeeds and if it produces correct streams. A new test case will be added
      that exercises relocation happening in parallel with send and then checks
      that send succeeds and the resulting streams are correct.
      
      A final note is that for now this still leaves the mutual exclusion
      between send operations and deduplication on files belonging to a root
      used by send operations. A solution for that will be slightly more complex
      but it will eventually be built on top of this change.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: Anand Jain's avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00a74293
    • Zhengjun Xing's avatar
      perf parse: Fix event parser error for hybrid systems · 7c3ebd47
      Zhengjun Xing authored
      commit 91c9923a upstream.
      
      This bug happened on hybrid systems when both cpu_core and cpu_atom
      have the same event name such as "UOPS_RETIRED.MS" while their event
      terms are different, then during perf stat, the event for cpu_atom
      will parse fail and then no output for cpu_atom.
      
      UOPS_RETIRED.MS -> cpu_core/period=0x1e8483,umask=0x4,event=0xc2,frontend=0x8/
      UOPS_RETIRED.MS -> cpu_atom/period=0x1e8483,umask=0x1,event=0xc2/
      
      It is because event terms in the "head" of parse_events_multi_pmu_add
      will be changed to event terms for cpu_core after parsing UOPS_RETIRED.MS
      for cpu_core, then when parsing the same event for cpu_atom, it still
      uses the event terms for cpu_core, but event terms for cpu_atom are
      different with cpu_core, the event parses for cpu_atom will fail. This
      patch fixes it, the event terms should be parsed from the original
      event.
      
      This patch can work for the hybrid systems that have the same event
      in more than 2 PMUs. It also can work in non-hybrid systems.
      
      Before:
      
        # perf stat -v  -e  UOPS_RETIRED.MS  -a sleep 1
      
        Using CPUID GenuineIntel-6-97-1
        UOPS_RETIRED.MS -> cpu_core/period=0x1e8483,umask=0x4,event=0xc2,frontend=0x8/
        Control descriptor is not initialized
        UOPS_RETIRED.MS: 2737845 16068518485 16068518485
      
       Performance counter stats for 'system wide':
      
               2,737,845      cpu_core/UOPS_RETIRED.MS/
      
             1.002553850 seconds time elapsed
      
      After:
      
        # perf stat -v  -e  UOPS_RETIRED.MS  -a sleep 1
      
        Using CPUID GenuineIntel-6-97-1
        UOPS_RETIRED.MS -> cpu_core/period=0x1e8483,umask=0x4,event=0xc2,frontend=0x8/
        UOPS_RETIRED.MS -> cpu_atom/period=0x1e8483,umask=0x1,event=0xc2/
        Control descriptor is not initialized
        UOPS_RETIRED.MS: 1977555 16076950711 16076950711
        UOPS_RETIRED.MS: 568684 8038694234 8038694234
      
       Performance counter stats for 'system wide':
      
               1,977,555      cpu_core/UOPS_RETIRED.MS/
                 568,684      cpu_atom/UOPS_RETIRED.MS/
      
             1.004758259 seconds time elapsed
      
      Fixes: fb081153
      
       ("perf parse-events: Allow config on kernel PMU events")
      Reviewed-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarZhengjun Xing <zhengjun.xing@linux.intel.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20220307151627.30049-1-zhengjun.xing@linux.intel.com
      
      Signed-off-by: Arnaldo Melo's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c3ebd47
    • Thomas Zimmermann's avatar
      drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP · 8185af33
      Thomas Zimmermann authored
      commit 3755d35e
      
       upstream.
      
      As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
      the option to fix the build failure. The error message is shown
      below.
      
        arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function
          `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to
          `drm_panel_dp_aux_backlight'
        make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1
      
      The issue has been reported before, when DisplayPort helpers were
      hidden behind the option CONFIG_DRM_KMS_HELPER. [2]
      
      v2:
      	* fix and expand commit description (Arnd)
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Fixes: 9d6366e7
      
       ("drm: fb_helper: improve CONFIG_FB dependency")
      Reported-by: Naresh Kamboju's avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Reported-by: ghost-82353-658473's avatarLinux Kernel Functional Testing <lkft@linaro.org>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://lore.kernel.org/dri-devel/CA+G9fYvN0NyaVkRQmA1O6rX7H8PPaZrUAD7=RDy33QY9rUU-9g@mail.gmail.com/ # [1]
      Link: https://lore.kernel.org/all/20211117062704.14671-1-rdunlap@infradead.org/ # [2]
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: dri-devel@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20220203093922.20754-1-tzimmermann@suse.de
      
      Signed-off-by: David Airlie's avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8185af33
    • Li Huafei's avatar
      x86/traps: Mark do_int3() NOKPROBE_SYMBOL · aa093e28
      Li Huafei authored
      commit a365a65f upstream.
      
      Since kprobe_int3_handler() is called in do_int3(), probing do_int3()
      can cause a breakpoint recursion and crash the kernel. Therefore,
      do_int3() should be marked as NOKPROBE_SYMBOL.
      
      Fixes: 21e28290
      
       ("x86/traps: Split int3 handler up")
      Signed-off-by: default avatarLi Huafei <lihuafei1@huawei.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220310120915.63349-1-lihuafei1@huawei.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa093e28
    • Jarkko Sakkinen's avatar
      x86/sgx: Free backing memory after faulting the enclave page · 248c6347
      Jarkko Sakkinen authored
      commit 08999b24 upstream.
      
      There is a limited amount of SGX memory (EPC) on each system.  When that
      memory is used up, SGX has its own swapping mechanism which is similar
      in concept but totally separate from the core mm/* code.  Instead of
      swapping to disk, SGX swaps from EPC to normal RAM.  That normal RAM
      comes from a shared memory pseudo-file and can itself be swapped by the
      core mm code.  There is a hierarchy like this:
      
      	EPC <-> shmem <-> disk
      
      After data is swapped back in from shmem to EPC, the shmem backing
      storage needs to be freed.  Currently, the backing shmem is not freed.
      This effectively wastes the shmem while the enclave is running.  The
      memory is recovered when the enclave is destroyed and the backing
      storage freed.
      
      Sort this out by freeing memory with shmem_truncate_range(), as soon as
      a page is faulted back to the EPC.  In addition, free the memory for
      PCMD pages as soon as all PCMD's in a page have been marked as unused
      by zeroing its contents.
      
      Cc: stable@vger.kernel.org
      Fixes: 1728ab54
      
       ("x86/sgx: Add a page reclaimer")
      Reported-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Link: https://lkml.kernel.org/r/20220303223859.273187-1-jarkko@kernel.org
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      248c6347