On 2018/08/27 16:41, Christian König wrote:
> Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
>> I'm not following. Why don't we need to do like below (given that
>> nobody except amdgpu_mn_read_lock() holds ->read_lock) because e.g.
>> drm_sched_fence_create() from drm_sched_job_init() from amdgpu_cs_submit()
>> is doing GFP_KERNEL memory allocation with ->lock held for write?
>
> That's a bug which needs to be fixed separately.
>
> Allocating memory with GFP_KERNEL while holding a lock which is also taken in the reclaim code path is illegal not matter what you do.
>
> Patches to fix this are already on the appropriate mailing list and will be pushed upstream today.
>
> Regards,
> Christian.
Commit 4a2de54dc1d7668f ("drm/amdgpu: fix holding mn_lock while allocating memory")
seems to be calling amdgpu_mn_unlock() without amdgpu_mn_lock() when
drm_sched_job_init() failed...
Michal, you are asking me to fix all bugs (including out of tree code) and prevent
future bugs just because you want to avoid using timeout in order to avoid OOM lockup
( https://marc.info/?i=55a3fb37-3246-73d7-0f45-5835a3f4831c@xxxxxxxxxxxxxxxxxxx ).
That is a too much request which is impossible for even you. More you count on
the OOM reaper, we exponentially complicates dependency and more likely to stumble
over unreviewed/untested code...
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
