On Fri, Jan 11, 2013 at 02:32:12PM +0000, Daniel Baluta wrote: > On Fri, Jan 11, 2013 at 4:02 PM, Catalin Marinas <catalin.marinas@xxxxxxx> > wrote: > > On Fri, Jan 11, 2013 at 01:51:43PM +0000, Alexandru Copot wrote: > > > --- a/drivers/virtio/virtio_ring.c > > > +++ b/drivers/virtio/virtio_ring.c > > > @@ -23,6 +23,7 @@ > > > #include <linux/slab.h> > > > #include <linux/module.h> > > > #include <linux/hrtimer.h> > > > +#include <linux/kmemleak.h> > > > > > > /* virtio guest is communicating with a virtual "device" that actually runs on > > > * a host processor. Memory barriers are used to control SMP effects. */ > > > @@ -140,6 +141,7 @@ static int vring_add_indirect(struct vring_virtqueue *vq, > > > desc = kmalloc((out + in) * sizeof(struct vring_desc), gfp); > > > if (!desc) > > > return -ENOMEM; > > > + kmemleak_not_leak(desc); > > > > Please add a comment above this call in case people later wonder why > > this annotation is needed. > > So, kememleak cannot handle this kind of pointer aliases? No. Basically it stores the allocated object start/end in an rb-tree and cannot cope with overlapping blocks. If we allow aliases, we could have some overlapping. I think there was a patch in the past to add a separate rb-tree for aliases but I didn't particularly like it because it affected the performance. > Also, I wonder if phys_to_virt(virt_to_phys(x)) == x holds true all the time. It should as long as x is a valid kernel virtual address in the logical (linear) mapping. -- Catalin _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
