Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591088 > unrolled thread

[PATCH v2 6/9] kasan: improve slab object description

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 6/9] kasan: improve slab object description Andrey Konovalov <andreyknvl@google.com> - 2017-03-02 14:50 +0100
    Re: [PATCH v2 6/9] kasan: improve slab object description Alexander Potapenko <glider@google.com> - 2017-03-03 17:50 +0100
      Re: [PATCH v2 6/9] kasan: improve slab object description Andrey Konovalov <andreyknvl@google.com> - 2017-03-06 14:50 +0100
        Re: [PATCH v2 6/9] kasan: improve slab object description Andrey Konovalov <andreyknvl@google.com> - 2017-03-06 18:10 +0100
          Re: [PATCH v2 6/9] kasan: improve slab object description Andrey Konovalov <andreyknvl@google.com> - 2017-03-06 19:20 +0100

#1591088 — [PATCH v2 6/9] kasan: improve slab object description

Changes slab object description from:

Object at ffff880068388540, in cache kmalloc-128 size: 128

to:

The buggy address belongs to the object at ffff880068388540
 which belongs to the cache kmalloc-128 of size 128
The buggy address is located 123 bytes inside of
 128-byte region [ffff880068388540, ffff8800683885c0)

Makes it more explanatory and adds information about relative offset
of the accessed address to the start of the object.

Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
 mm/kasan/report.c | 53 ++++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 42 insertions(+), 11 deletions(-)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 945d0e13e8a4..8dfb7a060d69 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -196,18 +196,49 @@ static struct page *addr_to_page(const void *addr)
 	return NULL;
 }
 
-static void describe_object(struct kmem_cache *cache, void *object)
+static void describe_object_addr(struct kmem_cache *cache, void *object,
+				const void *addr)
 {
-	struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
+	unsigned long access_addr = (unsigned long)addr;
+	unsigned long object_addr = (unsigned long)object;
+	const char *rel_type;
+	int rel_bytes;
 
-	pr_err("Object at %p, in cache %s size: %d\n", object, cache->name,
-		cache->object_size);
+	pr_err("The buggy address belongs to the object at %p\n"
+	       " which belongs to the cache %s of size %d\n",
+		object, cache->name, cache->object_size);
 
-	if (!(cache->flags & SLAB_KASAN))
+	if (!addr)
 		return;
 
-	print_track(&alloc_info->alloc_track, "Allocated");
-	print_track(&alloc_info->free_track, "Freed");
+	if (access_addr < object_addr) {
+		rel_type = "to the left";
+		rel_bytes = object_addr - access_addr;
+	} else if (access_addr >= object_addr + cache->object_size) {
+		rel_type = "to the right";
+		rel_bytes = access_addr - (object_addr + cache->object_size);
+	} else {
+		rel_type = "inside";
+		rel_bytes = access_addr - object_addr;
+	}
+
+	pr_err("The buggy address is located %d bytes %s of\n"
+	       " %d-byte region [%p, %p)\n",
+		rel_bytes, rel_type, cache->object_size, (void *)object_addr,
+		(void *)(object_addr + cache->object_size));
+}
+
+static void describe_object(struct kmem_cache *cache, void *object,
+				const void *addr)
+{
+	struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
+
+	if (cache->flags & SLAB_KASAN) {
+		print_track(&alloc_info->alloc_track, "Allocated");
+		print_track(&alloc_info->free_track, "Freed");
+	}
+
+	describe_object_addr(cache, object, addr);
 }
 
 void kasan_report_double_free(struct kmem_cache *cache, void *object,
@@ -219,13 +250,13 @@ void kasan_report_double_free(struct kmem_cache *cache, void *object,
 	pr_err("BUG: Double free or freeing an invalid pointer\n");
 	pr_err("Unexpected shadow byte: 0x%hhX\n", shadow);
 	dump_stack();
-	describe_object(cache, object);
+	describe_object(cache, object, NULL);
 	kasan_end_report(&flags);
 }
 
 static void print_address_description(struct kasan_access_info *info)
 {
-	const void *addr = info->access_addr;
+	void *addr = (void *)info->access_addr;
 	struct page *page = addr_to_page(addr);
 
 	if (page)
@@ -235,9 +266,9 @@ static void print_address_description(struct kasan_access_info *info)
 
 	if (page && PageSlab(page)) {
 		struct kmem_cache *cache = page->slab_cache;
-		void *object = nearest_obj(cache, page,	(void *)addr);
+		void *object = nearest_obj(cache, page,	addr);
 
-		describe_object(cache, object);
+		describe_object(cache, object, addr);
 	}
 
 	if (kernel_or_module_addr(addr)) {
-- 
2.12.0.rc1.440.g5b76565f74-goog

[toc] | [next] | [standalone]

#1592132

On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
> On 03/02/2017 04:48 PM, Andrey Konovalov wrote:
>> Changes slab object description from:
>>
>> Object at ffff880068388540, in cache kmalloc-128 size: 128
>>
>> to:
>>
>> The buggy address belongs to the object at ffff880068388540
>>  which belongs to the cache kmalloc-128 of size 128
>> The buggy address is located 123 bytes inside of
>>  128-byte region [ffff880068388540, ffff8800683885c0)
>>
>> Makes it more explanatory and adds information about relative offset
>> of the accessed address to the start of the object.
>>
>
> I don't think that this is an improvement. You replaced one simple line with a huge
> and hard to parse text without giving any new/useful information.
> Except maybe offset, it useful sometimes, so wouldn't mind adding it to description.
Agreed.
How about:
===========
Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
Object at ffff880068388540 belongs to the cache kmalloc-128
===========
?

> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kasan-dev@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/db0b6605-32bc-4c7a-0c99-2e60e4bdb11f%40virtuozzo.com.
> For more options, visit https://groups.google.com/d/optout.



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

[toc] | [prev] | [next] | [standalone]

#1593334

On Fri, Mar 3, 2017 at 3:39 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>
>
> On 03/03/2017 04:52 PM, Alexander Potapenko wrote:
>> On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>>> On 03/02/2017 04:48 PM, Andrey Konovalov wrote:
>>>> Changes slab object description from:
>>>>
>>>> Object at ffff880068388540, in cache kmalloc-128 size: 128
>>>>
>>>> to:
>>>>
>>>> The buggy address belongs to the object at ffff880068388540
>>>>  which belongs to the cache kmalloc-128 of size 128
>>>> The buggy address is located 123 bytes inside of
>>>>  128-byte region [ffff880068388540, ffff8800683885c0)
>>>>
>>>> Makes it more explanatory and adds information about relative offset
>>>> of the accessed address to the start of the object.
>>>>
>>>
>>> I don't think that this is an improvement. You replaced one simple line with a huge
>>> and hard to parse text without giving any new/useful information.
>>> Except maybe offset, it useful sometimes, so wouldn't mind adding it to description.
>> Agreed.
>> How about:
>> ===========
>> Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
>> Object at ffff880068388540 belongs to the cache kmalloc-128
>> ===========
>> ?
>>
>
> I would just add the offset in the end:
>         Object at ffff880068388540, in cache kmalloc-128 size: 128 accessed at offset y

Access can be inside or outside the object, so it's better to
specifically say that.

I think we can do (basically what Alexander suggested):

Object at ffff880068388540 belongs to the cache kmalloc-128 of size 128
Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)

What do you think?

[toc] | [prev] | [next] | [standalone]

#1593539

On Mon, Mar 6, 2017 at 5:12 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
> On 03/06/2017 04:45 PM, Andrey Konovalov wrote:
>> On Fri, Mar 3, 2017 at 3:39 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>>>
>>>
>>> On 03/03/2017 04:52 PM, Alexander Potapenko wrote:
>>>> On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>>>>> On 03/02/2017 04:48 PM, Andrey Konovalov wrote:
>>>>>> Changes slab object description from:
>>>>>>
>>>>>> Object at ffff880068388540, in cache kmalloc-128 size: 128
>>>>>>
>>>>>> to:
>>>>>>
>>>>>> The buggy address belongs to the object at ffff880068388540
>>>>>>  which belongs to the cache kmalloc-128 of size 128
>>>>>> The buggy address is located 123 bytes inside of
>>>>>>  128-byte region [ffff880068388540, ffff8800683885c0)
>>>>>>
>>>>>> Makes it more explanatory and adds information about relative offset
>>>>>> of the accessed address to the start of the object.
>>>>>>
>>>>>
>>>>> I don't think that this is an improvement. You replaced one simple line with a huge
>>>>> and hard to parse text without giving any new/useful information.
>>>>> Except maybe offset, it useful sometimes, so wouldn't mind adding it to description.
>>>> Agreed.
>>>> How about:
>>>> ===========
>>>> Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
>>>> Object at ffff880068388540 belongs to the cache kmalloc-128
>>>> ===========
>>>> ?
>>>>
>>>
>>> I would just add the offset in the end:
>>>         Object at ffff880068388540, in cache kmalloc-128 size: 128 accessed at offset y
>>
>> Access can be inside or outside the object, so it's better to
>> specifically say that.
>>
>
> That what access offset and object's size tells us.
>
>
>> I think we can do (basically what Alexander suggested):
>>
>> Object at ffff880068388540 belongs to the cache kmalloc-128 of size 128
>> Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
>
> This is just wrong and therefore very confusing. The message says that we access 123 bytes,
> while in fact we access x-bytes at offset 123. IOW 123 sounds like access size here not the offset.

What about

Object at ffff880068388540 belongs to cache kmalloc-128 of size 128
Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)

?

>
>
>> What do you think?
>>
>
> Not better.

[toc] | [prev] | [next] | [standalone]

#1593561

On Mon, Mar 6, 2017 at 6:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Mon, Mar 6, 2017 at 5:12 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>> On 03/06/2017 04:45 PM, Andrey Konovalov wrote:
>>> On Fri, Mar 3, 2017 at 3:39 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>>>>
>>>>
>>>> On 03/03/2017 04:52 PM, Alexander Potapenko wrote:
>>>>> On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
>>>>>> On 03/02/2017 04:48 PM, Andrey Konovalov wrote:
>>>>>>> Changes slab object description from:
>>>>>>>
>>>>>>> Object at ffff880068388540, in cache kmalloc-128 size: 128
>>>>>>>
>>>>>>> to:
>>>>>>>
>>>>>>> The buggy address belongs to the object at ffff880068388540
>>>>>>>  which belongs to the cache kmalloc-128 of size 128
>>>>>>> The buggy address is located 123 bytes inside of
>>>>>>>  128-byte region [ffff880068388540, ffff8800683885c0)
>>>>>>>
>>>>>>> Makes it more explanatory and adds information about relative offset
>>>>>>> of the accessed address to the start of the object.
>>>>>>>
>>>>>>
>>>>>> I don't think that this is an improvement. You replaced one simple line with a huge
>>>>>> and hard to parse text without giving any new/useful information.
>>>>>> Except maybe offset, it useful sometimes, so wouldn't mind adding it to description.
>>>>> Agreed.
>>>>> How about:
>>>>> ===========
>>>>> Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
>>>>> Object at ffff880068388540 belongs to the cache kmalloc-128
>>>>> ===========
>>>>> ?
>>>>>
>>>>
>>>> I would just add the offset in the end:
>>>>         Object at ffff880068388540, in cache kmalloc-128 size: 128 accessed at offset y
>>>
>>> Access can be inside or outside the object, so it's better to
>>> specifically say that.
>>>
>>
>> That what access offset and object's size tells us.
>>
>>
>>> I think we can do (basically what Alexander suggested):
>>>
>>> Object at ffff880068388540 belongs to the cache kmalloc-128 of size 128
>>> Access 123 bytes inside of 128-byte region [ffff880068388540, ffff8800683885c0)
>>
>> This is just wrong and therefore very confusing. The message says that we access 123 bytes,
>> while in fact we access x-bytes at offset 123. IOW 123 sounds like access size here not the offset.
>
> What about
>
> Object at ffff880068388540 belongs to cache kmalloc-128 of size 128
> Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)
>
> ?

Another alternative:

Accessed address is 123 bytes inside of [ffff880068388540, ffff8800683885c0)
Object belongs to cache kmalloc-128 of size 128

>
>>
>>
>>> What do you think?
>>>
>>
>> Not better.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web