[PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[vjitta]

From: Yogesh Lal <ylal@codeaurora.org>

Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.

Aim is to have configurable value for  STACK_HASH_SIZE,
so depend on use case one can configure it.

One example is of Page Owner, default value of
STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
Making it configurable and use lower value helps to enable features like
CONFIG_PAGE_OWNER without any significant overhead.

Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
---
 lib/Kconfig      | 9 +++++++++
 lib/stackdepot.c | 3 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 3321d04..fd967fb 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -623,6 +623,15 @@ config STACKDEPOT
 	bool
 	select STACKTRACE
 
+config STACK_HASH_ORDER_SHIFT
+	int "stack depot hash size (12 => 4KB, 20 => 1024KB)"
+	range 12 20
+	default 20
+	depends on STACKDEPOT
+	help
+	 Select the hash size as a power of 2 for the stackdepot hash table.
+	 Choose a lower value to reduce the memory impact.
+
 config SBITMAP
 	bool
 
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 81c69c0..614ac28 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -141,8 +141,7 @@ static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
 	return stack;
 }
 
-#define STACK_HASH_ORDER 20
-#define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
+#define STACK_HASH_SIZE (1L << CONFIG_STACK_HASH_ORDER_SHIFT)
 #define STACK_HASH_MASK (STACK_HASH_SIZE - 1)
 #define STACK_HASH_SEED 0x9747b28c
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
2.7.4

[PATCH v4 2/2] lib: stackdepot: Add support to disable stack depot

[vjitta]

From: Vijayanand Jitta <vjitta@codeaurora.org>

Add a kernel parameter stack_depot_disable to disable
stack depot. So that stack hash table doesn't consume
any memory when stack depot is disabled.

Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
---
 lib/stackdepot.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 614ac28..72b9050 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -30,6 +30,7 @@
 #include <linux/stackdepot.h>
 #include <linux/string.h>
 #include <linux/types.h>
+#include <linux/vmalloc.h>
 
 #define DEPOT_STACK_BITS (sizeof(depot_stack_handle_t) * 8)
 
@@ -145,10 +146,36 @@ static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
 #define STACK_HASH_MASK (STACK_HASH_SIZE - 1)
 #define STACK_HASH_SEED 0x9747b28c
 
-static struct stack_record *stack_table[STACK_HASH_SIZE] = {
+static struct stack_record *stack_table_tmp[STACK_HASH_SIZE] __initdata = {
 	[0 ...	STACK_HASH_SIZE - 1] = NULL
 };
 
+static bool stack_depot_disable;
+static struct stack_record **stack_table __refdata = stack_table_tmp;
+
+static int __init is_stack_depot_disabled(char *str)
+{
+	kstrtobool(str, &stack_depot_disable);
+	if (stack_depot_disable) {
+		pr_info("Stack Depot is disabled\n");
+		stack_table = NULL;
+	}
+	return 0;
+}
+early_param("stack_depot_disable", is_stack_depot_disabled);
+
+static int __init init_stackdepot(void)
+{
+	if (!stack_depot_disable) {
+		size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
+
+		stack_table = vmalloc(size);
+		memcpy(stack_table, stack_table_tmp, size);
+	}
+	return 0;
+}
+early_initcall(init_stackdepot);
+
 /* Calculate hash for a stack */
 static inline u32 hash_stack(unsigned long *entries, unsigned int size)
 {
@@ -230,7 +257,7 @@ depot_stack_handle_t stack_depot_save(unsigned long *entries,
 	unsigned long flags;
 	u32 hash;
 
-	if (unlikely(nr_entries == 0))
+	if (unlikely(nr_entries == 0) || !stack_table)
 		goto fast_exit;
 
 	hash = hash_stack(entries, nr_entries);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
2.7.4

Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Andrew Morton]

On Wed, 30 Dec 2020 18:15:30 +0530 vjitta@codeaurora.org wrote:

> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
> 
> Aim is to have configurable value for  STACK_HASH_SIZE,
> so depend on use case one can configure it.
> 
> One example is of Page Owner, default value of
> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
> Making it configurable and use lower value helps to enable features like
> CONFIG_PAGE_OWNER without any significant overhead.

Questions regarding the stackdepot code.

- stack_table_tmp[] is __initdata.  So after initmem is released,
  that "consume 8MB of static memory" should no longer be true.  But
  iirc, not all architectures actually release __initdata memory.  Does
  your architecture do this?

- Stackdepot copies stack_table_tmp[] into vmalloced memory during
  initcalls.  Why?  Why not simply make stack_table_tmp[] no longer
  __initdata and use that memory for all time?

  Presumably because in the stack_depot_disable==true case, we
  release stack_table_tmp[] memory, don't vmalloc for a copy of it, and
  save a bunch of memory?  If so, this assumes that the __initdata
  memory is freed.

- Why is that hash table so large?  Is it appropriately sized?

- SMP is up and running during init_stackdepot(), I think?  If so, is
  that huge memcpy smp-safe?  Can other CPUs be modifying
  stack_table_tmp[] while the memcpy is in flight?

Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Vijayanand Jitta]

On 1/5/2021 4:42 AM, Andrew Morton wrote:
> On Wed, 30 Dec 2020 18:15:30 +0530 vjitta@codeaurora.org wrote:
> 
>> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
>>
>> Aim is to have configurable value for  STACK_HASH_SIZE,
>> so depend on use case one can configure it.
>>
>> One example is of Page Owner, default value of
>> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
>> Making it configurable and use lower value helps to enable features like
>> CONFIG_PAGE_OWNER without any significant overhead.
> 
> Questions regarding the stackdepot code.
> 
> - stack_table_tmp[] is __initdata.  So after initmem is released,
>   that "consume 8MB of static memory" should no longer be true.  But
>   iirc, not all architectures actually release __initdata memory.  Does
>   your architecture do this?
> 
Thanks for review comments, I wasn't aware that __initdata is
architecture dependent, I was assuming that __initdata always frees
memory and yes the architecture which i am using (arm64) does free
__inidata.

> - Stackdepot copies stack_table_tmp[] into vmalloced memory during
>   initcalls.  Why?  Why not simply make stack_table_tmp[] no longer
>   __initdata and use that memory for all time?
> 
>   Presumably because in the stack_depot_disable==true case, we
>   release stack_table_tmp[] memory, don't vmalloc for a copy of it, and
>   save a bunch of memory?  If so, this assumes that the __initdata
>   memory is freed.
> 

Yes, that correct. assumption here is __initidata will free memory if
stack_depot_disable=true is set.

> - Why is that hash table so large?  Is it appropriately sized?
> 

I think the large size of hash table is justified since the users of
stack depot like kasan, page owner etc store a very large number of  stacks.

> - SMP is up and running during init_stackdepot(), I think?  If so, is
>   that huge memcpy smp-safe?  Can other CPUs be modifying
>   stack_table_tmp[] while the memcpy is in flight?
> 
> 
> 
Yes, parallel access could be possible. I will add a locking mechanism
inplace.

Thanks,
Vijay

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Vijayanand Jitta]

On 1/5/2021 2:54 PM, Vijayanand Jitta wrote:
> 
> 
> On 1/5/2021 4:42 AM, Andrew Morton wrote:
>> On Wed, 30 Dec 2020 18:15:30 +0530 vjitta@codeaurora.org wrote:
>>
>>> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
>>>
>>> Aim is to have configurable value for  STACK_HASH_SIZE,
>>> so depend on use case one can configure it.
>>>
>>> One example is of Page Owner, default value of
>>> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
>>> Making it configurable and use lower value helps to enable features like
>>> CONFIG_PAGE_OWNER without any significant overhead.
>>
>> Questions regarding the stackdepot code.
>>
>> - stack_table_tmp[] is __initdata.  So after initmem is released,
>>   that "consume 8MB of static memory" should no longer be true.  But
>>   iirc, not all architectures actually release __initdata memory.  Does
>>   your architecture do this?
>>
> Thanks for review comments, I wasn't aware that __initdata is
> architecture dependent, I was assuming that __initdata always frees
> memory and yes the architecture which i am using (arm64) does free
> __inidata.
> 
>> - Stackdepot copies stack_table_tmp[] into vmalloced memory during
>>   initcalls.  Why?  Why not simply make stack_table_tmp[] no longer
>>   __initdata and use that memory for all time?
>>
>>   Presumably because in the stack_depot_disable==true case, we
>>   release stack_table_tmp[] memory, don't vmalloc for a copy of it, and
>>   save a bunch of memory?  If so, this assumes that the __initdata
>>   memory is freed.
>>
> 
> Yes, that correct. assumption here is __initidata will free memory if
> stack_depot_disable=true is set.
> 
>> - Why is that hash table so large?  Is it appropriately sized?
>>
> 
> I think the large size of hash table is justified since the users of
> stack depot like kasan, page owner etc store a very large number of  stacks.
> 
>> - SMP is up and running during init_stackdepot(), I think?  If so, is
>>   that huge memcpy smp-safe?  Can other CPUs be modifying
>>   stack_table_tmp[] while the memcpy is in flight?
>>
>>
>>
> Yes, parallel access could be possible. I will add a locking mechanism
> inplace.
> 
> Thanks,
> Vijay
> 

I have updated the patch avoiding __initdata as per suggestion and the
copy from tmp , can you please review v5.

https://lore.kernel.org/patchwork/patch/1367306/

Thanks,
Vijay

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Alexander Potapenko]

On Wed, Dec 30, 2020 at 1:46 PM <vjitta@codeaurora.org> wrote:
>
> From: Yogesh Lal <ylal@codeaurora.org>
>
> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
I think "ORDER_SHIFT" is somewhat redundant, as "SMTH_ORDER" already
means this is a power of two we'll be using for shifting.
Leaving this up to you.

Alex

Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Vijayanand Jitta]

On 1/7/2021 3:14 PM, Alexander Potapenko wrote:
> On Wed, Dec 30, 2020 at 1:46 PM <vjitta@codeaurora.org> wrote:
>>
>> From: Yogesh Lal <ylal@codeaurora.org>
>>
>> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
> I think "ORDER_SHIFT" is somewhat redundant, as "SMTH_ORDER" already
> means this is a power of two we'll be using for shifting.
> Leaving this up to you.
> 
> Alex
> 

Right, updated this to STACK_HASH_ORDER in v5.
https://lkml.org/lkml/2021/1/18/255

Thanks,
Vijay
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation