On Thu, 2020-12-03 at 12:28 -0800, Andrew Morton wrote:
> On Thu, 3 Dec 2020 13:46:59 +0100 Andrey Konovalov
> wrote:
>
> > > #define QLIST_INIT { NULL, NULL, 0 }
> > > @@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info,
> > > struct kmem_cache *cache)
> > >
On Thu, 3 Dec 2020 13:46:59 +0100 Andrey Konovalov
wrote:
> > #define QLIST_INIT { NULL, NULL, 0 }
> > @@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info,
> > struct kmem_cache *cache)
> > local_irq_save(flags);
> >
> > q = this_cpu_ptr(_quarantine);
> > +
On Wed, 2020-12-02 at 15:53 +0800, Kuan-Ying Lee wrote:
> We hit this issue in our internal test.
> When enabling generic kasan, a kfree()'d object is put into per-cpu
> quarantine first. If the cpu goes offline, object still remains in
> the per-cpu quarantine. If we call kmem_cache_destroy()
On Wed, Dec 2, 2020 at 8:58 AM Kuan-Ying Lee wrote:
>
> We hit this issue in our internal test.
> When enabling generic kasan, a kfree()'d object is put into per-cpu
> quarantine first. If the cpu goes offline, object still remains in
> the per-cpu quarantine. If we call kmem_cache_destroy() now,
On Wed, Dec 2, 2020 at 8:58 AM Kuan-Ying Lee wrote:
>
> We hit this issue in our internal test.
> When enabling generic kasan, a kfree()'d object is put into per-cpu
> quarantine first. If the cpu goes offline, object still remains in
> the per-cpu quarantine. If we call kmem_cache_destroy() now,
We hit this issue in our internal test.
When enabling generic kasan, a kfree()'d object is put into per-cpu
quarantine first. If the cpu goes offline, object still remains in
the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
will report "Objects remaining" error.
[ 74.982625]
6 matches
Mail list logo