linux-kernel - Re: [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53DFA210.2020603@canonical.com>
Date:	Mon, 04 Aug 2014 17:09:04 +0200
From:	Maarten Lankhorst <maarten.lankhorst@...onical.com>
To:	Christian König <christian.koenig@....com>,
	airlied@...ux.ie
CC:	thellstrom@...are.com, nouveau@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	bskeggs@...hat.com, alexander.deucher@....com
Subject: Re: [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

op 04-08-14 17:04, Christian König schreef:
> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>> op 04-08-14 16:45, Christian König schreef:
>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>>>> op 04-08-14 16:37, Christian König schreef:
>>>>>> It'a pain to deal with gpu reset.
>>>>> Yeah, well that's nothing new.
>>>>>
>>>>>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup.
>>>>>> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery.
>>>>> The lockup code itself should never call any waiting code and V2 doesn't seem to handle a couple of cases correctly either.
>>>>>
>>>>> How about moving the fence waiting out of the reset code?
>>>> What cases did I miss then?
>>>>
>>>> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc.
>>> The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore.
>> I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclusive lock?
>
> Just set need_reset again and return -EAGAIN, that should have mostly the same effect as what we are doing right now.
Yeah, except for the locking the ttm delayed workqueue, but that bool should be easy to save/restore.
I think this could work.

~Maarten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/