Hi Divneil, On Mon, Apr 7, 2014 at 6:56 PM, Divneil Wadhawan <divneil@xxxxxxxxxxx> wrote: > Hi, > > I have a V4L2 capture driver accepting a malloc'ed buffer. > The driver is using vb2_vmalloc_memops (../drivers/media/v4l2-core/videobuf2-vmalloc.c) for user-space to kvaddr translation. > Randomly, corrupted data is received by user-app. > > So, the question is regarding the handling of get_userptr, put_userptr by v4l2-core: > > const struct vb2_mem_ops vb2_vmalloc_memops = { > ........ > .get_userptr = vb2_vmalloc_get_userptr, (get_user_pages() and vm_map_ram()) > .put_userptr = vb2_vmalloc_put_userptr, (set_page_dirty_lock() and put_page()) > ..... > }; > > The driver prepares for the transaction by virtue of v4l2-core calling get_userptr (QBUF) > After data is filled, driver puts on a done list (DQBUF) > > We never mark the pages as dirty (or put_userptr) after a transaction is complete. > Here, in v4l2 core (videobuf2-core.c) , we conditionally put_userptr - when a QBUF with a different userptr on same index, or releasing buffers. > > Is it correct? Probably seems to be the reason for corrupted data. This is an optimization and requires the mapping of userspace buffer to v4l2_buffer index to not change. Is it possible that your userspace is not always queuing the same userptr memory areas with the same v4l2_buffer index values? In other words, if you have 2 buffers in use, under userspace mapping at addr1 and addr2, if you queue addr1 with index=0 and addr2 with index=1 initially, you should always keep queuing addr1 with index=0 and never 1, etc. Also, what architecture are you running this on? > Regards, > Divneil -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html