folio_zero_user() is constrained to operate in a page-at-a-time
fashion because it handles CONFIG_HIGHMEM which means that the
pages in a folio might be mapped to a discontiguous kernel address
range.

In addition, cooperative preemption models (none, voluntary) force
zeroing of successive chunks to be interspersed with invocations
invocations of cond_resched().

Allow an architecture specific override.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
 mm/memory.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index 8eba595056fe..e769480b712a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -7079,8 +7079,11 @@ static int clear_subpage(unsigned long addr, int idx, void *arg)
  * folio_zero_user - Zero a folio which will be mapped to userspace.
  * @folio: The folio to zero.
  * @addr_hint: The address will be accessed or the base address if uncelar.
+ *
+ * folio_zero_user() does page-at-a-time zeroing because it needs to handle
+ * CONFIG_HIGHMEM. Allow architecture override.
  */
-void folio_zero_user(struct folio *folio, unsigned long addr_hint)
+void __weak folio_zero_user(struct folio *folio, unsigned long addr_hint)
 {
 	unsigned int nr_pages = folio_nr_pages(folio);
 
-- 
2.31.1