From: Greg Kroah-Hartman Date: Mon, 2 Jan 2023 10:43:20 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v6.0.17~19 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5887fc3aa2f99b4ed0ee7db7b90957a531b17200;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: futex-fix-futex_waitv-hrtimer-debug-object-leak-on-kcalloc-error.patch hfsplus-fix-bug-causing-custom-uid-and-gid-being-unable-to-be-assigned-with-mount.patch kmsan-export-kmsan_handle_urb.patch kmsan-include-linux-vmalloc.h.patch mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.patch mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch pstore-properly-assign-mem_type-property.patch pstore-zone-use-gfp_atomic-to-allocate-zone-buffer.patch rtmutex-add-acquire-semantics-for-rtmutex-lock-acquisition-slow-path.patch --- diff --git a/queue-6.1/futex-fix-futex_waitv-hrtimer-debug-object-leak-on-kcalloc-error.patch b/queue-6.1/futex-fix-futex_waitv-hrtimer-debug-object-leak-on-kcalloc-error.patch new file mode 100644 index 00000000000..3408145c1e5 --- /dev/null +++ b/queue-6.1/futex-fix-futex_waitv-hrtimer-debug-object-leak-on-kcalloc-error.patch @@ -0,0 +1,55 @@ +From 94cd8fa09f5f1ebdd4e90964b08b7f2cc4b36c43 Mon Sep 17 00:00:00 2001 +From: Mathieu Desnoyers +Date: Wed, 14 Dec 2022 17:20:08 -0500 +Subject: futex: Fix futex_waitv() hrtimer debug object leak on kcalloc error + +From: Mathieu Desnoyers + +commit 94cd8fa09f5f1ebdd4e90964b08b7f2cc4b36c43 upstream. + +In a scenario where kcalloc() fails to allocate memory, the futex_waitv +system call immediately returns -ENOMEM without invoking +destroy_hrtimer_on_stack(). When CONFIG_DEBUG_OBJECTS_TIMERS=y, this +results in leaking a timer debug object. + +Fixes: bf69bad38cf6 ("futex: Implement sys_futex_waitv()") +Signed-off-by: Mathieu Desnoyers +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Davidlohr Bueso +Cc: stable@vger.kernel.org +Cc: stable@vger.kernel.org # v5.16+ +Link: https://lore.kernel.org/r/20221214222008.200393-1-mathieu.desnoyers@efficios.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/futex/syscalls.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/kernel/futex/syscalls.c ++++ b/kernel/futex/syscalls.c +@@ -286,19 +286,22 @@ SYSCALL_DEFINE5(futex_waitv, struct fute + } + + futexv = kcalloc(nr_futexes, sizeof(*futexv), GFP_KERNEL); +- if (!futexv) +- return -ENOMEM; ++ if (!futexv) { ++ ret = -ENOMEM; ++ goto destroy_timer; ++ } + + ret = futex_parse_waitv(futexv, waiters, nr_futexes); + if (!ret) + ret = futex_wait_multiple(futexv, nr_futexes, timeout ? &to : NULL); + ++ kfree(futexv); ++ ++destroy_timer: + if (timeout) { + hrtimer_cancel(&to.timer); + destroy_hrtimer_on_stack(&to.timer); + } +- +- kfree(futexv); + return ret; + } + diff --git a/queue-6.1/hfsplus-fix-bug-causing-custom-uid-and-gid-being-unable-to-be-assigned-with-mount.patch b/queue-6.1/hfsplus-fix-bug-causing-custom-uid-and-gid-being-unable-to-be-assigned-with-mount.patch new file mode 100644 index 00000000000..f5efaa7c268 --- /dev/null +++ b/queue-6.1/hfsplus-fix-bug-causing-custom-uid-and-gid-being-unable-to-be-assigned-with-mount.patch @@ -0,0 +1,71 @@ +From 9f2b5debc07073e6dfdd774e3594d0224b991927 Mon Sep 17 00:00:00 2001 +From: Aditya Garg +Date: Wed, 7 Dec 2022 03:05:40 +0000 +Subject: hfsplus: fix bug causing custom uid and gid being unable to be assigned with mount + +From: Aditya Garg + +commit 9f2b5debc07073e6dfdd774e3594d0224b991927 upstream. + +Despite specifying UID and GID in mount command, the specified UID and GID +were not being assigned. This patch fixes this issue. + +Link: https://lkml.kernel.org/r/C0264BF5-059C-45CF-B8DA-3A3BD2C803A2@live.com +Signed-off-by: Aditya Garg +Reviewed-by: Viacheslav Dubeyko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/hfsplus/hfsplus_fs.h | 2 ++ + fs/hfsplus/inode.c | 4 ++-- + fs/hfsplus/options.c | 4 ++++ + 3 files changed, 8 insertions(+), 2 deletions(-) + +--- a/fs/hfsplus/hfsplus_fs.h ++++ b/fs/hfsplus/hfsplus_fs.h +@@ -198,6 +198,8 @@ struct hfsplus_sb_info { + #define HFSPLUS_SB_HFSX 3 + #define HFSPLUS_SB_CASEFOLD 4 + #define HFSPLUS_SB_NOBARRIER 5 ++#define HFSPLUS_SB_UID 6 ++#define HFSPLUS_SB_GID 7 + + static inline struct hfsplus_sb_info *HFSPLUS_SB(struct super_block *sb) + { +--- a/fs/hfsplus/inode.c ++++ b/fs/hfsplus/inode.c +@@ -192,11 +192,11 @@ static void hfsplus_get_perms(struct ino + mode = be16_to_cpu(perms->mode); + + i_uid_write(inode, be32_to_cpu(perms->owner)); +- if (!i_uid_read(inode) && !mode) ++ if ((test_bit(HFSPLUS_SB_UID, &sbi->flags)) || (!i_uid_read(inode) && !mode)) + inode->i_uid = sbi->uid; + + i_gid_write(inode, be32_to_cpu(perms->group)); +- if (!i_gid_read(inode) && !mode) ++ if ((test_bit(HFSPLUS_SB_GID, &sbi->flags)) || (!i_gid_read(inode) && !mode)) + inode->i_gid = sbi->gid; + + if (dir) { +--- a/fs/hfsplus/options.c ++++ b/fs/hfsplus/options.c +@@ -140,6 +140,8 @@ int hfsplus_parse_options(char *input, s + if (!uid_valid(sbi->uid)) { + pr_err("invalid uid specified\n"); + return 0; ++ } else { ++ set_bit(HFSPLUS_SB_UID, &sbi->flags); + } + break; + case opt_gid: +@@ -151,6 +153,8 @@ int hfsplus_parse_options(char *input, s + if (!gid_valid(sbi->gid)) { + pr_err("invalid gid specified\n"); + return 0; ++ } else { ++ set_bit(HFSPLUS_SB_GID, &sbi->flags); + } + break; + case opt_part: diff --git a/queue-6.1/kmsan-export-kmsan_handle_urb.patch b/queue-6.1/kmsan-export-kmsan_handle_urb.patch new file mode 100644 index 00000000000..2a84ab89ab1 --- /dev/null +++ b/queue-6.1/kmsan-export-kmsan_handle_urb.patch @@ -0,0 +1,44 @@ +From 7ba594d700998bafa96a75360d2e060aa39156d2 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Thu, 15 Dec 2022 17:26:57 +0100 +Subject: kmsan: export kmsan_handle_urb + +From: Arnd Bergmann + +commit 7ba594d700998bafa96a75360d2e060aa39156d2 upstream. + +USB support can be in a loadable module, and this causes a link failure +with KMSAN: + +ERROR: modpost: "kmsan_handle_urb" [drivers/usb/core/usbcore.ko] undefined! + +Export the symbol so it can be used by this module. + +Link: https://lkml.kernel.org/r/20221215162710.3802378-1-arnd@kernel.org +Fixes: 553a80188a5d ("kmsan: handle memory sent to/from USB") +Signed-off-by: Arnd Bergmann +Reviewed-by: Alexander Potapenko +Cc: Dmitry Vyukov +Cc: Marco Elver +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmsan/hooks.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c +index 35f6b6e6a908..3807502766a3 100644 +--- a/mm/kmsan/hooks.c ++++ b/mm/kmsan/hooks.c +@@ -260,6 +260,7 @@ void kmsan_handle_urb(const struct urb *urb, bool is_out) + urb->transfer_buffer_length, + /*checked*/ false); + } ++EXPORT_SYMBOL_GPL(kmsan_handle_urb); + + static void kmsan_handle_dma_page(const void *addr, size_t size, + enum dma_data_direction dir) +-- +2.39.0 + diff --git a/queue-6.1/kmsan-include-linux-vmalloc.h.patch b/queue-6.1/kmsan-include-linux-vmalloc.h.patch new file mode 100644 index 00000000000..2ce970ecc0b --- /dev/null +++ b/queue-6.1/kmsan-include-linux-vmalloc.h.patch @@ -0,0 +1,49 @@ +From aaa746ad8b30f38ef89a301faf339ef1c19cf33a Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Thu, 15 Dec 2022 17:30:17 +0100 +Subject: kmsan: include linux/vmalloc.h + +From: Arnd Bergmann + +commit aaa746ad8b30f38ef89a301faf339ef1c19cf33a upstream. + +This is needed for the vmap/vunmap declarations: + +mm/kmsan/kmsan_test.c:316:9: error: implicit declaration of function 'vmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL); + ^ +mm/kmsan/kmsan_test.c:316:29: error: use of undeclared identifier 'VM_MAP' + vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL); + ^ +mm/kmsan/kmsan_test.c:322:3: error: implicit declaration of function 'vunmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + vunmap(vbuf); + ^ + +Link: https://lkml.kernel.org/r/20221215163046.4079767-1-arnd@kernel.org +Fixes: 8ed691b02ade ("kmsan: add tests for KMSAN") +Signed-off-by: Arnd Bergmann +Reviewed-by: Alexander Potapenko +Cc: Dmitry Vyukov +Cc: Marco Elver +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmsan/kmsan_test.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/mm/kmsan/kmsan_test.c b/mm/kmsan/kmsan_test.c +index eb44ef3c5f29..088e21a48dc4 100644 +--- a/mm/kmsan/kmsan_test.c ++++ b/mm/kmsan/kmsan_test.c +@@ -22,6 +22,7 @@ + #include + #include + #include ++#include + #include + + static DEFINE_PER_CPU(int, per_cpu_var); +-- +2.39.0 + diff --git a/queue-6.1/mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.patch b/queue-6.1/mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.patch new file mode 100644 index 00000000000..a70d5464023 --- /dev/null +++ b/queue-6.1/mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.patch @@ -0,0 +1,51 @@ +From 38ce7c9bdfc228c14d7621ba36d3eebedd9d4f76 Mon Sep 17 00:00:00 2001 +From: Mathieu Desnoyers +Date: Thu, 15 Dec 2022 14:46:21 -0500 +Subject: mm/mempolicy: fix memory leak in set_mempolicy_home_node system call + +From: Mathieu Desnoyers + +commit 38ce7c9bdfc228c14d7621ba36d3eebedd9d4f76 upstream. + +When encountering any vma in the range with policy other than MPOL_BIND or +MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on +the policy just allocated with mpol_dup(). + +This allows arbitrary users to leak kernel memory. + +Link: https://lkml.kernel.org/r/20221215194621.202816-1-mathieu.desnoyers@efficios.com +Fixes: c6018b4b2549 ("mm/mempolicy: add set_mempolicy_home_node syscall") +Signed-off-by: Mathieu Desnoyers +Reviewed-by: Randy Dunlap +Reviewed-by: "Huang, Ying" +Reviewed-by: Aneesh Kumar K.V +Acked-by: Michal Hocko +Cc: Aneesh Kumar K.V +Cc: Dave Hansen +Cc: Feng Tang +Cc: Michal Hocko +Cc: Andrea Arcangeli +Cc: Mel Gorman +Cc: Mike Kravetz +Cc: Randy Dunlap +Cc: Vlastimil Babka +Cc: Andi Kleen +Cc: Dan Williams +Cc: Huang Ying +Cc: [5.17+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/mempolicy.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -1540,6 +1540,7 @@ SYSCALL_DEFINE4(set_mempolicy_home_node, + * the home node for vmas we already updated before. + */ + if (new->mode != MPOL_BIND && new->mode != MPOL_PREFERRED_MANY) { ++ mpol_put(new); + err = -EOPNOTSUPP; + break; + } diff --git a/queue-6.1/mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch b/queue-6.1/mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch new file mode 100644 index 00000000000..6ac9fed4e3a --- /dev/null +++ b/queue-6.1/mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch @@ -0,0 +1,57 @@ +From 6f12be792fde994ed934168f93c2a0d2a0cf0bc5 Mon Sep 17 00:00:00 2001 +From: Vlastimil Babka +Date: Fri, 16 Dec 2022 17:32:27 +0100 +Subject: mm, mremap: fix mremap() expanding vma with addr inside vma +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Vlastimil Babka + +commit 6f12be792fde994ed934168f93c2a0d2a0cf0bc5 upstream. + +Since 6.1 we have noticed random rpm install failures that were tracked to +mremap() returning -ENOMEM and to commit ca3d76b0aa80 ("mm: add merging +after mremap resize"). + +The problem occurs when mremap() expands a VMA in place, but using an +starting address that's not vma->vm_start, but somewhere in the middle. +The extension_pgoff calculation introduced by the commit is wrong in that +case, so vma_merge() fails due to pgoffs not being compatible. Fix the +calculation. + +By the way it seems that the situations, where rpm now expands a vma from +the middle, were made possible also due to that commit, thanks to the +improved vma merging. Yet it should work just fine, except for the buggy +calculation. + +Link: https://lkml.kernel.org/r/20221216163227.24648-1-vbabka@suse.cz +Reported-by: Jiri Slaby + Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359 +Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize") +Signed-off-by: Vlastimil Babka +Cc: Jakub Matěna +Cc: "Kirill A . Shutemov" +Cc: Liam Howlett +Cc: Matthew Wilcox +Cc: Mel Gorman +Cc: Michal Hocko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/mremap.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -1016,7 +1016,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, a + long pages = (new_len - old_len) >> PAGE_SHIFT; + unsigned long extension_start = addr + old_len; + unsigned long extension_end = addr + new_len; +- pgoff_t extension_pgoff = vma->vm_pgoff + (old_len >> PAGE_SHIFT); ++ pgoff_t extension_pgoff = vma->vm_pgoff + ++ ((extension_start - vma->vm_start) >> PAGE_SHIFT); + + if (vma->vm_flags & VM_ACCOUNT) { + if (security_vm_enough_memory_mm(mm, pages)) { diff --git a/queue-6.1/pstore-properly-assign-mem_type-property.patch b/queue-6.1/pstore-properly-assign-mem_type-property.patch new file mode 100644 index 00000000000..d3b34e8be97 --- /dev/null +++ b/queue-6.1/pstore-properly-assign-mem_type-property.patch @@ -0,0 +1,42 @@ +From beca3e311a49cd3c55a056096531737d7afa4361 Mon Sep 17 00:00:00 2001 +From: Luca Stefani +Date: Thu, 22 Dec 2022 14:10:49 +0100 +Subject: pstore: Properly assign mem_type property + +From: Luca Stefani + +commit beca3e311a49cd3c55a056096531737d7afa4361 upstream. + +If mem-type is specified in the device tree +it would end up overriding the record_size +field instead of populating mem_type. + +As record_size is currently parsed after the +improper assignment with default size 0 it +continued to work as expected regardless of the +value found in the device tree. + +Simply changing the target field of the struct +is enough to get mem-type working as expected. + +Fixes: 9d843e8fafc7 ("pstore: Add mem_type property DT parsing support") +Cc: stable@vger.kernel.org +Signed-off-by: Luca Stefani +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/20221222131049.286288-1-luca@osomprivacy.com +Signed-off-by: Greg Kroah-Hartman +--- + fs/pstore/ram.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/pstore/ram.c ++++ b/fs/pstore/ram.c +@@ -670,7 +670,7 @@ static int ramoops_parse_dt(struct platf + field = value; \ + } + +- parse_u32("mem-type", pdata->record_size, pdata->mem_type); ++ parse_u32("mem-type", pdata->mem_type, pdata->mem_type); + parse_u32("record-size", pdata->record_size, 0); + parse_u32("console-size", pdata->console_size, 0); + parse_u32("ftrace-size", pdata->ftrace_size, 0); diff --git a/queue-6.1/pstore-zone-use-gfp_atomic-to-allocate-zone-buffer.patch b/queue-6.1/pstore-zone-use-gfp_atomic-to-allocate-zone-buffer.patch new file mode 100644 index 00000000000..13758abb427 --- /dev/null +++ b/queue-6.1/pstore-zone-use-gfp_atomic-to-allocate-zone-buffer.patch @@ -0,0 +1,36 @@ +From 99b3b837855b987563bcfb397cf9ddd88262814b Mon Sep 17 00:00:00 2001 +From: Qiujun Huang +Date: Sun, 4 Sep 2022 23:17:13 +0800 +Subject: pstore/zone: Use GFP_ATOMIC to allocate zone buffer + +From: Qiujun Huang + +commit 99b3b837855b987563bcfb397cf9ddd88262814b upstream. + +There is a case found when triggering a panic_on_oom, pstore fails to dump +kmsg. Because psz_kmsg_write_record can't get the new buffer. + +Handle this by using GFP_ATOMIC to allocate a buffer at lower watermark. + +Signed-off-by: Qiujun Huang +Fixes: 335426c6dcdd ("pstore/zone: Provide way to skip "broken" zone for MTD devices") +Cc: WeiXiong Liao +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/CAJRQjofRCF7wjrYmw3D7zd5QZnwHQq+F8U-mJDJ6NZ4bddYdLA@mail.gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + fs/pstore/zone.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/pstore/zone.c ++++ b/fs/pstore/zone.c +@@ -761,7 +761,7 @@ static inline int notrace psz_kmsg_write + /* avoid destroying old data, allocate a new one */ + len = zone->buffer_size + sizeof(*zone->buffer); + zone->oldbuf = zone->buffer; +- zone->buffer = kzalloc(len, GFP_KERNEL); ++ zone->buffer = kzalloc(len, GFP_ATOMIC); + if (!zone->buffer) { + zone->buffer = zone->oldbuf; + return -ENOMEM; diff --git a/queue-6.1/rtmutex-add-acquire-semantics-for-rtmutex-lock-acquisition-slow-path.patch b/queue-6.1/rtmutex-add-acquire-semantics-for-rtmutex-lock-acquisition-slow-path.patch new file mode 100644 index 00000000000..868afa775de --- /dev/null +++ b/queue-6.1/rtmutex-add-acquire-semantics-for-rtmutex-lock-acquisition-slow-path.patch @@ -0,0 +1,219 @@ +From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 +From: Mel Gorman +Date: Fri, 2 Dec 2022 10:02:23 +0000 +Subject: rtmutex: Add acquire semantics for rtmutex lock acquisition slow path + +From: Mel Gorman + +commit 1c0908d8e441631f5b8ba433523cf39339ee2ba0 upstream. + +Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench +on XFS on arm64. + + kernel BUG at fs/inode.c:625! + Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP + CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 + pc : clear_inode+0xa0/0xc0 + lr : clear_inode+0x38/0xc0 + Call trace: + clear_inode+0xa0/0xc0 + evict+0x160/0x180 + iput+0x154/0x240 + do_unlinkat+0x184/0x300 + __arm64_sys_unlinkat+0x48/0xc0 + el0_svc_common.constprop.4+0xe4/0x2c0 + do_el0_svc+0xac/0x100 + el0_svc+0x78/0x200 + el0t_64_sync_handler+0x9c/0xc0 + el0t_64_sync+0x19c/0x1a0 + +It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this +is likely a bug that existed forever and only became visible when ARM +support was added to preempt-rt. The same problem does not occur on x86-64 +and he also reported that converting sb->s_inode_wblist_lock to +raw_spinlock_t makes the problem disappear indicating that the RT spinlock +variant is the problem. + +Which in turn means that RT mutexes on ARM64 and any other weakly ordered +architecture are affected by this independent of RT. + +Will Deacon observed: + + "I'd be more inclined to be suspicious of the slowpath tbh, as we need to + make sure that we have acquire semantics on all paths where the lock can + be taken. Looking at the rtmutex code, this really isn't obvious to me + -- for example, try_to_take_rt_mutex() appears to be able to return via + the 'takeit' label without acquire semantics and it looks like we might + be relying on the caller's subsequent _unlock_ of the wait_lock for + ordering, but that will give us release semantics which aren't correct." + +Sebastian Andrzej Siewior prototyped a fix that does work based on that +comment but it was a little bit overkill and added some fences that should +not be necessary. + +The lock owner is updated with an IRQ-safe raw spinlock held, but the +spin_unlock does not provide acquire semantics which are needed when +acquiring a mutex. + +Adds the necessary acquire semantics for lock owner updates in the slow path +acquisition and the waiter bit logic. + +It successfully completed 10 iterations of the dbench workload while the +vanilla kernel fails on the first iteration. + +[ bigeasy@linutronix.de: Initial prototype fix ] + +Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") +Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") +Reported-by: Jan Kara +Signed-off-by: Mel Gorman +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.net +Signed-off-by: Greg Kroah-Hartman +--- + kernel/locking/rtmutex.c | 55 +++++++++++++++++++++++++++++++++++-------- + kernel/locking/rtmutex_api.c | 6 ++-- + 2 files changed, 49 insertions(+), 12 deletions(-) + +--- a/kernel/locking/rtmutex.c ++++ b/kernel/locking/rtmutex.c +@@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill( + * set this bit before looking at the lock. + */ + +-static __always_inline void +-rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) ++static __always_inline struct task_struct * ++rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) + { + unsigned long val = (unsigned long)owner; + + if (rt_mutex_has_waiters(lock)) + val |= RT_MUTEX_HAS_WAITERS; + +- WRITE_ONCE(lock->owner, (struct task_struct *)val); ++ return (struct task_struct *)val; ++} ++ ++static __always_inline void ++rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) ++{ ++ /* ++ * lock->wait_lock is held but explicit acquire semantics are needed ++ * for a new lock owner so WRITE_ONCE is insufficient. ++ */ ++ xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); ++} ++ ++static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) ++{ ++ /* lock->wait_lock is held so the unlock provides release semantics. */ ++ WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); + } + + static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) +@@ -106,7 +122,8 @@ static __always_inline void clear_rt_mut + ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); + } + +-static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) ++static __always_inline void ++fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) + { + unsigned long owner, *p = (unsigned long *) &lock->owner; + +@@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mut + * still set. + */ + owner = READ_ONCE(*p); +- if (owner & RT_MUTEX_HAS_WAITERS) +- WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); ++ if (owner & RT_MUTEX_HAS_WAITERS) { ++ /* ++ * See rt_mutex_set_owner() and rt_mutex_clear_owner() on ++ * why xchg_acquire() is used for updating owner for ++ * locking and WRITE_ONCE() for unlocking. ++ * ++ * WRITE_ONCE() would work for the acquire case too, but ++ * in case that the lock acquisition failed it might ++ * force other lockers into the slow path unnecessarily. ++ */ ++ if (acquire_lock) ++ xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); ++ else ++ WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); ++ } + } + + /* +@@ -208,6 +238,13 @@ static __always_inline void mark_rt_mute + owner = *p; + } while (cmpxchg_relaxed(p, owner, + owner | RT_MUTEX_HAS_WAITERS) != owner); ++ ++ /* ++ * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE ++ * operations in the event of contention. Ensure the successful ++ * cmpxchg is visible. ++ */ ++ smp_mb__after_atomic(); + } + + /* +@@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtryloc + * try_to_take_rt_mutex() sets the lock waiters bit + * unconditionally. Clean this up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + + return ret; + } +@@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(s + * try_to_take_rt_mutex() sets the waiter bit + * unconditionally. We might have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + + trace_contention_end(lock, ret); + +@@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_lock + * try_to_take_rt_mutex() sets the waiter bit unconditionally. + * We might have to fix that up: + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + debug_rt_mutex_free_waiter(&waiter); + + trace_contention_end(lock, 0); +--- a/kernel/locking/rtmutex_api.c ++++ b/kernel/locking/rtmutex_api.c +@@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked( + void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) + { + debug_rt_mutex_proxy_unlock(lock); +- rt_mutex_set_owner(lock, NULL); ++ rt_mutex_clear_owner(lock); + } + + /** +@@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(str + * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might + * have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + raw_spin_unlock_irq(&lock->wait_lock); + + return ret; +@@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock + * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might + * have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, false); + + raw_spin_unlock_irq(&lock->wait_lock); + diff --git a/queue-6.1/series b/queue-6.1/series index 29419541a90..a9aff00c7b8 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -40,3 +40,12 @@ nfsd-fix-use-after-free-in-__nfs42_ssc_open.patch kprobes-kretprobe-events-missing-on-2-core-kvm-guest.patch hid-multitouch-fix-asus-expertbook-p2-p2451fa-trackp.patch hid-plantronics-additional-pids-for-double-volume-ke.patch +futex-fix-futex_waitv-hrtimer-debug-object-leak-on-kcalloc-error.patch +rtmutex-add-acquire-semantics-for-rtmutex-lock-acquisition-slow-path.patch +mm-mremap-fix-mremap-expanding-vma-with-addr-inside-vma.patch +mm-mempolicy-fix-memory-leak-in-set_mempolicy_home_node-system-call.patch +kmsan-export-kmsan_handle_urb.patch +kmsan-include-linux-vmalloc.h.patch +pstore-properly-assign-mem_type-property.patch +pstore-zone-use-gfp_atomic-to-allocate-zone-buffer.patch +hfsplus-fix-bug-causing-custom-uid-and-gid-being-unable-to-be-assigned-with-mount.patch