Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Wed, Oct 1, 2014 at 6:11 PM, Andrey Ryabinin wrote: >>> >>> We can disable kasan instrumentation of this file as well. >> >> Yes, but why? I don't think we need that. > > Just gut feeling. Such tools usually don't play well together. For > example, due to asan quarantine lots of leaks will be missed (if we > pretend that tools work together, end users will use them together and > miss bugs). I won't be surprised if leak detector touches freed > objects under some circumstances as well. > We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. >>> >>> I did test them together. With this patch applied both tools works without >>> problems. >> >> What do you mean "works without problems"? Are you sure that kmemleak >> still detects all leaks it is intended to detect? >> > > Yes I'm sure about that. And how kasan could affect on kmemleak's capability > to detect leaks? Ah, OK, we don't have quarantine. The idea is that redzones and quarantine will contain parasitical pointers (quarantine is exactly a linked list of freed objects). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On 10/01/2014 05:27 PM, Dmitry Vyukov wrote: > On Wed, Oct 1, 2014 at 3:45 PM, Andrey Ryabinin > wrote: >> On 10/01/2014 02:39 PM, Catalin Marinas wrote: >>> On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin wrote: > 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : >> Looks good to me. >> >> We can disable kasan instrumentation of this file as well. > > Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. >>> >>> I think it's worth testing them together first. >>> >> >> I did test them together. With this patch applied both tools works without >> problems. > > What do you mean "works without problems"? Are you sure that kmemleak > still detects all leaks it is intended to detect? > Yes I'm sure about that. And how kasan could affect on kmemleak's capability to detect leaks? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Wed, Oct 1, 2014 at 3:45 PM, Andrey Ryabinin wrote: > On 10/01/2014 02:39 PM, Catalin Marinas wrote: >> On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: >>> On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin >>> wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : > Looks good to me. > > We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. >>> >>> Just gut feeling. Such tools usually don't play well together. For >>> example, due to asan quarantine lots of leaks will be missed (if we >>> pretend that tools work together, end users will use them together and >>> miss bugs). I won't be surprised if leak detector touches freed >>> objects under some circumstances as well. >>> We can do this if/when discover actual compatibility issues, of course. >> >> I think it's worth testing them together first. >> > > I did test them together. With this patch applied both tools works without > problems. What do you mean "works without problems"? Are you sure that kmemleak still detects all leaks it is intended to detect? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On 10/01/2014 02:39 PM, Catalin Marinas wrote: > On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: >> On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin >> wrote: >>> 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : Looks good to me. We can disable kasan instrumentation of this file as well. >>> >>> Yes, but why? I don't think we need that. >> >> Just gut feeling. Such tools usually don't play well together. For >> example, due to asan quarantine lots of leaks will be missed (if we >> pretend that tools work together, end users will use them together and >> miss bugs). I won't be surprised if leak detector touches freed >> objects under some circumstances as well. >> We can do this if/when discover actual compatibility issues, of course. > > I think it's worth testing them together first. > I did test them together. With this patch applied both tools works without problems. > One issue, as mentioned in the patch log, is that the size information > that kmemleak gets is the one from the kmem_cache object rather than the > original allocation size, so this would be rounded up. > > Kmemleak should not touch freed objects (if an object is freed during a > scan, it is protected by some lock until the scan completes). There is a > bug however which I haven't got to fixing it yet, if kmemleak fails for > some reason (cannot allocate memory) and disables itself, it may access > some freed object (though usually hard to trigger). > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: > On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin > wrote: > > 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : > >> Looks good to me. > >> > >> We can disable kasan instrumentation of this file as well. > > > > Yes, but why? I don't think we need that. > > Just gut feeling. Such tools usually don't play well together. For > example, due to asan quarantine lots of leaks will be missed (if we > pretend that tools work together, end users will use them together and > miss bugs). I won't be surprised if leak detector touches freed > objects under some circumstances as well. > We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. One issue, as mentioned in the patch log, is that the size information that kmemleak gets is the one from the kmem_cache object rather than the original allocation size, so this would be rounded up. Kmemleak should not touch freed objects (if an object is freed during a scan, it is protected by some lock until the scan completes). There is a bug however which I haven't got to fixing it yet, if kmemleak fails for some reason (cannot allocate memory) and disables itself, it may access some freed object (though usually hard to trigger). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. One issue, as mentioned in the patch log, is that the size information that kmemleak gets is the one from the kmem_cache object rather than the original allocation size, so this would be rounded up. Kmemleak should not touch freed objects (if an object is freed during a scan, it is protected by some lock until the scan completes). There is a bug however which I haven't got to fixing it yet, if kmemleak fails for some reason (cannot allocate memory) and disables itself, it may access some freed object (though usually hard to trigger). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On 10/01/2014 02:39 PM, Catalin Marinas wrote: On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. I did test them together. With this patch applied both tools works without problems. One issue, as mentioned in the patch log, is that the size information that kmemleak gets is the one from the kmem_cache object rather than the original allocation size, so this would be rounded up. Kmemleak should not touch freed objects (if an object is freed during a scan, it is protected by some lock until the scan completes). There is a bug however which I haven't got to fixing it yet, if kmemleak fails for some reason (cannot allocate memory) and disables itself, it may access some freed object (though usually hard to trigger). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Wed, Oct 1, 2014 at 3:45 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 10/01/2014 02:39 PM, Catalin Marinas wrote: On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. I did test them together. With this patch applied both tools works without problems. What do you mean works without problems? Are you sure that kmemleak still detects all leaks it is intended to detect? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On 10/01/2014 05:27 PM, Dmitry Vyukov wrote: On Wed, Oct 1, 2014 at 3:45 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 10/01/2014 02:39 PM, Catalin Marinas wrote: On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. I did test them together. With this patch applied both tools works without problems. What do you mean works without problems? Are you sure that kmemleak still detects all leaks it is intended to detect? Yes I'm sure about that. And how kasan could affect on kmemleak's capability to detect leaks? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Wed, Oct 1, 2014 at 6:11 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. I think it's worth testing them together first. I did test them together. With this patch applied both tools works without problems. What do you mean works without problems? Are you sure that kmemleak still detects all leaks it is intended to detect? Yes I'm sure about that. And how kasan could affect on kmemleak's capability to detect leaks? Ah, OK, we don't have quarantine. The idea is that redzones and quarantine will contain parasitical pointers (quarantine is exactly a linked list of freed objects). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin wrote: > 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : >> Looks good to me. >> >> We can disable kasan instrumentation of this file as well. >> > > Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. >> On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin >> wrote: >>> kmalloc internally round up allocation size, and kmemleak >>> uses rounded up size as object's size. This makes kasan >>> to complain while kmemleak scans memory or calculates of object's >>> checksum. The simplest solution here is to disable kasan. >>> >>> Signed-off-by: Andrey Ryabinin >>> --- >>> mm/kmemleak.c | 6 ++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >>> index 3cda50c..9bda1b3 100644 >>> --- a/mm/kmemleak.c >>> +++ b/mm/kmemleak.c >>> @@ -98,6 +98,7 @@ >>> #include >>> #include >>> >>> +#include >>> #include >>> #include >>> #include >>> @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object >>> *object) >>> if (!kmemcheck_is_obj_initialized(object->pointer, object->size)) >>> return false; >>> >>> + kasan_disable_local(); >>> object->checksum = crc32(0, (void *)object->pointer, object->size); >>> + kasan_enable_local(); >>> + >>> return object->checksum != old_csum; >>> } >>> >>> @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, >>> BYTES_PER_POINTER)) >>> continue; >>> >>> + kasan_disable_local(); >>> pointer = *ptr; >>> + kasan_enable_local(); >>> >>> object = find_and_get_object(pointer, 1); >>> if (!object) >>> -- >>> 2.1.1 >>> >> > > > -- > Best regards, > Andrey Ryabinin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks will be missed (if we pretend that tools work together, end users will use them together and miss bugs). I won't be surprised if leak detector touches freed objects under some circumstances as well. We can do this if/when discover actual compatibility issues, of course. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while kmemleak scans memory or calculates of object's checksum. The simplest solution here is to disable kasan. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com --- mm/kmemleak.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3cda50c..9bda1b3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -98,6 +98,7 @@ #include asm/processor.h #include linux/atomic.h +#include linux/kasan.h #include linux/kmemcheck.h #include linux/kmemleak.h #include linux/memory_hotplug.h @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object *object) if (!kmemcheck_is_obj_initialized(object-pointer, object-size)) return false; + kasan_disable_local(); object-checksum = crc32(0, (void *)object-pointer, object-size); + kasan_enable_local(); + return object-checksum != old_csum; } @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, BYTES_PER_POINTER)) continue; + kasan_disable_local(); pointer = *ptr; + kasan_enable_local(); object = find_and_get_object(pointer, 1); if (!object) -- 2.1.1 -- Best regards, Andrey Ryabinin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
2014-09-26 21:10 GMT+04:00 Dmitry Vyukov : > Looks good to me. > > We can disable kasan instrumentation of this file as well. > Yes, but why? I don't think we need that. > On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin > wrote: >> kmalloc internally round up allocation size, and kmemleak >> uses rounded up size as object's size. This makes kasan >> to complain while kmemleak scans memory or calculates of object's >> checksum. The simplest solution here is to disable kasan. >> >> Signed-off-by: Andrey Ryabinin >> --- >> mm/kmemleak.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >> index 3cda50c..9bda1b3 100644 >> --- a/mm/kmemleak.c >> +++ b/mm/kmemleak.c >> @@ -98,6 +98,7 @@ >> #include >> #include >> >> +#include >> #include >> #include >> #include >> @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object >> *object) >> if (!kmemcheck_is_obj_initialized(object->pointer, object->size)) >> return false; >> >> + kasan_disable_local(); >> object->checksum = crc32(0, (void *)object->pointer, object->size); >> + kasan_enable_local(); >> + >> return object->checksum != old_csum; >> } >> >> @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, >> BYTES_PER_POINTER)) >> continue; >> >> + kasan_disable_local(); >> pointer = *ptr; >> + kasan_enable_local(); >> >> object = find_and_get_object(pointer, 1); >> if (!object) >> -- >> 2.1.1 >> > -- Best regards, Andrey Ryabinin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
Looks good to me. We can disable kasan instrumentation of this file as well. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin wrote: > kmalloc internally round up allocation size, and kmemleak > uses rounded up size as object's size. This makes kasan > to complain while kmemleak scans memory or calculates of object's > checksum. The simplest solution here is to disable kasan. > > Signed-off-by: Andrey Ryabinin > --- > mm/kmemleak.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 3cda50c..9bda1b3 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -98,6 +98,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object > *object) > if (!kmemcheck_is_obj_initialized(object->pointer, object->size)) > return false; > > + kasan_disable_local(); > object->checksum = crc32(0, (void *)object->pointer, object->size); > + kasan_enable_local(); > + > return object->checksum != old_csum; > } > > @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, > BYTES_PER_POINTER)) > continue; > > + kasan_disable_local(); > pointer = *ptr; > + kasan_enable_local(); > > object = find_and_get_object(pointer, 1); > if (!object) > -- > 2.1.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
Looks good to me. We can disable kasan instrumentation of this file as well. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while kmemleak scans memory or calculates of object's checksum. The simplest solution here is to disable kasan. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com --- mm/kmemleak.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3cda50c..9bda1b3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -98,6 +98,7 @@ #include asm/processor.h #include linux/atomic.h +#include linux/kasan.h #include linux/kmemcheck.h #include linux/kmemleak.h #include linux/memory_hotplug.h @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object *object) if (!kmemcheck_is_obj_initialized(object-pointer, object-size)) return false; + kasan_disable_local(); object-checksum = crc32(0, (void *)object-pointer, object-size); + kasan_enable_local(); + return object-checksum != old_csum; } @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, BYTES_PER_POINTER)) continue; + kasan_disable_local(); pointer = *ptr; + kasan_enable_local(); object = find_and_get_object(pointer, 1); if (!object) -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while kmemleak scans memory or calculates of object's checksum. The simplest solution here is to disable kasan. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com --- mm/kmemleak.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3cda50c..9bda1b3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -98,6 +98,7 @@ #include asm/processor.h #include linux/atomic.h +#include linux/kasan.h #include linux/kmemcheck.h #include linux/kmemleak.h #include linux/memory_hotplug.h @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object *object) if (!kmemcheck_is_obj_initialized(object-pointer, object-size)) return false; + kasan_disable_local(); object-checksum = crc32(0, (void *)object-pointer, object-size); + kasan_enable_local(); + return object-checksum != old_csum; } @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, BYTES_PER_POINTER)) continue; + kasan_disable_local(); pointer = *ptr; + kasan_enable_local(); object = find_and_get_object(pointer, 1); if (!object) -- 2.1.1 -- Best regards, Andrey Ryabinin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while kmemleak scans memory or calculates of object's checksum. The simplest solution here is to disable kasan. Signed-off-by: Andrey Ryabinin --- mm/kmemleak.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3cda50c..9bda1b3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -98,6 +98,7 @@ #include #include +#include #include #include #include @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object *object) if (!kmemcheck_is_obj_initialized(object->pointer, object->size)) return false; + kasan_disable_local(); object->checksum = crc32(0, (void *)object->pointer, object->size); + kasan_enable_local(); + return object->checksum != old_csum; } @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, BYTES_PER_POINTER)) continue; + kasan_disable_local(); pointer = *ptr; + kasan_enable_local(); object = find_and_get_object(pointer, 1); if (!object) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak
kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while kmemleak scans memory or calculates of object's checksum. The simplest solution here is to disable kasan. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com --- mm/kmemleak.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3cda50c..9bda1b3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -98,6 +98,7 @@ #include asm/processor.h #include linux/atomic.h +#include linux/kasan.h #include linux/kmemcheck.h #include linux/kmemleak.h #include linux/memory_hotplug.h @@ -1113,7 +1114,10 @@ static bool update_checksum(struct kmemleak_object *object) if (!kmemcheck_is_obj_initialized(object-pointer, object-size)) return false; + kasan_disable_local(); object-checksum = crc32(0, (void *)object-pointer, object-size); + kasan_enable_local(); + return object-checksum != old_csum; } @@ -1164,7 +1168,9 @@ static void scan_block(void *_start, void *_end, BYTES_PER_POINTER)) continue; + kasan_disable_local(); pointer = *ptr; + kasan_enable_local(); object = find_and_get_object(pointer, 1); if (!object) -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
