[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210304173132.6696eb2a357edf835a5033ee@linux-foundation.org>
Date: Thu, 4 Mar 2021 17:31:32 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alexander Potapenko <glider@...gle.com>
Cc: Dmitriy Vyukov <dvyukov@...gle.com>,
Andrey Konovalov <andreyknvl@...gle.com>,
Jann Horn <jannh@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
kasan-dev <kasan-dev@...glegroups.com>,
Marco Elver <elver@...gle.com>
Subject: Re: [PATCH mm] kfence, slab: fix cache_alloc_debugcheck_after() for
bulk allocations
On Thu, 4 Mar 2021 22:05:48 +0100 Alexander Potapenko <glider@...gle.com> wrote:
> On Thu, Mar 4, 2021 at 9:53 PM Marco Elver <elver@...gle.com> wrote:
> >
> > cache_alloc_debugcheck_after() performs checks on an object, including
> > adjusting the returned pointer. None of this should apply to KFENCE
> > objects. While for non-bulk allocations, the checks are skipped when we
> > allocate via KFENCE, for bulk allocations cache_alloc_debugcheck_after()
> > is called via cache_alloc_debugcheck_after_bulk().
>
> @Andrew, is this code used by anyone?
> As far as I understand, it cannot be enabled by any config option, so
> nobody really tests it.
> If it is still needed, shall we promote #if DEBUGs in slab.c to a
> separate config option, or maybe this code can be safely removed?
It's all used:
#ifdef CONFIG_DEBUG_SLAB
#define DEBUG 1
#define STATS 1
#define FORCED_DEBUG 1
#else
#define DEBUG 0
#define STATS 0
#define FORCED_DEBUG 0
#endif
Powered by blists - more mailing lists