On Tue, May 31, 2022 at 05:57:11PM +0100, Will Deacon wrote:
> On Thu, May 26, 2022 at 04:39:56PM -0400, Qian Cai wrote:
> > Running some SR-IOV workloads could trigger some leak reports from
> > kmemleak.
> >
> > unreferenced object 0xffff080243cef500 (size 128):
> > comm "qemu-system-aar", pid 179935, jiffies 4298359506 (age 1629.732s)
> > hex dump (first 32 bytes):
> > 28 00 00 00 01 00 00 00 00 e0 4c 52 03 08 ff ff (.........LR....
> > e0 af a4 7f 7c d1 ff ff a8 3c b3 08 00 80 ff ff ....|....<......
> > backtrace:
> > kmem_cache_alloc_trace
> > kvm_init_stage2_mmu
>
> Hmm, I can't spot a 128-byte allocation in here so this is pretty cryptic.
> I don't really like the idea of papering over the report; we'd be better off
> trying to reproduce it.
... although the hexdump does look like {u32; u32; ptr; ptr; ptr}, which
would match 'struct kvm_pgtable'. I guess the allocation is aligned to
ARCH_DMA_MINALIGN, which could explain the size?
Have you spotted any pattern for when the leak occurs? How are you
terminating the guest?
Will
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
