On Fri, 2020-11-13 at 08:03 +0100, Dmitry Vyukov wrote:
> On Fri, Nov 13, 2020 at 3:32 AM Kuan-Ying Lee
> wrote:
> >
> > On Thu, 2020-11-12 at 09:39 +0100, Dmitry Vyukov wrote:
> > > On Thu, Nov 12, 2020 at 7:25 AM Kuan-Ying Lee
> > > wrote:
> > > >
> > > > We hit this issue in our internal test.
On Fri, Nov 13, 2020 at 3:32 AM Kuan-Ying Lee
wrote:
>
> On Thu, 2020-11-12 at 09:39 +0100, Dmitry Vyukov wrote:
> > On Thu, Nov 12, 2020 at 7:25 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-c
On Thu, 2020-11-12 at 09:39 +0100, Dmitry Vyukov wrote:
> On Thu, Nov 12, 2020 at 7:25 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 remai
On Thu, Nov 12, 2020 at 7:25 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]
==
5 matches
Mail list logo