5.4-stable patches

added patches:
	drm-amdkfd-don-t-allow-mapping-the-mmio-hdp-page-with-large-pages.patch
	filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch
	ipc-replace-costly-bailout-check-in-sysvipc_find_ipc.patch

diff --git a/queue-5.4/drm-amdkfd-don-t-allow-mapping-the-mmio-hdp-page-with-large-pages.patch b/queue-5.4/drm-amdkfd-don-t-allow-mapping-the-mmio-hdp-page-with-large-pages.patch
new file mode 100644 (file)
index 0000000..73a7653
--- /dev/null
+++ b/queue-5.4/drm-amdkfd-don-t-allow-mapping-the-mmio-hdp-page-with-large-pages.patch
@@ -0,0 +1,47 @@
+From be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Sun, 14 Apr 2024 13:06:39 -0400
+Subject: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7 upstream.
+
+We don't get the right offset in that case.  The GPU has
+an unused 4K area of the register BAR space into which you can
+remap registers.  We remap the HDP flush registers into this
+space to allow userspace (CPU or GPU) to flush the HDP when it
+updates VRAM.  However, on systems with >4K pages, we end up
+exposing PAGE_SIZE of MMIO space.
+
+Fixes: d8e408a82704 ("drm/amdkfd: Expose HDP registers to user space")
+Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
++++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+@@ -1278,7 +1278,7 @@ static int kfd_ioctl_alloc_memory_of_gpu
+               if (args->size != PAGE_SIZE)
+                       return -EINVAL;
+               offset = amdgpu_amdkfd_get_mmio_remap_phys_addr(dev->kgd);
+-              if (!offset)
++              if (!offset || (PAGE_SIZE > 4096))
+                       return -ENOMEM;
+       }
+ 
+@@ -1872,6 +1872,9 @@ static int kfd_mmio_mmap(struct kfd_dev
+       if (vma->vm_end - vma->vm_start != PAGE_SIZE)
+               return -EINVAL;
+ 
++      if (PAGE_SIZE > 4096)
++              return -EINVAL;
++
+       address = amdgpu_amdkfd_get_mmio_remap_phys_addr(dev->kgd);
+ 
+       vma->vm_flags |= VM_IO | VM_DONTCOPY | VM_DONTEXPAND | VM_NORESERVE |

diff --git a/queue-5.4/filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch b/queue-5.4/filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch
new file mode 100644 (file)
index 0000000..ecb4738
--- /dev/null
+++ b/queue-5.4/filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch
@@ -0,0 +1,47 @@
+From leo.lilong@huawei.com  Fri Aug 30 13:11:50 2024
+From: Long Li <leo.lilong@huawei.com>
+Date: Fri, 16 Aug 2024 13:06:27 +0800
+Subject: filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64
+To: <stable@vger.kernel.org>
+Cc: <gregkh@linuxfoundation.org>, <jannh@google.com>, <leo.lilong@huawei.com>, <yangerkun@huawei.com>
+Message-ID: <20240816050627.2122228-1-leo.lilong@huawei.com>
+
+From: Long Li <leo.lilong@huawei.com>
+
+The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed
+to reliably remove locks when an fcntl/close race is detected. However, it
+was passing in the wrong filelock owner, it looks like a mistake and
+resulting in a failure to remove locks. More critically, if the lock
+removal fails, it could lead to a uaf issue while traversing the locks.
+
+This problem occurs only in the 4.19/5.4 stable version.
+
+Fixes: 4c43ad4ab416 ("filelock: Fix fcntl/close race recovery compat path")
+Fixes: dc2ce1dfceaa ("filelock: Remove locks reliably when fcntl/close race is detected")
+Cc: stable@vger.kernel.org
+Signed-off-by: Long Li <leo.lilong@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/locks.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/locks.c
++++ b/fs/locks.c
+@@ -2542,7 +2542,7 @@ int fcntl_setlk(unsigned int fd, struct
+               f = fcheck(fd);
+               spin_unlock(&current->files->file_lock);
+               if (f != filp) {
+-                      locks_remove_posix(filp, &current->files);
++                      locks_remove_posix(filp, current->files);
+                       error = -EBADF;
+               }
+       }
+@@ -2672,7 +2672,7 @@ int fcntl_setlk64(unsigned int fd, struc
+               f = fcheck(fd);
+               spin_unlock(&current->files->file_lock);
+               if (f != filp) {
+-                      locks_remove_posix(filp, &current->files);
++                      locks_remove_posix(filp, current->files);
+                       error = -EBADF;
+               }
+       }

diff --git a/queue-5.4/ipc-replace-costly-bailout-check-in-sysvipc_find_ipc.patch b/queue-5.4/ipc-replace-costly-bailout-check-in-sysvipc_find_ipc.patch
new file mode 100644 (file)
index 0000000..a8ae496
--- /dev/null
+++ b/queue-5.4/ipc-replace-costly-bailout-check-in-sysvipc_find_ipc.patch
@@ -0,0 +1,81 @@
+From 20401d1058f3f841f35a594ac2fc1293710e55b9 Mon Sep 17 00:00:00 2001
+From: Rafael Aquini <aquini@redhat.com>
+Date: Tue, 7 Sep 2021 20:00:53 -0700
+Subject: ipc: replace costly bailout check in sysvipc_find_ipc()
+
+From: Rafael Aquini <aquini@redhat.com>
+
+commit 20401d1058f3f841f35a594ac2fc1293710e55b9 upstream.
+
+sysvipc_find_ipc() was left with a costly way to check if the offset
+position fed to it is bigger than the total number of IPC IDs in use.  So
+much so that the time it takes to iterate over /proc/sysvipc/* files grows
+exponentially for a custom benchmark that creates "N" SYSV shm segments
+and then times the read of /proc/sysvipc/shm (milliseconds):
+
+    12 msecs to read   1024 segs from /proc/sysvipc/shm
+    18 msecs to read   2048 segs from /proc/sysvipc/shm
+    65 msecs to read   4096 segs from /proc/sysvipc/shm
+   325 msecs to read   8192 segs from /proc/sysvipc/shm
+  1303 msecs to read  16384 segs from /proc/sysvipc/shm
+  5182 msecs to read  32768 segs from /proc/sysvipc/shm
+
+The root problem lies with the loop that computes the total amount of ids
+in use to check if the "pos" feeded to sysvipc_find_ipc() grew bigger than
+"ids->in_use".  That is a quite inneficient way to get to the maximum
+index in the id lookup table, specially when that value is already
+provided by struct ipc_ids.max_idx.
+
+This patch follows up on the optimization introduced via commit
+15df03c879836 ("sysvipc: make get_maxid O(1) again") and gets rid of the
+aforementioned costly loop replacing it by a simpler checkpoint based on
+ipc_get_maxidx() returned value, which allows for a smooth linear increase
+in time complexity for the same custom benchmark:
+
+     2 msecs to read   1024 segs from /proc/sysvipc/shm
+     2 msecs to read   2048 segs from /proc/sysvipc/shm
+     4 msecs to read   4096 segs from /proc/sysvipc/shm
+     9 msecs to read   8192 segs from /proc/sysvipc/shm
+    19 msecs to read  16384 segs from /proc/sysvipc/shm
+    39 msecs to read  32768 segs from /proc/sysvipc/shm
+
+Link: https://lkml.kernel.org/r/20210809203554.1562989-1-aquini@redhat.com
+Signed-off-by: Rafael Aquini <aquini@redhat.com>
+Acked-by: Davidlohr Bueso <dbueso@suse.de>
+Acked-by: Manfred Spraul <manfred@colorfullife.com>
+Cc: Waiman Long <llong@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ ipc/util.c |   16 ++++------------
+ 1 file changed, 4 insertions(+), 12 deletions(-)
+
+--- a/ipc/util.c
++++ b/ipc/util.c
+@@ -754,21 +754,13 @@ struct pid_namespace *ipc_seq_pid_ns(str
+ static struct kern_ipc_perm *sysvipc_find_ipc(struct ipc_ids *ids, loff_t pos,
+                                             loff_t *new_pos)
+ {
+-      struct kern_ipc_perm *ipc;
+-      int total, id;
++      struct kern_ipc_perm *ipc = NULL;
++      int max_idx = ipc_get_maxidx(ids);
+ 
+-      total = 0;
+-      for (id = 0; id < pos && total < ids->in_use; id++) {
+-              ipc = idr_find(&ids->ipcs_idr, id);
+-              if (ipc != NULL)
+-                      total++;
+-      }
+-
+-      ipc = NULL;
+-      if (total >= ids->in_use)
++      if (max_idx == -1 || pos > max_idx)
+               goto out;
+ 
+-      for (; pos < ipc_mni; pos++) {
++      for (; pos <= max_idx; pos++) {
+               ipc = idr_find(&ids->ipcs_idr, pos);
+               if (ipc != NULL) {
+                       rcu_read_lock();

diff --git a/queue-5.4/series b/queue-5.4/series
index fa8dc2cacba0b0604342364981d85c9f65e32a55..51c42397a26355d9cf7ee2866201e32b4cb9d6dd 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -110,3 +110,6 @@ drm-amdgpu-using-uninitialized-value-size-when-calling-amdgpu_vce_cs_reloc.patch
 pinctrl-rockchip-correct-rk3328-iomux-width-flag-for-gpio2-b-pins.patch
 pinctrl-single-fix-potential-null-dereference-in-pcs_get_function.patch
 wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch
+ipc-replace-costly-bailout-check-in-sysvipc_find_ipc.patch
+drm-amdkfd-don-t-allow-mapping-the-mmio-hdp-page-with-large-pages.patch
+filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch