On Fri, Jan 11, 2013 at 02:32:12PM +0000, Daniel Baluta wrote:

On Fri, Jan 11, 2013 at 4:02 PM, Catalin Marinas [off-list ref]
wrote:

quoted

On Fri, Jan 11, 2013 at 01:51:43PM +0000, Alexandru Copot wrote:

quoted

--- 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