Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Wed, Jun 1, 2016 at 6:31 PM, Alexander Potapenko <gli...@google.com> wrote: > On Wed, Jun 1, 2016 at 5:23 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: >> On 05/31/2016 08:49 PM, Alexander Potapenko wrote: >>> On Tue, May 31, 2016 at 1:5

Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Wed, Jun 1, 2016 at 6:31 PM, Alexander Potapenko wrote: > On Wed, Jun 1, 2016 at 5:23 PM, Andrey Ryabinin > wrote: >> On 05/31/2016 08:49 PM, Alexander Potapenko wrote: >>> On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin >>> wrote: >>>> >>>

Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Wed, Jun 1, 2016 at 5:23 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > On 05/31/2016 08:49 PM, Alexander Potapenko wrote: >> On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> >>> >>> On 05

Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Wed, Jun 1, 2016 at 5:23 PM, Andrey Ryabinin wrote: > On 05/31/2016 08:49 PM, Alexander Potapenko wrote: >> On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin >> wrote: >>> >>> >>> On 05/31/2016 01:44 PM, Alexander Potapenko wrote: >>>&

Re: [PATCH] kasan: change memory hot-add error messages to info messages

s/ryabinin/aryabinin/ On Wed, Jun 1, 2016 at 5:22 PM, Alexander Potapenko <gli...@google.com> wrote: > On Wed, Jun 1, 2016 at 5:20 PM, Shuah Khan <shua...@osg.samsung.com> wrote: >> Change the following memory hot-add error messages to info messages. There >> is no

Re: [PATCH] kasan: change memory hot-add error messages to info messages

s/ryabinin/aryabinin/ On Wed, Jun 1, 2016 at 5:22 PM, Alexander Potapenko wrote: > On Wed, Jun 1, 2016 at 5:20 PM, Shuah Khan wrote: >> Change the following memory hot-add error messages to info messages. There >> is no need for these to be errors. >> >> [8.22

Re: [PATCH] kasan: change memory hot-add error messages to info messages

WARNING: KASAN doesn't support memory hot-add\n"); > - pr_err("Memory hot-add will be disabled\n"); > + pr_info("WARNING: KASAN doesn't support memory hot-add\n"); > + pr_info("Memory hot-add will be disabled\n"); No objections, but let's wait for

Re: [PATCH] kasan: change memory hot-add error messages to info messages

"Memory hot-add will be disabled\n"); > + pr_info("WARNING: KASAN doesn't support memory hot-add\n"); > + pr_info("Memory hot-add will be disabled\n"); No objections, but let's wait for Andrey. > hotplug_memory_notifier(kasan_mem_notifi

[PATCH] mm: kasan: don't touch metadata in kasan_[un]poison_element()

. Signed-off-by: Alexander Potapenko <gli...@google.com> Reported-by: Kuthonuzo Luruo <kuthonuzo.lu...@hpe.com> --- include/linux/kasan.h | 8 ++-- mm/kasan/kasan.c | 48 +--- mm/mempool.c | 5 +++-- mm/slab.c |

[PATCH] mm: kasan: don't touch metadata in kasan_[un]poison_element()

. Signed-off-by: Alexander Potapenko Reported-by: Kuthonuzo Luruo --- include/linux/kasan.h | 8 ++-- mm/kasan/kasan.c | 48 +--- mm/mempool.c | 5 +++-- mm/slab.c | 4 ++-- mm/slab.h | 2 +- 5 files changed

Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > > > On 05/31/2016 01:44 PM, Alexander Potapenko wrote: >> Add a special shadow value to distinguish accesses to KASAN-specific >> allocator metadata. >> >> Unlike Addres

Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata

On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin wrote: > > > On 05/31/2016 01:44 PM, Alexander Potapenko wrote: >> Add a special shadow value to distinguish accesses to KASAN-specific >> allocator metadata. >> >> Unlike AddressSanitizer in the userspace, KASAN

[PATCH] mm, kasan: introduce a special shadow value for allocator metadata

and induce crashes later on. Warning about such corruptions will ease the debugging. Signed-off-by: Alexander Potapenko <gli...@google.com> --- mm/kasan/kasan.c | 15 +++ mm/kasan/kasan.h | 1 + mm/kasan/report.c | 3 +++ 3 files changed, 19 insertions(+) diff --git a/mm

[PATCH] mm, kasan: introduce a special shadow value for allocator metadata

and induce crashes later on. Warning about such corruptions will ease the debugging. Signed-off-by: Alexander Potapenko --- mm/kasan/kasan.c | 15 +++ mm/kasan/kasan.h | 1 + mm/kasan/report.c | 3 +++ 3 files changed, 19 insertions(+) diff --git a/mm/kasan/kasan.c b/mm/kasan

Re: [PATCH v1] [mm] Set page->slab_cache for every page allocated for a kmem_cache.

On Fri, May 27, 2016 at 7:30 PM, Christoph Lameter <c...@linux.com> wrote: > On Fri, 27 May 2016, Alexander Potapenko wrote: > >> It's reasonable to rely on the fact that for every page allocated for a >> kmem_cache the |slab_cache| field points to that cache. Without tha

Re: [PATCH v1] [mm] Set page->slab_cache for every page allocated for a kmem_cache.

On Fri, May 27, 2016 at 7:30 PM, Christoph Lameter wrote: > On Fri, 27 May 2016, Alexander Potapenko wrote: > >> It's reasonable to rely on the fact that for every page allocated for a >> kmem_cache the |slab_cache| field points to that cache. Without that it's >> hard t

[PATCH v1] [mm] Set page->slab_cache for every page allocated for a kmem_cache.

ntine implementation") Signed-off-by: Alexander Potapenko <gli...@google.com> --- mm/slab.c | 7 ++- mm/slub.c | 8 +--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index cc8bbc1..ac6c251 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2703,8 +2703,1

[PATCH v1] [mm] Set page->slab_cache for every page allocated for a kmem_cache.

ntine implementation") Signed-off-by: Alexander Potapenko --- mm/slab.c | 7 ++- mm/slub.c | 8 +--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index cc8bbc1..ac6c251 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2703,8 +2703,13 @@ static void slab_put_

Re: [PATCH v9] mm: kasan: Initial memory quarantine implementation

Hello Alexey, On Tue, May 17, 2016 at 12:03 AM, Alexey Klimov <klimov.li...@gmail.com> wrote: > Hi Alexander, > > On Wed, May 11, 2016 at 6:18 PM, Alexander Potapenko <gli...@google.com> > wrote: >> Quarantine isolates freed objects in a separate queu

Re: [PATCH v9] mm: kasan: Initial memory quarantine implementation

Hello Alexey, On Tue, May 17, 2016 at 12:03 AM, Alexey Klimov wrote: > Hi Alexander, > > On Wed, May 11, 2016 at 6:18 PM, Alexander Potapenko > wrote: >> Quarantine isolates freed objects in a separate queue. The objects are >> returned to the allocator later, which h

Re: [PATCH 3/4] mm/kasan: add API to check memory regions

> > Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexander Potapenko <gli...@google.com> > Cc: Dmitry Vyukov <dvyu...@google.com> > --- > MAINTAINERS | 2 +- > include/linux/kasan-checks.h | 12 > mm/kasan/kas

Re: [PATCH 3/4] mm/kasan: add API to check memory regions

Ryabinin > Cc: Alexander Potapenko > Cc: Dmitry Vyukov > --- > MAINTAINERS | 2 +- > include/linux/kasan-checks.h | 12 > mm/kasan/kasan.c | 12 > 3 files changed, 25 insertions(+), 1 deletion(-) > create mode 10064

Re: [PATCH 2/4] mm/kasan: print name of mem[set,cpy,move]() caller in report

UG: KASAN: out-of-bounds access in memset+0x23/0x40 at > After: > BUG: KASAN: out-of-bounds access in at > > Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Alexander Potapenko <gli...@google.com> > Cc: Dmitry Vyuk

Re: [PATCH 2/4] mm/kasan: print name of mem[set,cpy,move]() caller in report

n memset+0x23/0x40 at > After: > BUG: KASAN: out-of-bounds access in at > > Signed-off-by: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Dmitry Vyukov > --- > mm/kasan/kasan.c | 64 > ++-- > 1 file cha

[PATCH v9] mm: kasan: Initial memory quarantine implementation

uarantine.c b/mm/kasan/quarantine.c new file mode 100644 index 000..4973505 --- /dev/null +++ b/mm/kasan/quarantine.c @@ -0,0 +1,291 @@ +/* + * KASAN quarantine. + * + * Author: Alexander Potapenko <gli...@google.com> + * Copyright (C) 2016 Google, Inc. + * + * Based on code by Dmitry Ch

[PATCH v9] mm: kasan: Initial memory quarantine implementation

n/quarantine.c new file mode 100644 index 000..4973505 --- /dev/null +++ b/mm/kasan/quarantine.c @@ -0,0 +1,291 @@ +/* + * KASAN quarantine. + * + * Author: Alexander Potapenko + * Copyright (C) 2016 Google, Inc. + * + * Based on code by Dmitry Chernenkov. + * + * This program is free software;

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

On Wed, May 11, 2016 at 4:30 PM, Alexander Potapenko <gli...@google.com> wrote: > On Wed, May 11, 2016 at 1:11 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> On 05/11/2016 01:18 PM, Alexander Potapenko wrote: >>> On Tue, May 10, 2016 at 3:3

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

On Wed, May 11, 2016 at 4:30 PM, Alexander Potapenko wrote: > On Wed, May 11, 2016 at 1:11 PM, Andrey Ryabinin > wrote: >> On 05/11/2016 01:18 PM, Alexander Potapenko wrote: >>> On Tue, May 10, 2016 at 3:38 PM, Andrey Ryabinin >>> wrote: >>>>

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

On Wed, May 11, 2016 at 1:11 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > On 05/11/2016 01:18 PM, Alexander Potapenko wrote: >> On Tue, May 10, 2016 at 3:38 PM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> * Fix comment styles, >>

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

On Wed, May 11, 2016 at 1:11 PM, Andrey Ryabinin wrote: > On 05/11/2016 01:18 PM, Alexander Potapenko wrote: >> On Tue, May 10, 2016 at 3:38 PM, Andrey Ryabinin >> wrote: >>> * Fix comment styles, >> yDid you remove the comments from include/linux/ka

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

page_alloc.c > index 497befe..477d938 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -993,7 +993,7 @@ static __always_inline bool free_pages_prepare(struct > page *page, > > trace_mm_page_free(page, order); > kmemcheck_free_shadow(page, order); > - kasan_poison_free_pages(page, order); > + kasan_free_pages(page, order); > > /* > * Check tail pages before head page information is cleared to > diff --git a/mm/slab.c b/mm/slab.c > index 3f20800..cc8bbc1 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -3547,13 +3547,10 @@ free_done: > static inline void __cache_free(struct kmem_cache *cachep, void *objp, > unsigned long caller) > { > -#ifdef CONFIG_KASAN > + /* Put the object into the quarantine, don't touch it for now. */ > if (kasan_slab_free(cachep, objp)) > - /* The object has been put into the quarantine, don't touch it > -* for now. > -*/ > return; > -#endif > + > ___cache_free(cachep, objp, caller); > } > > diff --git a/mm/slub.c b/mm/slub.c > index f41360e..538c858 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -1319,7 +1319,7 @@ static inline void kmalloc_large_node_hook(void *ptr, > size_t size, gfp_t flags) > static inline void kfree_hook(const void *x) > { > kmemleak_free(x); > - kasan_poison_kfree_large(x); > + kasan_kfree_large(x); > } > > static inline void slab_free_hook(struct kmem_cache *s, void *x) > @@ -1344,7 +1344,7 @@ static inline void slab_free_hook(struct kmem_cache *s, > void *x) > if (!(s->flags & SLAB_DEBUG_OBJECTS)) > debug_check_no_obj_freed(x, s->object_size); > > - kasan_poison_slab_free(s, x); > + kasan_slab_free(s, x); > } > > static inline void slab_free_freelist_hook(struct kmem_cache *s, > -- > 2.7.3 > -- 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

Re: [PATCH] mm-kasan-initial-memory-quarantine-implementation-v8-fix

ee_pages(element, (unsigned long)pool->pool_data); > } > > static void kasan_unpoison_element(mempool_t *pool, void *element, gfp_t > flags) > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 497befe..477d938 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_al

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 9:57 PM, Andrey Ryabinin <ryabinin@gmail.com> wrote: > 2016-05-10 20:17 GMT+03:00 Alexander Potapenko <gli...@google.com>: >> On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin <ryabinin@gmail.com> >> wrote: >>> 2016-03-1

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 9:57 PM, Andrey Ryabinin wrote: > 2016-05-10 20:17 GMT+03:00 Alexander Potapenko : >> On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin >> wrote: >>> 2016-03-15 13:10 GMT+03:00 Alexander Potapenko : >>> >>>> >>>>

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin <ryabinin@gmail.com> wrote: > 2016-03-15 13:10 GMT+03:00 Alexander Potapenko <gli...@google.com>: > >> >> static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } >> static inline

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin wrote: > 2016-03-15 13:10 GMT+03:00 Alexander Potapenko : > >> >> static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } >> static inline void kasan_free_shadow(const struct vm_struct *vm) {} >>

Re: [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle

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

Re: [PATCH for v4.6] lib/stackdepot: avoid to return 0 handle

+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; &

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

On Mon, May 2, 2016 at 5:13 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote: > On 5/2/16 22:23, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 3:51 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote: >>> >>> OK, thanks. >>> >>> An

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

On Mon, May 2, 2016 at 5:13 PM, Chen Gang wrote: > On 5/2/16 22:23, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 3:51 PM, Chen Gang wrote: >>> >>> OK, thanks. >>> >>> And for "kasan_depth == 1", I guess, its meaning is related wi

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

On Mon, May 2, 2016 at 3:51 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote: > On 5/2/16 20:42, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 2:27 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote: >>> On 5/2/16 19:21, Dmitry Vyukov wrote: >>>> >&g

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

On Mon, May 2, 2016 at 3:51 PM, Chen Gang wrote: > On 5/2/16 20:42, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 2:27 PM, Chen Gang wrote: >>> On 5/2/16 19:21, Dmitry Vyukov wrote: >>>> >>>> Signed counter looks good to me. >>> >&g

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

to bark loudly, so that the unmatched annotations are noticed and >> fixed. >> > > How about BUG_ON()? As noted by Dmitry in an offline discussion, we shouldn't bail out as long as it's possible to proceed, otherwise the kernel may become very hard to debug. A mismatching annotation isn't a case in which we can't proceed with the execution. > > Thanks. > -- > Chen Gang (陈刚) > > Managing Natural Environments is the Duty of Human Beings. -- 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

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

excessive disable, then we can end up with ignores enabled >> permanently. If we ignore an excessive enable, then we can end up with >> ignores enabled when they should not be enabled. The main point here >> is to bark loudly, so that the unmatched annotations are noticed and &

Re: [PATCH] kasan: improve double-free detection

ke: >> >> /* Sets status to KASAN_STATE_LOCKED if the current status is equal to >> old_state, returns current state. Waits while current state equals >> KASAN_STATE_LOCKED. */ >> u32 kasan_lock_if_state_equals(struct kasan_alloc_meta *meta, u32 old_state); >> >> /* Changes state from KASAN_STATE_LOCKED to new_state */ >> void kasan_unlock_and_set_status(struct kasan_alloc_meta *meta, u32 >> new_state); >> >> Then free can be expressed as: >> >> if (kasan_lock_if_state_equals(meta, KASAN_STATE_ALLOC) == >> KASAN_STATE_ALLOC) { >>free_info = get_free_info(cache, object); >>quarantine_put(free_info, cache); >>set_track(_info->track, GFP_NOWAIT); >>kasan_poison_slab_free(cache, object); >>kasan_unlock_and_set_status(meta, KASAN_STATE_QUARANTINE); >>return true; >> } >> >> And on the reporting path we would need to lock the header, read all >> state, unlock the header. >> >> Does it make sense? >> >> Please add the test as well. We need to start collecting tests for all >> these tricky corner cases. >> >> Thanks! -- 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

Re: [PATCH] kasan: improve double-free detection

The same is true for all other state transitions (e.g. >> use-after-free racing with the object being pushed out of the >> quarantine). We could introduce 2 helper functions like: >> >> /* Sets status to KASAN_STATE_LOCKED if the current status is equal to >> old_state,

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

> > static inline bool kasan_report_enabled(void) > { > - return !current->kasan_depth; > + return !!current->kasan_depth; > } > > void kasan_report(unsigned long addr, size_t size, > -- > 1.9.3 > -- Alexander Potapenko Software Engineer Googl

Re: [PATCH] mm/kasan/kasan.h: Fix boolean checking issue for kasan_report_enabled()

an_depth; > + return !!current->kasan_depth; > } > > void kasan_report(unsigned long addr, size_t size, > -- > 1.9.3 > -- 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

Re: [PATCH] include/linux/kasan.h: Notice about 0 for kasan_[dis/en]able_current()

On Mon, May 2, 2016 at 1:20 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote: > On 5/2/16 18:49, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 7:35 AM, <cheng...@emindsoft.com.cn> wrote: >>> >>> According to their comments and the kasan_depth's ini

Re: [PATCH] include/linux/kasan.h: Notice about 0 for kasan_[dis/en]able_current()

On Mon, May 2, 2016 at 1:20 PM, Chen Gang wrote: > On 5/2/16 18:49, Alexander Potapenko wrote: >> On Mon, May 2, 2016 at 7:35 AM, wrote: >>> >>> According to their comments and the kasan_depth's initialization, if >>> kasan_depth is zero, it means disable. So

Re: [PATCH] include/linux/kasan.h: Notice about 0 for kasan_[dis/en]able_current()

> size_t new_size, > > static inline void kasan_slab_alloc(struct kmem_cache *s, void *object, >gfp_t flags) {} > -/* kasan_slab_free() returns true if the object has been put into quarantine. > - */ > static inline bool kasan_slab_free(struct kmem_cache *s, vo

Re: [PATCH] include/linux/kasan.h: Notice about 0 for kasan_[dis/en]able_current()

gfp_t flags) {} > -/* kasan_slab_free() returns true if the object has been put into quarantine. > - */ > static inline bool kasan_slab_free(struct kmem_cache *s, void *object) > { > return false; > -- > 1.9.3 > Acked-by: Alexander Pota

Re: [PATCH v2 1/2] mm, kasan: don't call kasan_krealloc() from ksize().

On Fri, Apr 22, 2016 at 11:32 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Wed, 13 Apr 2016 13:20:09 +0200 Alexander Potapenko <gli...@google.com> > wrote: > >> Instead of calling kasan_krealloc(), which replaces the memory allocation >> stack

Re: [PATCH v2 1/2] mm, kasan: don't call kasan_krealloc() from ksize().

On Fri, Apr 22, 2016 at 11:32 PM, Andrew Morton wrote: > On Wed, 13 Apr 2016 13:20:09 +0200 Alexander Potapenko > wrote: > >> Instead of calling kasan_krealloc(), which replaces the memory allocation >> stack ID (if stack depot is used), just unpoison the whole memo

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

Hi James, On Wed, Apr 13, 2016 at 6:12 PM, James Morse <james.mo...@arm.com> wrote: > Hi Alex, > > On 12/04/16 12:17, Alexander Potapenko wrote: >> I also wonder if we can, say, land the change to arch/arm64/Kconfig >> separately from makefile changes that improve the

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

Hi James, On Wed, Apr 13, 2016 at 6:12 PM, James Morse wrote: > Hi Alex, > > On 12/04/16 12:17, Alexander Potapenko wrote: >> I also wonder if we can, say, land the change to arch/arm64/Kconfig >> separately from makefile changes that improve the precision or fix >> c

[PATCH v2] lib/stackdepot.c: allow the stack trace hash to be zero

Do not bail out from depot_save_stack() if the stack trace has zero hash. Initially depot_save_stack() silently dropped stack traces with zero hashes, however there's actually no point in reserving this zero value. Reported-by: Joonsoo Kim <iamjoonsoo@lge.com> Signed-off-by: Ale

[PATCH v2] lib/stackdepot.c: allow the stack trace hash to be zero

Do not bail out from depot_save_stack() if the stack trace has zero hash. Initially depot_save_stack() silently dropped stack traces with zero hashes, however there's actually no point in reserving this zero value. Reported-by: Joonsoo Kim Signed-off-by: Alexander Potapenko --- lib

[PATCH v2 2/2] mm, kasan: add a ksize() test

Add a test that makes sure ksize() unpoisons the whole chunk. Signed-off-by: Alexander Potapenko <gli...@google.com> --- v2: - splitted v1 into two patches --- lib/test_kasan.c | 20 1 file changed, 20 insertions(+) diff --git a/lib/test_kasan.c b/lib/test_kasan.c

[PATCH v2 2/2] mm, kasan: add a ksize() test

Add a test that makes sure ksize() unpoisons the whole chunk. Signed-off-by: Alexander Potapenko --- v2: - splitted v1 into two patches --- lib/test_kasan.c | 20 1 file changed, 20 insertions(+) diff --git a/lib/test_kasan.c b/lib/test_kasan.c index 82169fb..48e5a0b

[PATCH v2 1/2] mm, kasan: don't call kasan_krealloc() from ksize().

Instead of calling kasan_krealloc(), which replaces the memory allocation stack ID (if stack depot is used), just unpoison the whole memory chunk. Signed-off-by: Alexander Potapenko <gli...@google.com> --- v2: - splitted v1 into two patches --- mm/slab.c | 2 +- mm/slub.c | 5 +++-- 2

[PATCH v2 1/2] mm, kasan: don't call kasan_krealloc() from ksize().

Instead of calling kasan_krealloc(), which replaces the memory allocation stack ID (if stack depot is used), just unpoison the whole memory chunk. Signed-off-by: Alexander Potapenko --- v2: - splitted v1 into two patches --- mm/slab.c | 2 +- mm/slub.c | 5 +++-- 2 files changed, 4 insertions

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Mon, Apr 4, 2016 at 7:30 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Thu, Mar 31, 2016 at 7:18 PM, Alexander Potapenko <gli...@google.com> > wrote: >> On Thu, Mar 31, 2016 at 7:14 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >>> On Thu, Mar

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Mon, Apr 4, 2016 at 7:30 PM, Dmitry Vyukov wrote: > On Thu, Mar 31, 2016 at 7:18 PM, Alexander Potapenko > wrote: >> On Thu, Mar 31, 2016 at 7:14 PM, Mark Rutland wrote: >>> On Thu, Mar 31, 2016 at 06:33:24PM +0200, Alexander Potapenko wrote: >>>> On T

[PATCH v1] lib/stackdepot.c: allow the stack trace hash to be zero

There's actually no point in reserving the zero hash value. Reported-by: Joonsoo Kim --- lib/stackdepot.c | 4 1 file changed, 4 deletions(-) diff --git a/lib/stackdepot.c b/lib/stackdepot.c index 654c9d8..9e0b031 100644 --- a/lib/stackdepot.c +++

[PATCH v1] lib/stackdepot.c: allow the stack trace hash to be zero

There's actually no point in reserving the zero hash value. Reported-by: Joonsoo Kim --- lib/stackdepot.c | 4 1 file changed, 4 deletions(-) diff --git a/lib/stackdepot.c b/lib/stackdepot.c index 654c9d8..9e0b031 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -210,10 +210,6 @@

[PATCH v1] mm, kasan: don't call kasan_krealloc() from ksize(). Add a ksize() test.

Instead of calling kasan_krealloc(), which replaces the memory allocation stack ID (if stack depot is used), just unpoison the whole memory chunk. Add a test that makes sure ksize() unpoisons the whole chunk. Signed-off-by: Alexander Potapenko <gli...@google.com> --- lib/test_kasan.

[PATCH v1] mm, kasan: don't call kasan_krealloc() from ksize(). Add a ksize() test.

Instead of calling kasan_krealloc(), which replaces the memory allocation stack ID (if stack depot is used), just unpoison the whole memory chunk. Add a test that makes sure ksize() unpoisons the whole chunk. Signed-off-by: Alexander Potapenko --- lib/test_kasan.c | 20 mm

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Mon, Apr 11, 2016 at 4:39 PM, Alexander Potapenko <gli...@google.com> wrote: > On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: >> On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote: >>> +depot_stack_handle_t depot

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Mon, Apr 11, 2016 at 4:39 PM, Alexander Potapenko wrote: > On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim wrote: >> On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote: >>> +depot_stack_handle_t depot_save_stack(struct

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: > On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote: >> +depot_stack_handle_t depot_save_stack(struct stack_trace *trace, >> + gfp_t alloc_flags) &g

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim wrote: > On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote: >> +depot_stack_handle_t depot_save_stack(struct stack_trace *trace, >> + gfp_t alloc_flags) >>

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 7:14 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Thu, Mar 31, 2016 at 06:33:24PM +0200, Alexander Potapenko wrote: >> On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >> > On Thu, Mar 31, 2016 at 05:09:29PM +0

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 7:14 PM, Mark Rutland wrote: > On Thu, Mar 31, 2016 at 06:33:24PM +0200, Alexander Potapenko wrote: >> On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland wrote: >> > On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: >> >>

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 6:33 PM, Alexander Potapenko <gli...@google.com> wrote: > On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >> On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: >>> On Thu, Mar 31, 2016 at 4:

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 6:33 PM, Alexander Potapenko wrote: > On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland wrote: >> On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: >>> On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland wrote: >>> > Hi, >>>

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: >> On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >> > Hi, >> > >> > On

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 6:00 PM, Mark Rutland wrote: > On Thu, Mar 31, 2016 at 05:09:29PM +0200, Alexander Potapenko wrote: >> On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland wrote: >> > Hi, >> > >> > On Thu, Mar 31, 2016 at 03:54:45PM +0200, Alexander Pota

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > Hi, > > On Thu, Mar 31, 2016 at 03:54:45PM +0200, Alexander Potapenko wrote: >> Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of >> arch/arm64/lib/delay.c > > Why do we d

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 4:29 PM, Mark Rutland wrote: > Hi, > > On Thu, Mar 31, 2016 at 03:54:45PM +0200, Alexander Potapenko wrote: >> Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of >> arch/arm64/lib/delay.c > > Why do we disable instrumentation of delay.

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 3:54 PM, Alexander Potapenko <gli...@google.com> wrote: > Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of > arch/arm64/lib/delay.c > > Signed-off-by: Alexander Potapenko <gli...@google.com> > --- > arch/arm64/Kconfig | 1 +

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

On Thu, Mar 31, 2016 at 3:54 PM, Alexander Potapenko wrote: > Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of > arch/arm64/lib/delay.c > > Signed-off-by: Alexander Potapenko > --- > arch/arm64/Kconfig | 1 + > arch/arm64/lib/Makefile | 3 +++ > 2 fil

[PATCH v1] arm64: allow building with kcov coverage on ARM64

Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of arch/arm64/lib/delay.c Signed-off-by: Alexander Potapenko <gli...@google.com> --- arch/arm64/Kconfig | 1 + arch/arm64/lib/Makefile | 3 +++ 2 files changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/K

[PATCH v1] arm64: allow building with kcov coverage on ARM64

Add ARCH_HAS_KCOV to ARM64 config. Disable instrumentation of arch/arm64/lib/delay.c Signed-off-by: Alexander Potapenko --- arch/arm64/Kconfig | 1 + arch/arm64/lib/Makefile | 3 +++ 2 files changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4f43622

[PATCH v1] mm, kasan: fix compilation for CONFIG_SLAB

Add the missing argument to set_track(). Fixes: cd11016e5f5212c13c0cec7384a525edc93b4921 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") Signed-off-by: Alexander Potapenko <gli...@google.com> --- mm/kasan/kasan.c | 2 +- 1 file changed, 1 insertion(+), 1 d

[PATCH v1] mm, kasan: fix compilation for CONFIG_SLAB

Add the missing argument to set_track(). Fixes: cd11016e5f5212c13c0cec7384a525edc93b4921 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") Signed-off-by: Alexander Potapenko --- mm/kasan/kasan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: KASAN overhead?

On Sun, Mar 20, 2016 at 2:14 AM, <valdis.kletni...@vt.edu> wrote: > On Sat, 19 Mar 2016 13:13:59 +0100, Alexander Potapenko said: > >> Which GCC version were you using? Are you sure it didn't accidentally >> enable the outline instrumentation (e.g. if the compiler is too

Re: KASAN overhead?

On Sun, Mar 20, 2016 at 2:14 AM, wrote: > On Sat, 19 Mar 2016 13:13:59 +0100, Alexander Potapenko said: > >> Which GCC version were you using? Are you sure it didn't accidentally >> enable the outline instrumentation (e.g. if the compiler is too old)? > > gcc --v

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Tue, Mar 15, 2016 at 1:22 PM, Andrey Ryabinin <ryabinin@gmail.com> wrote: > 2016-03-15 12:27 GMT+03:00 Alexander Potapenko <gli...@google.com>: >> On Mon, Mar 14, 2016 at 5:56 PM, Andrey Ryabinin <ryabinin@gmail.com> >> wrote: >>> 2016-03-1

Re: [PATCH v7 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

On Tue, Mar 15, 2016 at 1:22 PM, Andrey Ryabinin wrote: > 2016-03-15 12:27 GMT+03:00 Alexander Potapenko : >> On Mon, Mar 14, 2016 at 5:56 PM, Andrey Ryabinin >> wrote: >>> 2016-03-14 13:43 GMT+03:00 Alexander Potapenko : >>> >>>>

Re: [PATCH] af_unix: closed SOCK_SEQPACKET socketpair must get SIGPIPE

On Tue, Mar 15, 2016 at 2:46 PM, David Laight <david.lai...@aculab.com> wrote: > From: Alexander Potapenko >> Sent: 15 March 2016 09:04 >> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET >> socketpair with MSG_NOSIGNAL flag set must result in

Re: [PATCH] af_unix: closed SOCK_SEQPACKET socketpair must get SIGPIPE

On Tue, Mar 15, 2016 at 2:46 PM, David Laight wrote: > From: Alexander Potapenko >> Sent: 15 March 2016 09:04 >> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET >> socketpair with MSG_NOSIGNAL flag set must result in a SIGPIPE if the >> so

Re: [PATCH] af_unix: closed SOCK_SEQPACKET socketpair must get SIGPIPE

On Tue, Mar 15, 2016 at 2:20 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2016-03-15 at 10:03 +0100, Alexander Potapenko wrote: >> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET >> socketpair with MSG_NOSIGNAL flag set must result in a SIG

Re: [PATCH] af_unix: closed SOCK_SEQPACKET socketpair must get SIGPIPE

On Tue, Mar 15, 2016 at 2:20 PM, Eric Dumazet wrote: > On Tue, 2016-03-15 at 10:03 +0100, Alexander Potapenko wrote: >> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET >> socketpair with MSG_NOSIGNAL flag set must result in a SIGPIPE if the >> socket i

[PATCH v8 4/7] arch, ftrace: For KASAN put hard/soft IRQ entries into separate sections

the __softirq_entry macro which is similar to __irq_entry, but puts the corresponding functions to the .softirqentry.text section. Signed-off-by: Alexander Potapenko <gli...@google.com> Acked-by: Steven Rostedt <rost...@goodmis.org> --- v2: - per request from Steven Rostedt, moved the

[PATCH v8 4/7] arch, ftrace: For KASAN put hard/soft IRQ entries into separate sections

the __softirq_entry macro which is similar to __irq_entry, but puts the corresponding functions to the .softirqentry.text section. Signed-off-by: Alexander Potapenko Acked-by: Steven Rostedt --- v2: - per request from Steven Rostedt, moved the declarations of __softirq_entry and __irq_entry to v3

[PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

support is only enabled in SLAB allocator. Unification of KASAN features in SLAB and SLUB will be done later. This patch is based on the "mm: kasan: quarantine" patch originally prepared by Dmitry Chernenkov. Signed-off-by: Alexander Potapenko <gli...@google.com> --- v2: - added co

[PATCH v8 2/7] mm, kasan: SLAB support

Add KASAN hooks to SLAB allocator. This patch is based on the "mm: kasan: unified support for SLUB and SLAB allocators" patch originally prepared by Dmitry Chernenkov. Signed-off-by: Alexander Potapenko <gli...@google.com> --- v3: - minor description changes - store d

[PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

support is only enabled in SLAB allocator. Unification of KASAN features in SLAB and SLUB will be done later. This patch is based on the "mm: kasan: quarantine" patch originally prepared by Dmitry Chernenkov. Signed-off-by: Alexander Potapenko --- v2: - added copyright comments - p

[PATCH v8 2/7] mm, kasan: SLAB support

Add KASAN hooks to SLAB allocator. This patch is based on the "mm: kasan: unified support for SLUB and SLAB allocators" patch originally prepared by Dmitry Chernenkov. Signed-off-by: Alexander Potapenko --- v3: - minor description changes - store deallocation info in kasan_slab_

<    3   4   5   6   7   8   9   10   11   >