linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] page_owner: Fixup and cleanup
@ 2024-03-06 12:32 Oscar Salvador
  2024-03-06 12:32 ` [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount Oscar Salvador
  2024-03-06 12:32 ` [PATCH 2/2] mm,page_owner: Drop unnecesary check Oscar Salvador
  0 siblings, 2 replies; 5+ messages in thread
From: Oscar Salvador @ 2024-03-06 12:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, Michal Hocko, Vlastimil Babka,
	Marco Elver, Andrey Konovalov, Alexander Potapenko,
	Oscar Salvador

Hi,

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.

Oscar Salvador (2):
  mm,page_owner: Check for null stack_record before bumping its refcount
  mm,page_owner: Drop unnecesary check

 mm/page_owner.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

-- 
2.44.0



^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount
  2024-03-06 12:32 [PATCH 0/2] page_owner: Fixup and cleanup Oscar Salvador
@ 2024-03-06 12:32 ` Oscar Salvador
  2024-03-08  7:53   ` Vlastimil Babka
  2024-03-06 12:32 ` [PATCH 2/2] mm,page_owner: Drop unnecesary check Oscar Salvador
  1 sibling, 1 reply; 5+ messages in thread
From: Oscar Salvador @ 2024-03-06 12:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, Michal Hocko, Vlastimil Babka,
	Marco Elver, Andrey Konovalov, Alexander Potapenko,
	Oscar Salvador, kernel test robot

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.

Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202403051032.e2f865a-lkp@intel.com
Fixes: 4bedfb314bdd ("mm,page_owner: implement the tracking of the stacks count")
Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 mm/page_owner.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/page_owner.c b/mm/page_owner.c
index 033e349f6479..7163a1c44ccf 100644
--- a/mm/page_owner.c
+++ b/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 *m, void *v)
 	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;
-- 
2.44.0



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH 2/2] mm,page_owner: Drop unnecesary check
  2024-03-06 12:32 [PATCH 0/2] page_owner: Fixup and cleanup Oscar Salvador
  2024-03-06 12:32 ` [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount Oscar Salvador
@ 2024-03-06 12:32 ` Oscar Salvador
  2024-03-08  7:53   ` Vlastimil Babka
  1 sibling, 1 reply; 5+ messages in thread
From: Oscar Salvador @ 2024-03-06 12:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, Michal Hocko, Vlastimil Babka,
	Marco Elver, Andrey Konovalov, Alexander Potapenko,
	Oscar Salvador

stackdepot only saves stack_records which size is greather than 0,
so we cannot possibly have empty stack_records.
Drop the check.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 mm/page_owner.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_owner.c b/mm/page_owner.c
index 7163a1c44ccf..e7139952ffd9 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -865,8 +865,7 @@ static int stack_print(struct seq_file *m, void *v)
 	entries = stack_record->entries;
 	stack_count = refcount_read(&stack_record->count) - 1;
 
-	if (!nr_entries || nr_entries < 0 || stack_count < 1 ||
-	    stack_count < page_owner_stack_threshold)
+	if (stack_count < 1 || stack_count < page_owner_stack_threshold)
 		return 0;
 
 	for (i = 0; i < nr_entries; i++)
-- 
2.44.0



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount
  2024-03-06 12:32 ` [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount Oscar Salvador
@ 2024-03-08  7:53   ` Vlastimil Babka
  0 siblings, 0 replies; 5+ messages in thread
From: Vlastimil Babka @ 2024-03-08  7:53 UTC (permalink / raw)
  To: Oscar Salvador, Andrew Morton
  Cc: linux-kernel, linux-mm, Michal Hocko, Marco Elver,
	Andrey Konovalov, Alexander Potapenko, kernel test robot

On 3/6/24 13:32, Oscar Salvador wrote:
> 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.
> 
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202403051032.e2f865a-lkp@intel.com
> Fixes: 4bedfb314bdd ("mm,page_owner: implement the tracking of the stacks count")
> Signed-off-by: Oscar Salvador <osalvador@suse.de>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

> ---
>  mm/page_owner.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 033e349f6479..7163a1c44ccf 100644
> --- a/mm/page_owner.c
> +++ b/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 *m, void *v)
>  	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;



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/2] mm,page_owner: Drop unnecesary check
  2024-03-06 12:32 ` [PATCH 2/2] mm,page_owner: Drop unnecesary check Oscar Salvador
@ 2024-03-08  7:53   ` Vlastimil Babka
  0 siblings, 0 replies; 5+ messages in thread
From: Vlastimil Babka @ 2024-03-08  7:53 UTC (permalink / raw)
  To: Oscar Salvador, Andrew Morton
  Cc: linux-kernel, linux-mm, Michal Hocko, Marco Elver,
	Andrey Konovalov, Alexander Potapenko

On 3/6/24 13:32, Oscar Salvador wrote:
> stackdepot only saves stack_records which size is greather than 0,
> so we cannot possibly have empty stack_records.
> Drop the check.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>---
>  mm/page_owner.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 7163a1c44ccf..e7139952ffd9 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -865,8 +865,7 @@ static int stack_print(struct seq_file *m, void *v)
>  	entries = stack_record->entries;
>  	stack_count = refcount_read(&stack_record->count) - 1;
>  
> -	if (!nr_entries || nr_entries < 0 || stack_count < 1 ||
> -	    stack_count < page_owner_stack_threshold)
> +	if (stack_count < 1 || stack_count < page_owner_stack_threshold)
>  		return 0;
>  
>  	for (i = 0; i < nr_entries; i++)



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-03-08  7:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-06 12:32 [PATCH 0/2] page_owner: Fixup and cleanup Oscar Salvador
2024-03-06 12:32 ` [PATCH 1/2] mm,page_owner: Check for null stack_record before bumping its refcount Oscar Salvador
2024-03-08  7:53   ` Vlastimil Babka
2024-03-06 12:32 ` [PATCH 2/2] mm,page_owner: Drop unnecesary check Oscar Salvador
2024-03-08  7:53   ` Vlastimil Babka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).