All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: andrey.konovalov@linux.dev
Cc: Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	kasan-dev@googlegroups.com, Evgenii Stepanov <eugenis@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [PATCH RFC 00/20] kasan: save mempool stack traces
Date: Wed, 22 Nov 2023 18:13:23 +0100	[thread overview]
Message-ID: <ZV42s_c3BzCAEwgu@elver.google.com> (raw)
In-Reply-To: <cover.1699297309.git.andreyknvl@google.com>

On Mon, Nov 06, 2023 at 09:10PM +0100, andrey.konovalov@linux.dev wrote:
> From: Andrey Konovalov <andreyknvl@google.com>
> 
> This series updates KASAN to save alloc and free stack traces for
> secondary-level allocators that cache and reuse allocations internally
> instead of giving them back to the underlying allocator (e.g. mempool).

Nice.

> As a part of this change, introduce and document a set of KASAN hooks:
> 
> bool kasan_mempool_poison_pages(struct page *page, unsigned int order);
> void kasan_mempool_unpoison_pages(struct page *page, unsigned int order);
> bool kasan_mempool_poison_object(void *ptr);
> void kasan_mempool_unpoison_object(void *ptr, size_t size);
> 
> and use them in the mempool code.
> 
> Besides mempool, skbuff and io_uring also cache allocations and already
> use KASAN hooks to poison those. Their code is updated to use the new
> mempool hooks.
>
> The new hooks save alloc and free stack traces (for normal kmalloc and
> slab objects; stack traces for large kmalloc objects and page_alloc are
> not supported by KASAN yet), improve the readability of the users' code,
> and also allow the users to prevent double-free and invalid-free bugs;
> see the patches for the details.
> 
> I'm posting this series as an RFC, as it has a few non-trivial-to-resolve
> conflicts with the stack depot eviction patches. I'll rebase the series and
> resolve the conflicts once the stack depot patches are in the mm tree.
> 
> Andrey Konovalov (20):
>   kasan: rename kasan_slab_free_mempool to kasan_mempool_poison_object
>   kasan: move kasan_mempool_poison_object
>   kasan: document kasan_mempool_poison_object
>   kasan: add return value for kasan_mempool_poison_object
>   kasan: introduce kasan_mempool_unpoison_object
>   kasan: introduce kasan_mempool_poison_pages
>   kasan: introduce kasan_mempool_unpoison_pages
>   kasan: clean up __kasan_mempool_poison_object
>   kasan: save free stack traces for slab mempools
>   kasan: clean up and rename ____kasan_kmalloc
>   kasan: introduce poison_kmalloc_large_redzone
>   kasan: save alloc stack traces for mempool
>   mempool: use new mempool KASAN hooks
>   mempool: introduce mempool_use_prealloc_only
>   kasan: add mempool tests
>   kasan: rename pagealloc tests
>   kasan: reorder tests
>   kasan: rename and document kasan_(un)poison_object_data
>   skbuff: use mempool KASAN hooks
>   io_uring: use mempool KASAN hook
> 
>  include/linux/kasan.h   | 161 +++++++-
>  include/linux/mempool.h |   2 +
>  io_uring/alloc_cache.h  |   5 +-
>  mm/kasan/common.c       | 221 ++++++----
>  mm/kasan/kasan_test.c   | 876 +++++++++++++++++++++++++++-------------
>  mm/mempool.c            |  49 ++-
>  mm/slab.c               |  10 +-
>  mm/slub.c               |   4 +-
>  net/core/skbuff.c       |  10 +-
>  9 files changed, 940 insertions(+), 398 deletions(-)

Overall LGTM and the majority of it is cleanups, so I think once the
stack depot patches are in the mm tree, just send v1 of this series.


  parent reply	other threads:[~2023-11-22 17:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 20:10 [PATCH RFC 00/20] kasan: save mempool stack traces andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 01/20] kasan: rename kasan_slab_free_mempool to kasan_mempool_poison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 02/20] kasan: move kasan_mempool_poison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 03/20] kasan: document kasan_mempool_poison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 04/20] kasan: add return value for kasan_mempool_poison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 05/20] kasan: introduce kasan_mempool_unpoison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 06/20] kasan: introduce kasan_mempool_poison_pages andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 07/20] kasan: introduce kasan_mempool_unpoison_pages andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 08/20] kasan: clean up __kasan_mempool_poison_object andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 09/20] kasan: save free stack traces for slab mempools andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 10/20] kasan: clean up and rename ____kasan_kmalloc andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 11/20] kasan: introduce poison_kmalloc_large_redzone andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 12/20] kasan: save alloc stack traces for mempool andrey.konovalov
2023-11-07 23:08   ` kernel test robot
2023-11-06 20:10 ` [PATCH RFC 13/20] mempool: use new mempool KASAN hooks andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 14/20] mempool: introduce mempool_use_prealloc_only andrey.konovalov
2023-11-22 17:20   ` Marco Elver
2023-11-23 18:06     ` Andrey Konovalov
2023-11-23 18:47       ` Marco Elver
2023-11-06 20:10 ` [PATCH RFC 15/20] kasan: add mempool tests andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 16/20] kasan: rename pagealloc tests andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 17/20] kasan: reorder tests andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 18/20] kasan: rename and document kasan_(un)poison_object_data andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 19/20] skbuff: use mempool KASAN hooks andrey.konovalov
2023-11-06 20:10 ` [PATCH RFC 20/20] io_uring: use mempool KASAN hook andrey.konovalov
2023-11-22 17:13 ` Marco Elver [this message]
2023-11-23 18:06   ` [PATCH RFC 00/20] kasan: save mempool stack traces Andrey Konovalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZV42s_c3BzCAEwgu@elver.google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrey.konovalov@linux.dev \
    --cc=andreyknvl@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryabinin.a.a@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.