Hi Raj, On Wed, Jan 09, 2019 at 06:01:39PM +0000, Mani, Rajmohan wrote: > Hi Jacopo, > > > Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset > > > > Hello Raj, > > > > On Wed, Jan 09, 2019 at 05:00:21PM +0000, Mani, Rajmohan wrote: > > > Hi Laurent, Tomasz, Jacopo, > > > > > > > Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset > > > > > > > > Hello, > > > > > > > > On Tue, Jan 08, 2019 at 03:54:34PM +0900, Tomasz Figa wrote: > > > > > Hi Raj, Yong, Bingbu, Tianshu, > > > > > > > > > > On Fri, Dec 21, 2018 at 12:04 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> > > wrote: > > > > > > > > > > > > On Fri, Dec 21, 2018 at 7:24 AM Laurent Pinchart > > > > > > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > Hellon > > > > > > > > > > > > > > On Sunday, 16 December 2018 09:26:18 EET Laurent Pinchart wrote: > > > > > > > > Hello Yong, > > > > > > > > > > > > > > > > Could you please have a look at the crash reported below ? > > > > > > > > > > > > > > A bit more information to help you debugging this. I've > > > > > > > enabled KASAN in the kernel configuration, and get the > > > > > > > following use-after-free > > > > reports. > > > > > > > > I tested as well using the ipu-process.sh script shared by Laurent, > > > > with the following command line: > > > > ./ipu3-process.sh --out 2560x1920 --vf 1920x1080 > > > > frame-2592x1944.cio2 > > > > > > > > and I got a very similar trace available at: > > > > https://paste.debian.net/hidden/5855e15a/ > > > > > > > > Please note I have been able to process a set of images (with KASAN > > > > enabled the machine does not freeze) but the kernel log gets flooded > > > > and it is not possible to process any other frame after this. > > > > > > > > The issue is currently quite annoying and it's a blocker for > > > > libcamera development on IPU3. Please let me know if I can support with > > more testing. > > > > > > > > Thanks > > > > j > > > > > > > > > > > > > > > > > > [ 166.332920] > > > > > > > > > > > > > ================================================================ > > > > == > > > > > > > [ 166.332937] BUG: KASAN: use-after-free in > > > > > > > __cached_rbnode_delete_update+0x36/0x202 > > > > > > > [ 166.332944] Read of size 8 at addr ffff888133823718 by task > > > > > > > yavta/1305 > > > > > > > > > > > > > > [ 166.332955] CPU: 3 PID: 1305 Comm: yavta Tainted: G C > > 4.20.0- > > > > rc6+ #3 > > > > > > > [ 166.332958] Hardware name: HP Soraka/Soraka, BIOS > > > > > > > 08/30/2018 [ 166.332959] Call Trace: > > > > > > > [ 166.332967] dump_stack+0x5b/0x81 [ 166.332974] > > > > > > > print_address_description+0x65/0x227 > > > > > > > [ 166.332979] ? __cached_rbnode_delete_update+0x36/0x202 > > > > > > > [ 166.332983] kasan_report+0x247/0x285 [ 166.332989] > > > > > > > __cached_rbnode_delete_update+0x36/0x202 > > > > > > > [ 166.332995] private_free_iova+0x57/0x6d [ 166.332999] > > > > > > > __free_iova+0x23/0x31 [ 166.333011] > > > > > > > ipu3_dmamap_free+0x118/0x1d6 [ipu3_imgu] > > > > > > > > > > > > Thanks Laurent, I think this is a very good hint. It looks like > > > > > > we're basically freeing and already freed IOVA and corrupting > > > > > > some allocator state? > > > > > > > > > > Did you have any luck in reproducing and fixing this double free issue? > > > > > > > > > > > This issue is either hard to reproduce or comes with different > > > signatures with the updated yavta (that now supports meta output) with > > > the 4.4 kernel that I have been using. > > > I am switching to 4.20-rc6 for better reproducibility. > > > Enabling KASAN also results in storage space issues on my Chrome device. > > > Will enable this just for ImgU to get ahead and get back with more updates. > > > > > > > Thanks for testing this. > > > > For your informations I'm using the following branch, from Sakari's > > tree: git://linuxtv.org/sailus/media_tree.git ipu3 > > > > Although it appears that the media tree master branch has everything that is > > there, with a few additional patches on top. I should move to use media tree > > master as well... > > > > I have here attached 2 configuration files for v4.20-rc5 I am using on Soraka, in > > case they might help you. One has KASAN enabled with an increased kernel > > log size, the other one is the one we use for daily development. > > I think I am missing a trick here to override the default chrome os kernel > config with the one that you supplied. > > In particular I am looking for steps to build the upstream kernel within chrome os > build environment using your config, so I can update my Soraka device. I'm sorry I can not help much building 'withing chrome os build environment'. Care to explain what you mean? What I usually do, provided you're running a debian-based Linux distro on your Soraka device, is compile the kernel on host with 'make bindeb-pkg' and then upload and install the resulting .deb package on the Soraka chromebook. If that might work for you, we can share more details on how to do so (tomorrow maybe :p ) Thanks j > > > > > Also, please make sure to use (the most) recent media-ctl and yavta utilities, as > > the ones provided by most distros are usually not recent enough to work with > > IPU3, but I'm sure you know that already ;) > > Ack > > > > > Thanks > > j > > > > [snip]
Attachment:
signature.asc
Description: PGP signature
