6.1-stable patches

added patches:
	fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
	x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch

diff --git a/queue-6.1/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch b/queue-6.1/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
new file mode 100644 (file)
index 0000000..fbfc0b4
--- /dev/null
+++ b/queue-6.1/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
@@ -0,0 +1,97 @@
+From 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 Mon Sep 17 00:00:00 2001
+From: Miaohe Lin <linmiaohe@huawei.com>
+Date: Wed, 10 Apr 2024 17:14:41 +0800
+Subject: fork: defer linking file vma until vma is fully initialized
+
+From: Miaohe Lin <linmiaohe@huawei.com>
+
+commit 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 upstream.
+
+Thorvald reported a WARNING [1]. And the root cause is below race:
+
+ CPU 1                                 CPU 2
+ fork                                  hugetlbfs_fallocate
+  dup_mmap                              hugetlbfs_punch_hole
+   i_mmap_lock_write(mapping);
+   vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree.
+   i_mmap_unlock_write(mapping);
+   hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem!
+                                        i_mmap_lock_write(mapping);
+                                        hugetlb_vmdelete_list
+                                         vma_interval_tree_foreach
+                                          hugetlb_vma_trylock_write -- Vma_lock is cleared.
+   tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem!
+                                          hugetlb_vma_unlock_write -- Vma_lock is assigned!!!
+                                        i_mmap_unlock_write(mapping);
+
+hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside
+i_mmap_rwsem lock while vma lock can be used in the same time.  Fix this
+by deferring linking file vma until vma is fully initialized.  Those vmas
+should be initialized first before they can be used.
+
+Link: https://lkml.kernel.org/r/20240410091441.3539905-1-linmiaohe@huawei.com
+Fixes: 8d9bfb260814 ("hugetlb: add vma based lock for pmd sharing")
+Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
+Reported-by: Thorvald Natvig <thorvald@google.com>
+Closes: https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/ [1]
+Reviewed-by: Jane Chu <jane.chu@oracle.com>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Heiko Carstens <hca@linux.ibm.com>
+Cc: Kent Overstreet <kent.overstreet@linux.dev>
+Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
+Cc: Mateusz Guzik <mjguzik@gmail.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Miaohe Lin <linmiaohe@huawei.com>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Peng Zhang <zhangpeng.00@bytedance.com>
+Cc: Tycho Andersen <tandersen@netflix.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/fork.c |   18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -662,6 +662,15 @@ static __latent_entropy int dup_mmap(str
+               } else if (anon_vma_fork(tmp, mpnt))
+                       goto fail_nomem_anon_vma_fork;
+               tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
++              /*
++               * Copy/update hugetlb private vma information.
++               */
++              if (is_vm_hugetlb_page(tmp))
++                      hugetlb_dup_vma_private(tmp);
++
++              if (tmp->vm_ops && tmp->vm_ops->open)
++                      tmp->vm_ops->open(tmp);
++
+               file = tmp->vm_file;
+               if (file) {
+                       struct address_space *mapping = file->f_mapping;
+@@ -678,12 +687,6 @@ static __latent_entropy int dup_mmap(str
+                       i_mmap_unlock_write(mapping);
+               }
+ 
+-              /*
+-               * Copy/update hugetlb private vma information.
+-               */
+-              if (is_vm_hugetlb_page(tmp))
+-                      hugetlb_dup_vma_private(tmp);
+-
+               /* Link the vma into the MT */
+               mas.index = tmp->vm_start;
+               mas.last = tmp->vm_end - 1;
+@@ -695,9 +698,6 @@ static __latent_entropy int dup_mmap(str
+               if (!(tmp->vm_flags & VM_WIPEONFORK))
+                       retval = copy_page_range(tmp, mpnt);
+ 
+-              if (tmp->vm_ops && tmp->vm_ops->open)
+-                      tmp->vm_ops->open(tmp);
+-
+               if (retval)
+                       goto loop_out;
+       }

diff --git a/queue-6.1/series b/queue-6.1/series
index 811b72c55990262a66af6941da7a82512cf376c3..8b02ab09e0748d1b18dc885c07c250add17f27a8 100644 (file)
--- a/queue-6.1/series
+++ b/queue-6.1/series
@@ -59,3 +59,5 @@ af_unix-suppress-false-positive-lockdep-splat-for-sp.patch
 cifs-replace-remaining-1-element-arrays.patch
 revert-crypto-api-disallow-identical-driver-names.patch
 virtio_net-do-not-send-rss-key-if-it-is-not-supported.patch
+fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
+x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch

diff --git a/queue-6.1/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch b/queue-6.1/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch
new file mode 100644 (file)
index 0000000..0b17270
--- /dev/null
+++ b/queue-6.1/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch
@@ -0,0 +1,42 @@
+From b53c6bd5d271d023857174b8fd3e32f98ae51372 Mon Sep 17 00:00:00 2001
+From: David Kaplan <david.kaplan@amd.com>
+Date: Sun, 21 Apr 2024 21:17:28 +0200
+Subject: x86/cpu: Fix check for RDPKRU in __show_regs()
+
+From: David Kaplan <david.kaplan@amd.com>
+
+commit b53c6bd5d271d023857174b8fd3e32f98ae51372 upstream.
+
+cpu_feature_enabled(X86_FEATURE_OSPKE) does not necessarily reflect
+whether CR4.PKE is set on the CPU.  In particular, they may differ on
+non-BSP CPUs before setup_pku() is executed.  In this scenario, RDPKRU
+will #UD causing the system to hang.
+
+Fix by checking CR4 for PKE enablement which is always correct for the
+current CPU.
+
+The scenario happens by inserting a WARN* before setup_pku() in
+identiy_cpu() or some other diagnostic which would lead to calling
+__show_regs().
+
+  [ bp: Massage commit message. ]
+
+Signed-off-by: David Kaplan <david.kaplan@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Link: https://lore.kernel.org/r/20240421191728.32239-1-bp@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/process_64.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/process_64.c
++++ b/arch/x86/kernel/process_64.c
+@@ -137,7 +137,7 @@ void __show_regs(struct pt_regs *regs, e
+                      log_lvl, d3, d6, d7);
+       }
+ 
+-      if (cpu_feature_enabled(X86_FEATURE_OSPKE))
++      if (cr4 & X86_CR4_PKE)
+               printk("%sPKRU: %08x\n", log_lvl, read_pkru());
+ }
+