On Tue, 2020-11-17 at 08:13 +0100, Dmitry Vyukov wrote:
> On Tue, Nov 17, 2020 at 7:46 AM Kuan-Ying Lee
> wrote:
> >
> > On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> > > On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee
> > > wrote:
> > > >
> > > > We hit this issue in our internal
On Tue, Nov 17, 2020 at 7:46 AM Kuan-Ying Lee
wrote:
>
> On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> > On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee
> > wrote:
> > >
> > > We hit this issue in our internal test.
> > > When enabling generic kasan, a kfree()'d object is put into
On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> On Mon, Nov 16, 2020 at 7:30 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
On Mon, Nov 16, 2020 at 7:30 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()
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