Hello Raj, On Saturday, 12 January 2019 04:30:49 EET Mani, Rajmohan wrote: [snip] > I finally managed to reproduce the issue with 4.20-rc6, with KASAN enabled > and with CONFIG_SLUB_DEBUG_ON with SLAB_STORE_USER. Nice ! Thank you for your work. > The following line indicates the crash happens when yavta PID 10289 tries to > free the memory. > > [ 452.437844] BUG: KASAN: use-after-free in ipu3_dmamap_free+0x50/0x9c > [ipu3_imgu] > [ 452.446123] Read of size 8 at addr ffff8881503481a0 by task yavta/10289 > > The above looks to be normal, since it's the same task that allocated this > memory. > [ 452.685731] Allocated by task 10289: > > Before the above happened, yavta/10187 came in and freed this memory per > KASAN. > [ 452.787656] Freed by task 10187: > > Is this (one instance of yavta freeing the memory allocated by another > instance of yavta) expected? Or does it indicate that mmap giving the same > address across these 2 instances of yavta? I need to debug / confirm the > latter case. KASAN prints the task name (and process ID) to help you debugging the problem, but this doesn't mean that yavta is freeing the memory. yavta exercises the V4L2 API exposed by the driver, and internally, down the call stack, ipu3_dmamap_free() is called by the driver. According to the backtraces you posted, this is in response to a VIDIOC_STREAMOFF call from yavta. I would expect VIDIOC_STREAMOFF to free DMA mappings created for the buffers on the corresponding video nodes, and thus allocated by the same task. The fact that memory is allocated in one task and freed in another seems weird to me in this case. My guess is that when using multiple instances of yavta the calls to VIDIOC_STREAMOFF on the different video nodes are asynchronous and happen in a way that the driver does not expect. Regardless of how the API is exercised by applications, in a good or bad way, the IPU3 driver must not crash. It needs to be prepared for all V4L2 ioctls to be called at any time, and an application could call VIDIOC_STREAMOFF on any video node while the IPU3 is busy processing images. > With the help of local application that operates these pipes in a serial > fashion, I do not see this issue. [snip] -- Regards, Laurent Pinchart
