Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Mani, Rajmohan" <rajmohan.mani@intel.com>
Cc: Jacopo Mondi <jacopo@jmondi.org>,
	Tomasz Figa <tfiga@chromium.org>,
	"Zhi, Yong" <yong.zhi@intel.com>,
	"Qiu, Tian Shu" <tian.shu.qiu@intel.com>,
	"Cao, Bingbu" <bingbu.cao@intel.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	"Hu, Jerry W" <jerry.w.hu@intel.com>,
	"Toivonen, Tuukka" <tuukka.toivonen@intel.com>
Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Date: Sat, 12 Jan 2019 17:10:14 +0200	[thread overview]
Message-ID: <2718150.slhGTuRzHq@avalon> (raw)
In-Reply-To: <6F87890CF0F5204F892DEA1EF0D77A599B322D80@fmsmsx122.amr.corp.intel.com>

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