mm/hugetlb: fix missing hugetlb_lock for resv uncharge

jira LE-1907
cve CVE-2024-36000
Rebuild_History Non-Buildable kernel-4.18.0-553.16.1.el8_10
commit-author Peter Xu <[email protected]>
commit b76b469
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/b76b4690.failed

There is a recent report on UFFDIO_COPY over hugetlb:

https://lore.kernel.org/all/[email protected]/

350:	lockdep_assert_held(&hugetlb_lock);

Should be an issue in hugetlb but triggered in an userfault context, where
it goes into the unlikely path where two threads modifying the resv map
together.  Mike has a fix in that path for resv uncharge but it looks like
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
will update the cgroup pointer, so it requires to be called with the lock
held.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 79aa925 ("hugetlb_cgroup: fix reservation accounting")
	Signed-off-by: Peter Xu <[email protected]>
	Reported-by: [email protected]
	Reviewed-by: Mina Almasry <[email protected]>
	Cc: David Hildenbrand <[email protected]>
	Cc: <[email protected]>
	Signed-off-by: Andrew Morton <[email protected]>
(cherry picked from commit b76b469)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	mm/hugetlb.c

Author: PlaidCat

ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/b76b4690.failed

@@ -0,0 +1,69 @@
+mm/hugetlb: fix missing hugetlb_lock for resv uncharge
+
+jira LE-1907
+cve CVE-2024-36000
+Rebuild_History Non-Buildable kernel-4.18.0-553.16.1.el8_10
+commit-author Peter Xu <[email protected]>
+commit b76b46902c2d0395488c8412e1116c2486cdfcb2
+Empty-Commit: Cherry-Pick Conflicts during history rebuild.
+Will be included in final tarball splat. Ref for failed cherry-pick at:
+ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/b76b4690.failed
+
+There is a recent report on UFFDIO_COPY over hugetlb:
+
+https://lore.kernel.org/all/[email protected]/
+
+350:	lockdep_assert_held(&hugetlb_lock);
+
+Should be an issue in hugetlb but triggered in an userfault context, where
+it goes into the unlikely path where two threads modifying the resv map
+together.  Mike has a fix in that path for resv uncharge but it looks like
+the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
+will update the cgroup pointer, so it requires to be called with the lock
+held.
+
+Link: https://lkml.kernel.org/r/[email protected]
+Fixes: 79aa925bf239 ("hugetlb_cgroup: fix reservation accounting")
+	Signed-off-by: Peter Xu <[email protected]>
+	Reported-by: [email protected]
+	Reviewed-by: Mina Almasry <[email protected]>
+	Cc: David Hildenbrand <[email protected]>
+	Cc: <[email protected]>
+	Signed-off-by: Andrew Morton <[email protected]>
+(cherry picked from commit b76b46902c2d0395488c8412e1116c2486cdfcb2)
+	Signed-off-by: Jonathan Maple <[email protected]>
+
+# Conflicts:
+#	mm/hugetlb.c
+diff --cc mm/hugetlb.c
+index 1bba953dfe5e,53e0ab5c0845..000000000000
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@@ -2460,11 -3268,19 +2460,20 @@@ struct page *alloc_huge_page(struct vm_
+  
+  		rsv_adjust = hugepage_subpool_put_pages(spool, 1);
+  		hugetlb_acct_memory(h, -rsv_adjust);
+++<<<<<<< HEAD
+ +		if (deferred_reserve)
+ +			hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h),
+ +					pages_per_huge_page(h), page);
+++=======
++ 		if (deferred_reserve) {
++ 			spin_lock_irq(&hugetlb_lock);
++ 			hugetlb_cgroup_uncharge_folio_rsvd(hstate_index(h),
++ 					pages_per_huge_page(h), folio);
++ 			spin_unlock_irq(&hugetlb_lock);
++ 		}
+++>>>>>>> b76b46902c2d (mm/hugetlb: fix missing hugetlb_lock for resv uncharge)
+  	}
+ -
+ -	if (!memcg_charge_ret)
+ -		mem_cgroup_commit_charge(folio, memcg);
+ -	mem_cgroup_put(memcg);
+ -
+ -	return folio;
+ +	return page;
+  
+  out_uncharge_cgroup:
+  	hugetlb_cgroup_uncharge_cgroup(idx, pages_per_huge_page(h), h_cg);
+* Unmerged path mm/hugetlb.c