The patch titled
Subject: mm,page_owner: check for null stack_record before bumping its refcount
has been added to the -mm mm-unstable branch. Its filename is
mmpage_owner-check-for-null-stack_record-before-bumping-its-refcount.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mmpage_owner-check-for-null-stack_record-before-bumping-its-refcount.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Oscar Salvador <osalvador@xxxxxxx>
Subject: mm,page_owner: check for null stack_record before bumping its refcount
Date: Wed, 6 Mar 2024 13:32:16 +0100
Patch series "page_owner: Fixup and cleanup".
This patchset consists of a fixup by an error that was reported by intel
robot, where it seems to be that by the time page_owner gets initialized,
stackdepot has already depleted its allocation space and returns
0-handles, turning that into null stack_records when trying to retrieve
the stack_record. I was not able to reproduce that from the config
because it booted fine for me, but when setting e.g: dummy_handle to 0
artificially, I could see the same error that was reported.
The second patch is a cleanup that can also lead to a compilation warning.
This patch (of 2):
Although the retrieval of the stack_records for {dummy,failure}_handle
happen when page_owner gets initialized, there seems to be some situations
where stackdepot space has been already depleted by then, so we get
0-handles which make stack_records being NULL for those cases.
Be careful to 1) only bump stack_records refcount and 2) only access
stack_record fields if we actually have a non-null stack_record between
hands.
Link: https://lkml.kernel.org/r/20240306123217.29774-1-osalvador@xxxxxxx
Link: https://lkml.kernel.org/r/20240306123217.29774-2-osalvador@xxxxxxx
Fixes: 4bedfb314bdd ("mm,page_owner: implement the tracking of the stacks count")
Signed-off-by: Oscar Salvador <osalvador@xxxxxxx>
Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
Closes: https://lore.kernel.org/oe-lkp/202403051032.e2f865a-lkp@xxxxxxxxx
Cc: Alexander Potapenko <glider@xxxxxxxxxx>
Cc: Andrey Konovalov <andreyknvl@xxxxxxxxx>
Cc: Marco Elver <elver@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/page_owner.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/mm/page_owner.c~mmpage_owner-check-for-null-stack_record-before-bumping-its-refcount
+++ a/mm/page_owner.c
@@ -107,8 +107,10 @@ static __init void init_page_owner(void)
/* Initialize dummy and failure stacks and link them to stack_list */
dummy_stack.stack_record = __stack_depot_get_stack_record(dummy_handle);
failure_stack.stack_record = __stack_depot_get_stack_record(failure_handle);
- refcount_set(&dummy_stack.stack_record->count, 1);
- refcount_set(&failure_stack.stack_record->count, 1);
+ if (dummy_stack.stack_record)
+ refcount_set(&dummy_stack.stack_record->count, 1);
+ if (failure_stack.stack_record)
+ refcount_set(&failure_stack.stack_record->count, 1);
dummy_stack.next = &failure_stack;
stack_list = &dummy_stack;
}
@@ -856,6 +858,9 @@ static int stack_print(struct seq_file *
unsigned long nr_entries;
struct stack_record *stack_record = stack->stack_record;
+ if (!stack->stack_record)
+ return 0;
+
nr_entries = stack_record->size;
entries = stack_record->entries;
stack_count = refcount_read(&stack_record->count) - 1;
_
Patches currently in -mm which might be from osalvador@xxxxxxx are
mmpage_owner-check-for-null-stack_record-before-bumping-its-refcount.patch
mmpage_owner-drop-unnecesary-check.patch
