From: Andrey Ryabinin <aryabinin@virtuozzo.com> To: Andrey Konovalov <andreyknvl@google.com>, Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Alexander Potapenko <glider@google.com>, Dmitry Vyukov <dvyukov@google.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Cc: Kostya Serebryany <kcc@google.com> Subject: Re: [PATCH] kasan, slub: fix handling of kasan_slab_free hook Date: Fri, 2 Mar 2018 15:10:21 +0300 [thread overview] Message-ID: <26dd94c5-19ca-dca6-07b8-7103f53c0130@virtuozzo.com> (raw) In-Reply-To: <083f58501e54731203801d899632d76175868e97.1519400992.git.andreyknvl@google.com> On 02/23/2018 06:53 PM, Andrey Konovalov wrote: > The kasan_slab_free hook's return value denotes whether the reuse of a > slab object must be delayed (e.g. when the object is put into memory > qurantine). > > The current way SLUB handles this hook is by ignoring its return value > and hardcoding checks similar (but not exactly the same) to the ones > performed in kasan_slab_free, which is prone to making mistakes. > What are those differences exactly? And what problems do they cause? Answers to these questions should be in the changelog. > This patch changes the way SLUB handles this by: > 1. taking into account the return value of kasan_slab_free for each of > the objects, that are being freed; > 2. reconstructing the freelist of objects to exclude the ones, whose > reuse must be delayed. > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > --- > > @@ -2965,14 +2974,13 @@ static __always_inline void slab_free(struct kmem_cache *s, struct page *page, > void *head, void *tail, int cnt, > unsigned long addr) > { > - slab_free_freelist_hook(s, head, tail); > /* > - * slab_free_freelist_hook() could have put the items into quarantine. > - * If so, no need to free them. > + * With KASAN enabled slab_free_freelist_hook modifies the freelist > + * to remove objects, whose reuse must be delayed. > */ > - if (s->flags & SLAB_KASAN && !(s->flags & SLAB_TYPESAFE_BY_RCU)) > - return; > - do_slab_free(s, page, head, tail, cnt, addr); > + slab_free_freelist_hook(s, &head, &tail); > + if (head != NULL) That's an additional branch in non-debug fast-path. Find a way to avoid this. > + do_slab_free(s, page, head, tail, cnt, addr); > } > > #ifdef CONFIG_KASAN >
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <aryabinin@virtuozzo.com> To: Andrey Konovalov <andreyknvl@google.com>, Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Alexander Potapenko <glider@google.com>, Dmitry Vyukov <dvyukov@google.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Cc: Kostya Serebryany <kcc@google.com> Subject: Re: [PATCH] kasan, slub: fix handling of kasan_slab_free hook Date: Fri, 2 Mar 2018 15:10:21 +0300 [thread overview] Message-ID: <26dd94c5-19ca-dca6-07b8-7103f53c0130@virtuozzo.com> (raw) In-Reply-To: <083f58501e54731203801d899632d76175868e97.1519400992.git.andreyknvl@google.com> On 02/23/2018 06:53 PM, Andrey Konovalov wrote: > The kasan_slab_free hook's return value denotes whether the reuse of a > slab object must be delayed (e.g. when the object is put into memory > qurantine). > > The current way SLUB handles this hook is by ignoring its return value > and hardcoding checks similar (but not exactly the same) to the ones > performed in kasan_slab_free, which is prone to making mistakes. > What are those differences exactly? And what problems do they cause? Answers to these questions should be in the changelog. > This patch changes the way SLUB handles this by: > 1. taking into account the return value of kasan_slab_free for each of > the objects, that are being freed; > 2. reconstructing the freelist of objects to exclude the ones, whose > reuse must be delayed. > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > --- > > @@ -2965,14 +2974,13 @@ static __always_inline void slab_free(struct kmem_cache *s, struct page *page, > void *head, void *tail, int cnt, > unsigned long addr) > { > - slab_free_freelist_hook(s, head, tail); > /* > - * slab_free_freelist_hook() could have put the items into quarantine. > - * If so, no need to free them. > + * With KASAN enabled slab_free_freelist_hook modifies the freelist > + * to remove objects, whose reuse must be delayed. > */ > - if (s->flags & SLAB_KASAN && !(s->flags & SLAB_TYPESAFE_BY_RCU)) > - return; > - do_slab_free(s, page, head, tail, cnt, addr); > + slab_free_freelist_hook(s, &head, &tail); > + if (head != NULL) That's an additional branch in non-debug fast-path. Find a way to avoid this. > + do_slab_free(s, page, head, tail, cnt, addr); > } > > #ifdef CONFIG_KASAN > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-03-02 12:09 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-23 15:53 [PATCH] kasan, slub: fix handling of kasan_slab_free hook Andrey Konovalov 2018-02-23 15:53 ` Andrey Konovalov 2018-03-02 12:10 ` Andrey Ryabinin [this message] 2018-03-02 12:10 ` Andrey Ryabinin 2018-03-06 17:42 ` Andrey Konovalov 2018-03-06 17:42 ` Andrey Konovalov 2018-03-06 17:47 ` Andrey Konovalov 2018-03-06 17:47 ` Andrey Konovalov 2018-03-07 12:43 ` Andrey Ryabinin 2018-03-07 12:43 ` Andrey Ryabinin
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=26dd94c5-19ca-dca6-07b8-7103f53c0130@virtuozzo.com \ --to=aryabinin@virtuozzo.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=cl@linux.com \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=kasan-dev@googlegroups.com \ --cc=kcc@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penberg@kernel.org \ --cc=rientjes@google.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: linkBe 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.