From: Greg Kroah-Hartman Date: Sat, 27 Jan 2024 00:39:53 +0000 (-0800) Subject: 5.10-stable patches X-Git-Tag: v6.1.76~92 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ee430b213fd2fa465392111dea9e910dd9d2d677;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: block-remove-special-casing-of-compound-pages.patch mm-page_alloc-unreserve-highatomic-page-blocks-before-oom.patch --- diff --git a/queue-5.10/block-remove-special-casing-of-compound-pages.patch b/queue-5.10/block-remove-special-casing-of-compound-pages.patch new file mode 100644 index 00000000000..55dded7fb60 --- /dev/null +++ b/queue-5.10/block-remove-special-casing-of-compound-pages.patch @@ -0,0 +1,79 @@ +From 0f2dca516541032fe47a1236c852f58edc662795 Mon Sep 17 00:00:00 2001 +From: "Matthew Wilcox (Oracle)" +Date: Mon, 14 Aug 2023 15:41:00 +0100 +Subject: block: Remove special-casing of compound pages + +From: Matthew Wilcox (Oracle) + +commit 1b151e2435fc3a9b10c8946c6aebe9f3e1938c55 upstream. + +The special casing was originally added in pre-git history; reproducing +the commit log here: + +> commit a318a92567d77 +> Author: Andrew Morton +> Date: Sun Sep 21 01:42:22 2003 -0700 +> +> [PATCH] Speed up direct-io hugetlbpage handling +> +> This patch short-circuits all the direct-io page dirtying logic for +> higher-order pages. Without this, we pointlessly bounce BIOs up to +> keventd all the time. + +In the last twenty years, compound pages have become used for more than +just hugetlb. Rewrite these functions to operate on folios instead +of pages and remove the special case for hugetlbfs; I don't think +it's needed any more (and if it is, we can put it back in as a call +to folio_test_hugetlb()). + +This was found by inspection; as far as I can tell, this bug can lead +to pages used as the destination of a direct I/O read not being marked +as dirty. If those pages are then reclaimed by the MM without being +dirtied for some other reason, they won't be written out. Then when +they're faulted back in, they will not contain the data they should. +It'll take a pretty unusual setup to produce this problem with several +races all going the wrong way. + +This problem predates the folio work; it could for example have been +triggered by mmaping a THP in tmpfs and using that as the target of an +O_DIRECT read. + +Fixes: 800d8c63b2e98 ("shmem: add huge pages support") +Cc: +Signed-off-by: Matthew Wilcox (Oracle) +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/bio.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/block/bio.c ++++ b/block/bio.c +@@ -954,7 +954,7 @@ void bio_release_pages(struct bio *bio, + return; + + bio_for_each_segment_all(bvec, bio, iter_all) { +- if (mark_dirty && !PageCompound(bvec->bv_page)) ++ if (mark_dirty) + set_page_dirty_lock(bvec->bv_page); + put_page(bvec->bv_page); + } +@@ -1326,8 +1326,7 @@ void bio_set_pages_dirty(struct bio *bio + struct bvec_iter_all iter_all; + + bio_for_each_segment_all(bvec, bio, iter_all) { +- if (!PageCompound(bvec->bv_page)) +- set_page_dirty_lock(bvec->bv_page); ++ set_page_dirty_lock(bvec->bv_page); + } + } + +@@ -1375,7 +1374,7 @@ void bio_check_pages_dirty(struct bio *b + struct bvec_iter_all iter_all; + + bio_for_each_segment_all(bvec, bio, iter_all) { +- if (!PageDirty(bvec->bv_page) && !PageCompound(bvec->bv_page)) ++ if (!PageDirty(bvec->bv_page)) + goto defer; + } + diff --git a/queue-5.10/mm-page_alloc-unreserve-highatomic-page-blocks-before-oom.patch b/queue-5.10/mm-page_alloc-unreserve-highatomic-page-blocks-before-oom.patch new file mode 100644 index 00000000000..e209541e89c --- /dev/null +++ b/queue-5.10/mm-page_alloc-unreserve-highatomic-page-blocks-before-oom.patch @@ -0,0 +1,104 @@ +From ac3f3b0a55518056bc80ed32a41931c99e1f7d81 Mon Sep 17 00:00:00 2001 +From: Charan Teja Kalla +Date: Fri, 24 Nov 2023 16:27:25 +0530 +Subject: mm: page_alloc: unreserve highatomic page blocks before oom + +From: Charan Teja Kalla + +commit ac3f3b0a55518056bc80ed32a41931c99e1f7d81 upstream. + +__alloc_pages_direct_reclaim() is called from slowpath allocation where +high atomic reserves can be unreserved after there is a progress in +reclaim and yet no suitable page is found. Later should_reclaim_retry() +gets called from slow path allocation to decide if the reclaim needs to be +retried before OOM kill path is taken. + +should_reclaim_retry() checks the available(reclaimable + free pages) +memory against the min wmark levels of a zone and returns: + +a) true, if it is above the min wmark so that slow path allocation will + do the reclaim retries. + +b) false, thus slowpath allocation takes oom kill path. + +should_reclaim_retry() can also unreserves the high atomic reserves **but +only after all the reclaim retries are exhausted.** + +In a case where there are almost none reclaimable memory and free pages +contains mostly the high atomic reserves but allocation context can't use +these high atomic reserves, makes the available memory below min wmark +levels hence false is returned from should_reclaim_retry() leading the +allocation request to take OOM kill path. This can turn into a early oom +kill if high atomic reserves are holding lot of free memory and +unreserving of them is not attempted. + +(early)OOM is encountered on a VM with the below state: +[ 295.998653] Normal free:7728kB boost:0kB min:804kB low:1004kB +high:1204kB reserved_highatomic:8192KB active_anon:4kB inactive_anon:0kB +active_file:24kB inactive_file:24kB unevictable:1220kB writepending:0kB +present:70732kB managed:49224kB mlocked:0kB bounce:0kB free_pcp:688kB +local_pcp:492kB free_cma:0kB +[ 295.998656] lowmem_reserve[]: 0 32 +[ 295.998659] Normal: 508*4kB (UMEH) 241*8kB (UMEH) 143*16kB (UMEH) +33*32kB (UH) 7*64kB (UH) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB +0*4096kB = 7752kB + +Per above log, the free memory of ~7MB exist in the high atomic reserves +is not freed up before falling back to oom kill path. + +Fix it by trying to unreserve the high atomic reserves in +should_reclaim_retry() before __alloc_pages_direct_reclaim() can fallback +to oom kill path. + +Link: https://lkml.kernel.org/r/1700823445-27531-1-git-send-email-quic_charante@quicinc.com +Fixes: 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand") +Signed-off-by: Charan Teja Kalla +Reported-by: Chris Goldsworthy +Suggested-by: Michal Hocko +Acked-by: Michal Hocko +Acked-by: David Rientjes +Cc: Chris Goldsworthy +Cc: David Hildenbrand +Cc: Johannes Weiner +Cc: Mel Gorman +Cc: Pavankumar Kondeti +Cc: Vlastimil Babka +Cc: Joakim Tjernlund +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/page_alloc.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/mm/page_alloc.c ++++ b/mm/page_alloc.c +@@ -4534,14 +4534,9 @@ should_reclaim_retry(gfp_t gfp_mask, uns + else + (*no_progress_loops)++; + +- /* +- * Make sure we converge to OOM if we cannot make any progress +- * several times in the row. +- */ +- if (*no_progress_loops > MAX_RECLAIM_RETRIES) { +- /* Before OOM, exhaust highatomic_reserve */ +- return unreserve_highatomic_pageblock(ac, true); +- } ++ if (*no_progress_loops > MAX_RECLAIM_RETRIES) ++ goto out; ++ + + /* + * Keep reclaiming pages while there is a chance this will lead +@@ -4603,6 +4598,11 @@ out: + schedule_timeout_uninterruptible(1); + else + cond_resched(); ++out: ++ /* Before OOM, exhaust highatomic_reserve */ ++ if (!ret) ++ return unreserve_highatomic_pageblock(ac, true); ++ + return ret; + } + diff --git a/queue-5.10/series b/queue-5.10/series index ec12295ee3d..6ae4450a06d 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -35,3 +35,5 @@ rtc-adjust-failure-return-code-for-cmos_set_alarm.patch nouveau-vmm-don-t-set-addr-on-the-fail-path-to-avoid-warning.patch ubifs-ubifs_symlink-fix-memleak-of-inode-i_link-in-error-path.patch rename-fix-the-locking-of-subdirectories.patch +block-remove-special-casing-of-compound-pages.patch +mm-page_alloc-unreserve-highatomic-page-blocks-before-oom.patch