linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle
@ 2016-05-03  5:13 js1304
  2016-05-04  8:34 ` Alexander Potapenko
  0 siblings, 1 reply; 3+ messages in thread
From: js1304 @ 2016-05-03  5:13 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alexander Potapenko, Andrey Ryabinin, linux-kernel, linux-mm,
	Joonsoo Kim

From: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Recently, we allow to save the stacktrace whose hashed value is 0.
It causes the problem that stackdepot could return 0 even if in success.
User of stackdepot cannot distinguish whether it is success or not so we
need to solve this problem. In this patch, 1 bit are added to handle
and make valid handle none 0 by setting this bit. After that, valid handle
will not be 0 and 0 handle will represent failure correctly.

Fixes: 33334e25769c ("lib/stackdepot.c: allow the stack trace hash
to be zero")
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
 lib/stackdepot.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 9e0b031..53ad6c0 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -42,12 +42,14 @@
 
 #define DEPOT_STACK_BITS (sizeof(depot_stack_handle_t) * 8)
 
+#define STACK_ALLOC_NULL_PROTECTION_BITS 1
 #define STACK_ALLOC_ORDER 2 /* 'Slab' size order for stack depot, 4 pages */
 #define STACK_ALLOC_SIZE (1LL << (PAGE_SHIFT + STACK_ALLOC_ORDER))
 #define STACK_ALLOC_ALIGN 4
 #define STACK_ALLOC_OFFSET_BITS (STACK_ALLOC_ORDER + PAGE_SHIFT - \
 					STACK_ALLOC_ALIGN)
-#define STACK_ALLOC_INDEX_BITS (DEPOT_STACK_BITS - STACK_ALLOC_OFFSET_BITS)
+#define STACK_ALLOC_INDEX_BITS (DEPOT_STACK_BITS - \
+		STACK_ALLOC_NULL_PROTECTION_BITS - STACK_ALLOC_OFFSET_BITS)
 #define STACK_ALLOC_SLABS_CAP 1024
 #define STACK_ALLOC_MAX_SLABS \
 	(((1LL << (STACK_ALLOC_INDEX_BITS)) < STACK_ALLOC_SLABS_CAP) ? \
@@ -59,6 +61,7 @@ union handle_parts {
 	struct {
 		u32 slabindex : STACK_ALLOC_INDEX_BITS;
 		u32 offset : STACK_ALLOC_OFFSET_BITS;
+		u32 valid : STACK_ALLOC_NULL_PROTECTION_BITS;
 	};
 };
 
@@ -136,6 +139,7 @@ static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
 	stack->size = size;
 	stack->handle.slabindex = depot_index;
 	stack->handle.offset = depot_offset >> STACK_ALLOC_ALIGN;
+	stack->handle.valid = 1;
 	memcpy(stack->entries, entries, size * sizeof(unsigned long));
 	depot_offset += required_size;
 
-- 
1.9.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

* Re: [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle
  2016-05-03  5:13 [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle js1304
@ 2016-05-04  8:34 ` Alexander Potapenko
  2016-05-04 15:17   ` Joonsoo Kim
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Potapenko @ 2016-05-04  8:34 UTC (permalink / raw)
  To: Joonsoo Kim
  Cc: Andrew Morton, Andrey Ryabinin, LKML,
	Linux Memory Management List, Joonsoo Kim

On Tue, May 3, 2016 at 7:13 AM,  <js1304@gmail.com> wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> Recently, we allow to save the stacktrace whose hashed value is 0.
> It causes the problem that stackdepot could return 0 even if in success.
> User of stackdepot cannot distinguish whether it is success or not so we
> need to solve this problem. In this patch, 1 bit are added to handle
> and make valid handle none 0 by setting this bit. After that, valid handle
> will not be 0 and 0 handle will represent failure correctly.
Returning success or failure doesn't require a special bit, we can
just make depot_alloc_stack() return a boolean value.
If I'm understanding correctly, your primary intention is to reserve
an invalid handle value that will never collide with valid handles
returned in the future.
Can you reflect this in the description?
> Fixes: 33334e25769c ("lib/stackdepot.c: allow the stack trace hash
> to be zero")
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> ---
>  lib/stackdepot.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 9e0b031..53ad6c0 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -42,12 +42,14 @@
>
>  #define DEPOT_STACK_BITS (sizeof(depot_stack_handle_t) * 8)
>
> +#define STACK_ALLOC_NULL_PROTECTION_BITS 1
>  #define STACK_ALLOC_ORDER 2 /* 'Slab' size order for stack depot, 4 pages */
>  #define STACK_ALLOC_SIZE (1LL << (PAGE_SHIFT + STACK_ALLOC_ORDER))
>  #define STACK_ALLOC_ALIGN 4
>  #define STACK_ALLOC_OFFSET_BITS (STACK_ALLOC_ORDER + PAGE_SHIFT - \
>                                         STACK_ALLOC_ALIGN)
> -#define STACK_ALLOC_INDEX_BITS (DEPOT_STACK_BITS - STACK_ALLOC_OFFSET_BITS)
> +#define STACK_ALLOC_INDEX_BITS (DEPOT_STACK_BITS - \
> +               STACK_ALLOC_NULL_PROTECTION_BITS - STACK_ALLOC_OFFSET_BITS)
>  #define STACK_ALLOC_SLABS_CAP 1024
>  #define STACK_ALLOC_MAX_SLABS \
>         (((1LL << (STACK_ALLOC_INDEX_BITS)) < STACK_ALLOC_SLABS_CAP) ? \
> @@ -59,6 +61,7 @@ union handle_parts {
>         struct {
>                 u32 slabindex : STACK_ALLOC_INDEX_BITS;
>                 u32 offset : STACK_ALLOC_OFFSET_BITS;
> +               u32 valid : STACK_ALLOC_NULL_PROTECTION_BITS;
>         };
>  };
>
> @@ -136,6 +139,7 @@ static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
>         stack->size = size;
>         stack->handle.slabindex = depot_index;
>         stack->handle.offset = depot_offset >> STACK_ALLOC_ALIGN;
> +       stack->handle.valid = 1;
>         memcpy(stack->entries, entries, size * sizeof(unsigned long));
>         depot_offset += required_size;
>
> --
> 1.9.1
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

* Re: [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle
  2016-05-04  8:34 ` Alexander Potapenko
@ 2016-05-04 15:17   ` Joonsoo Kim
  0 siblings, 0 replies; 3+ messages in thread
From: Joonsoo Kim @ 2016-05-04 15:17 UTC (permalink / raw)
  To: Alexander Potapenko
  Cc: Andrew Morton, Andrey Ryabinin, LKML,
	Linux Memory Management List, Joonsoo Kim

2016-05-04 17:34 GMT+09:00 Alexander Potapenko <glider@google.com>:
> On Tue, May 3, 2016 at 7:13 AM,  <js1304@gmail.com> wrote:
>> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>>
>> Recently, we allow to save the stacktrace whose hashed value is 0.
>> It causes the problem that stackdepot could return 0 even if in success.
>> User of stackdepot cannot distinguish whether it is success or not so we
>> need to solve this problem. In this patch, 1 bit are added to handle
>> and make valid handle none 0 by setting this bit. After that, valid handle
>> will not be 0 and 0 handle will represent failure correctly.
> Returning success or failure doesn't require a special bit, we can
> just make depot_alloc_stack() return a boolean value.
> If I'm understanding correctly, your primary intention is to reserve
> an invalid handle value that will never collide with valid handles
> returned in the future.
> Can you reflect this in the description?

Indeed. I will add it in the description and respin the patch.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

end of thread, other threads:[~2016-05-04 15:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-03  5:13 [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle js1304
2016-05-04  8:34 ` Alexander Potapenko
2016-05-04 15:17   ` Joonsoo Kim

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).