Re: [Intel-gfx] drm_mm crash with multi threads

[Mark yao <mark.yao@rock-chips.com>]

On 2016年12月23日 13:57, Rob Clark wrote:
> On Thu, Dec 22, 2016 at 11:07 PM, Mark yao <mark.yao@rock-chips.com> wrote:
>> Hi Chris Wilson
>>
>> We port drm_mm to my internal kernel, with high load test, found following
>> crash:
>>
>> [49451.856244]
>> ==================================================================
>> [49451.856350] BUG: KASAN: wild-memory-access on address dead000000000108
>> [49451.856379] Write of size 8 by task Binder:218_4/683 [49451.856417] CPU:
>> 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62 [49451.856443] Hardware
>> name: Rockchip RK3399 Excavator Board edp (Android) (DT) [49451.856469] Call
>> trace: [49451.856519] [<ffffff900808a9d0>] dump_backtrace+0x0/0x230
>> [49451.856556] [<ffffff900808ac14>] show_stack+0x14/0x1c [49451.856592]
>> [<ffffff90084a4de0>] dump_stack+0xa0/0xc8 [49451.856633]
>> [<ffffff900821b700>] kasan_report+0x110/0x4dc [49451.856670]
>> [<ffffff900821aa84>] __asan_store8+0x24/0x7c [49451.856715]
>> [<ffffff90086158c4>] drm_mm_insert_node_generic+0x2dc/0x464 [49451.856760]
>> [<ffffff90086406a8>] rockchip_gem_iommu_map+0x60/0x158 [49451.856794]
>> [<ffffff9008640bb4>] rockchip_gem_create_object+0x278/0x488 [49451.856827]
>> [<ffffff9008641020>] rockchip_gem_create_with_handle+0x24/0x10c
>> [49451.856862] [<ffffff9008641364>] rockchip_gem_create_ioctl+0x3c/0x50
>> [49451.856896] [<ffffff900860aee4>] drm_ioctl+0x354/0x52c [49451.856939]
>> [<ffffff900823d948>] do_vfs_ioctl+0x670/0x78c [49451.856976]
>> [<ffffff900823dac4>] SyS_ioctl+0x60/0x88 [49451.857009] [<ffffff9008082ef0>]
>> el0_svc_naked+0x24/0x28
>> We only use drm_mm_insert_node_generic to alloc memory, and use
>> drm_mm_remove_node to release memory
>>
>> alloc/release maybe on difference threads.
>>
>> Seem the problem is threads problem, drm_mm seems is not threads safe, we
>> found drm_mm_insert_node_generic and drm_mm_remove_node
>> may access same resource with list ops, such as some mm->hole_stack.
>>
>> After use mutex lock protect drm_mm_remove_node and
>> drm_mm_insert_node_generic, the crash disappear.
>>
>> I'm not familiar with drm mm, Do you know how to fix it?
> I don't think drm_mm is intended to be thread safe, but instead the
> driver should provide whatever locking is needed before calling in to
> drm_mm.  (And presumably you already need some lock to protect driver
> level data structures when creating/destroying gem objects.)
>
> BR,
> -R

Got it,

I also see other's driver, all of them  have a lock to protect memory 
creating/destorying.

Thanks.

>
>> Thanks.
>>
>> On 2016年12月17日 03:25, Chris Wilson wrote:
>>
>> With a lot of polish applied, Joonas has reviewed the series - all but
>> for [04/38] "lib: Add a simple prime number generator"
>> [lib/prime_numbers.c]. Anyone feel like poking around at a bit of number
>> theory?
>>
>> Other than it would appear to be ready for Daniel to sort out the merge
>> between drm-misc/i915... Please do take a look and see if you can spot
>> anything else that needs fixing/improving.
>> -Chris
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>> --
>> Ｍark Yao
>>
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
>


-- 
Ｍark Yao


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel