[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87egpbklh3.fsf@rustcorp.com.au>
Date: Sat, 28 Feb 2015 09:31:28 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Andrey Ryabinin <a.ryabinin@...sung.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Andrey Ryabinin <a.ryabinin@...sung.com>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH 1/2] kasan, module, vmalloc: rework shadow allocation for modules
Andrey Ryabinin <a.ryabinin@...sung.com> writes:
> Current approach in handling shadow memory for modules is broken.
>
> Shadow memory could be freed only after memory shadow corresponds
> it is no longer used.
> vfree() called from interrupt context could use memory its
> freeing to store 'struct llist_node' in it:
>
> void vfree(const void *addr)
> {
> ...
> if (unlikely(in_interrupt())) {
> struct vfree_deferred *p = this_cpu_ptr(&vfree_deferred);
> if (llist_add((struct llist_node *)addr, &p->list))
> schedule_work(&p->wq);
>
> Latter this list node used in free_work() which actually frees memory.
> Currently module_memfree() called in interrupt context will free
> shadow before freeing module's memory which could provoke kernel
> crash.
> So shadow memory should be freed after module's memory.
> However, such deallocation order could race with kasan_module_alloc()
> in module_alloc().
>
> Free shadow right before releasing vm area. At this point vfree()'d
> memory is not used anymore and yet not available for other allocations.
> New VM_KASAN flag used to indicate that vm area has dynamically allocated
> shadow memory so kasan frees shadow only if it was previously allocated.
>
> Signed-off-by: Andrey Ryabinin <a.ryabinin@...sung.com>
> Cc: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: Rusty Russell <rusty@...tcorp.com.au>
Acked-by: Rusty Russell <rusty@...tcorp.com.au>
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists