Re: [PATCH 5/6] drm/amdgpu: add timeline support in amdgpu CS

Hey Chunming, On 20.09.2018 13:03, Chunming Zhou wrote: @@ -1113,48 +1117,91 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p, } static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p, - struct

Re: [PATCH 5/6] drm/amdgpu: add timeline support in amdgpu CS

static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h index 1ceec56de015..412359b446f1 100644 --- a/include/uapi/drm/amdgpu_drm.h +++ b/include/uapi/drm/amdgpu_drm.h @@ -517,6 +517,8 @@ struct drm_amdgpu_gem_va {

Re: RFC for a render API to support adaptive sync and VRR

On 12.04.2018 01:30, Cyr, Aric wrote: At least with VDPAU, video players are already explicitly specifying the target presentation time, so no changes should be required at that level. Don't know about other video APIs. The X11 Present extension protocol is also prepared for specifying the

Re: RFC for a render API to support adaptive sync and VRR

On 10.04.2018 23:45, Cyr, Aric wrote: For video games we have a similar situation where a frame is rendered for a certain world time and in the ideal case we would actually display the frame at this world time. That seems like it would be a poorly written game that flips like that, unless they

Re: RFC for a render API to support adaptive sync and VRR

On 10.04.2018 19:25, Cyr, Aric wrote: -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, April 10, 2018 13:16 On 2018-04-10 07:13 PM, Cyr, Aric wrote: -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, April 10, 2018

Re: RFC for a render API to support adaptive sync and VRR

On 10.04.2018 18:26, Cyr, Aric wrote: That presentation time doesn’t need to come to kernel as such and actually is fine as-is completely decoupled from adaptive sync.  As long as the video player provides the new target_frame_duration_ns on the flip, then the driver/HW will target the correct

Re: [RFC] Per file OOM badness

On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget

Re: [RFC] Per file OOM badness

On 30.01.2018 11:48, Michel Dänzer wrote: On 2018-01-30 11:42 AM, Daniel Vetter wrote: On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: On 2018-01-30 10:31 AM, Daniel Vetter wrote: I guess a good first order approximation would be if we simply charge any newly allocated buffers

Re: [git pull] drm for v4.15

On 17.11.2017 20:18, Christian König wrote: The obvious alternative which we are working on for a few years now is to improve the input data we get from the hardware people. In other words instead of getting a flat list of registers we want the information about where and how many times a

Re: [git pull] drm for v4.15

On 16.11.2017 21:57, Dave Airlie wrote: On 16 November 2017 at 14:59, Linus Torvalds wrote: On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: There is some code touched on sound/soc, but I think the sound tree should have the same commits

Re: [PATCH libdrm 1/2] headers: Sync amdgpu_drm.h with drm-next

Both patches: Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> On 20.10.2017 16:57, Andres Rodriguez wrote: Generated using make headers_install from: airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ... Signed-off-by: Andres Rodriguez <andre...@gmail.com> -

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

On 17.10.2017 21:53, Ville Syrjälä wrote: On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote: On 17.10.2017 16:09, Ville Syrjälä wrote: On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: On 17/10/17 02:22 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 12:28:17PM

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

On 18.10.2017 10:10, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote: On 17.10.2017 19:16, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer <mic...@daenzer.net> wrote: On 17/10/17 05:04 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

at 12:28:17PM +0200, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: Common sense suggests that there need to be two side to FreeSync / VESA Adaptive Sync support: 1. Query the display capabilities. This means querying minimum / maximum refresh duration, plus possibly a

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

On 17.10.2017 16:09, Ville Syrjälä wrote: On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: On 17/10/17 02:22 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: Common sense suggests

Upstream support for FreeSync / Adaptive Sync

Hi all, I just sent out a patch that enables FreeSync in Mesa for the somewhat hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro) stack's DDX and kernel module. [0] While this patch isn't meant for upstream, that's as good a time as any to raise the issue of how a

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

On 17.10.2017 12:28, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: Hi all, I just sent out a patch that enables FreeSync in Mesa for the somewhat hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro) stack's DDX and kernel module. [0] While this patch

Re: X.org EVoC Ideas

On 18.04.2017 17:48, Rob Clark wrote: On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia wrote: Hi there I am Raghav Jajodia, an Engineering student from India. While going through the X.org foundation, I felt that X.org is a great community for new Open Source

Re: [PATCH 5/6] drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS

On 04.04.2017 13:33, Christian König wrote: Am 03.04.2017 um 18:22 schrieb Nicolai Hähnle: On 31.03.2017 11:47, Christian König wrote: From: Christian König <christian.koe...@amd.com> Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS instead of a placement

Re: [PATCH 3/6] drm/ttm: add TTM_PL_FLAG_CONTIGUOUS v2

-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Patch 4: Acked-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c| 4 +++- include/drm/ttm/ttm_placement.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo

Re: [PATCH 6/6] drm/amdgpu: handle CPU access for split VRAM buffers

On 31.03.2017 11:47, Christian König wrote: From: Christian König This avoids merging them together on page fault. Signed-off-by: Christian König Acked-by: Michel Dänzer ---

Re: [PATCH 5/6] drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS

On 31.03.2017 11:47, Christian König wrote: From: Christian König Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS instead of a placement limit. That allows us to better handle CPU accessible placements. Signed-off-by: Christian König

[PATCH libdrm 3/3] amdgpu: add REPLACE and CLEAR checking for VA op (v2)

From: Junwei Zhang <jerry.zh...@amd.com> v2: fix indent Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> --- amdgpu/amdgpu_bo.c | 4 +++- 1 file changed, 3 i

[PATCH libdrm 2/3] headers: the uint*_t vs. __u* discrepancy in amdgpu_drm is fixed

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This was already done in commit 3dc002df3e5 ("amdgpu: sync amdgpu_drm.h with kernel 4.11-rc2"), now update the README accordingly. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/README | 4 1 fil

[PATCH libdrm 1/3] headers: sync amdgpu_drm.h from airlied/drm-next

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Changes include: PRT and preemption flags, sensor info, and some more changes for Vega10. Generated using make headers_install from airlied/drm-next commit 320d8c3d38739fa8e31a076b86cbdafcf8897d5e. Signed-off-by: Nicolai Hähnle <nic

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 29.03.2017 11:36, Michel Dänzer wrote: On 29/03/17 06:07 PM, Christian König wrote: Am 29.03.2017 um 10:59 schrieb Michel Dänzer: On 28/03/17 08:00 PM, Julien Isorce wrote: On 28 March 2017 at 10:36, Michel Dänzer > wrote: On 28/03/17

Re: [PATCH libdrm] xf86drm: remove memory leaks in drmGetBusid/drmGetReservedContextList

On 27.03.2017 04:09, Seung-Woo Kim wrote: In error path of drmGetBusid() and drmGetReservedContextList(), there are memory leaks for error path. So this removes them. Signed-off-by: Seung-Woo Kim <sw0312@samsung.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --

[PATCH] drm/ttm: fix use-after-free races in vm fault handling

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The vm fault handler relies on the fact that the VMA owns a reference to the BO. However, once mmap_sem is released, other tasks are free to destroy the VMA, which can lead to the BO being freed. Fix two code paths where that can happen, both r

[PATCH v3 3/3] drm/amdgpu: simplify reservation handling during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> By using ttm_bo_init_reserved instead of the manual initialization of the reservation object, the reservation lock will be properly unlocked and destroyed when the TTM BO initialization fails. Actual deadlocks caused by the missing unlock

[PATCH v3 1/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH v3 2/3] drm/ttm: add ttm_bo_init_reserved

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This variant of ttm_bo_init returns the validated buffer object with the reservation lock held when resv == NULL. This is convenient for callers that want to use the BO immediately, e.g. for initializing its contents. Signed-off-by: Nicolai

Re: [PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

On 16.02.2017 02:00, Michel Dänzer wrote: On 16/02/17 04:10 AM, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 14:35, Nicolai Hähnle wrote: On 14.02.2017 13:51, Christian König wrote: Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle: On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow c

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 04:16, zhoucm1 wrote: On 2017年02月14日 18:37, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is

[PATCH v2 2/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH v2 1/3] drm/ttm: split BO structure initialization into a separate function

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is needed to fix a locking bug (destroy locked mutex) in amdgpu. v2: callers of ttm_bo_in

[PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation object when the first part of TTM BO initialization fails. Actual deadlocks caused by the m

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 14.02.2017 13:51, Christian König wrote: Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle: On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immed

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 04:16, zhoucm1 wrote: On 2017年02月14日 18:37, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is needed

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done,

[PATCH] drm/ttm: make TTM_MAX_BO_PRIORITY unsigned

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fix a warning about different types in min() macro in amdgpu: In file included from ./include/linux/list.h:8:0, from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In fu

Re: [PATCH 1/2] drm/ttm: never add BO that failed to validate to the LRU list

On 14.02.2017 11:38, Christian König wrote: Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to globa

[PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is needed to fix a locking bug (destroy locked mutex) in amdgpu. Signed-off-by: Nicolai

[PATCH 2/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH 3/3] drm/amdgpu: fix lock cleanup during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation object when the first part of TTM BO initialization fails. Actual deadlocks caused by the m

[PATCH 1/2] drm/ttm: never add BO that failed to validate to the LRU list

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to global list anyway Task 2: grabs hold of the BO, waits on its reservation lock Task 1: releases its ref

[PATCH 2/2] Revert "drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()"

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This reverts commit 38fc4856ad98f230bc91da0421dec69e4aee40f8, which introduces a use-after-free. The underlying bug should be properly fixed with "drm/ttm: never add BO that failed to validate to the LRU list". Cc: Samuel Pitois

[PATCH 0/2] drm/ttm, amdgpu: fix use-after-free in recent deadlock fix

Hi all, based on my current theory on how a deadlock could happen in the buffer allocation code, these two patches should fix the deadlock without having a use-after-free. I'm still working on a way to clean up the ttm_bo_init sequence overall, but I'm separating these two out for a hopefully

Re: [PATCH libdrm 1/3] amdgpu: add missing unlock on drmPrimeFDToHandle() failure

On 22.01.2017 19:48, Emil Velikov wrote: Cc: amd-...@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- amdgpu/amdgpu_bo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/amdgpu/amdgpu_b

Re: [PATCH libdrm 2/3] amdgpu: don't mess with shared_handle if amdgpu_bo_import() fails

I don't think is correct. The incoming handle is in shared_handle, not in handle. Once the code block around line 310 has executed, shared_handle is the handle produced by drmPrimeFDToHandle, and closing it on error (as the code currently does) should be the correct thing to do. The only

Re: Time to update GSoC/EVoC ideas page

Hi Rob, On 19.01.2017 23:32, Rob Clark wrote: Just a friendly reminder that now would be a good time to update the wiki page for GSoC/EVoC ideas: https://www.x.org/wiki/SummerOfCodeIdeas/ There are currently still some stale ideas there (and probably plenty of missing good ideas). Also,

[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

On 23.12.2016 11:48, Peter Zijlstra wrote: > On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote: >> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h >> index a5960e5..b2eaaab 100644 >> --- a/include/linux/ww_mutex.h >> +++ b/include/linux/ww_mutex.h >> @@ -186,11

[PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

On 22.12.2016 02:58, zhoucm1 wrote: > On 2016年12月22日 02:46, Nicolai Hähnle wrote: >> +static inline bool __sched >> +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b) >> +{ >> +return a->stamp - b->stamp <= LONG_MAX && >> + (a->stamp != b->stamp || a >

[PATCH v3 12/12] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH v3 11/12] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at

[PATCH v3 10/12] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure

[PATCH v3 09/12] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thread #1 - -

[PATCH v3 08/12] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off

[PATCH v3 07/12] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the

[PATCH v3 06/12] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make

[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

From: Nicolai Hähnle Keep the documentation in the header file since there is no good place for it in mutex.c: there are two rather different implementations with different EXPORT_SYMBOLs for each function. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst

[PATCH v3 04/12] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost

[PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. v3: rename to __ww_ctx_stamp_after (Chris Wilson) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org

[PATCH v3 02/12] locking/mutex: Fix a race with handoffs and interruptible waits

From: Nicolai Hähnle There's a possible race where the waiter in front of us leaves the wait list due to a signal, and the current owner subsequently hands the lock off to us even though we never observed ourselves at the front of the list. Set the task state before

[PATCH v3 01/12] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH 1/5] drm/ttm: add evict parameter to ttm_bo_driver::move_notify

On 16.12.2016 03:49, zhoucm1 wrote: > On 2016年12月16日 01:10, Nicolai Hähnle wrote: >> From: Nicolai Hähnle >> >> Ensure that the driver can listen to evictions even when they don't >> take the >> path through ttm_bo_driver::move. >> >> This is crucial for amdgpu, which relies on an

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 21:00, Peter Zijlstra wrote: > On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote: >> mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin >> case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the >> wait_lock. > >

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:20, Peter Zijlstra wrote: > On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: @@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, spin_unlock_mutex(>wait_lock, flags);

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:15, Peter Zijlstra wrote: > On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: >> The concern about picking up a handoff that we didn't request is real, >> though it cannot happen in the first iteration. Perhaps this __mutex_trylock >> can be moved to the end of the

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 01.12.2016 16:59, Chris Wilson wrote: > On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: >> @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state, >> unsigned int subclass, >> debug_mutex_lock_common(lock, ); >> debug_mutex_add_waiter(lock, , task);

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

Hi Peter and Chris, (trying to combine the handoff discussion here) On 06.12.2016 17:55, Peter Zijlstra wrote: > On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: >> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, >> unsigned int subclass, >>

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 06.12.2016 16:36, Peter Zijlstra wrote: > On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: >> +static inline int __sched >> +__ww_mutex_add_waiter(struct mutex_waiter *waiter, >> + struct mutex *lock, >> + struct ww_acquire_ctx *ww_ctx) >> +{ >>

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On 06.12.2016 16:25, Peter Zijlstra wrote: > On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: > >> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, >> unsigned int subclass, >> struct mutex_waiter waiter; >> unsigned long flags; >> bool

[PATCH v2] drm/amd/amdgpu: add check that shadow page tables are GPU-accessible

From: Nicolai Hähnle Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the non-shadow page tables using the new helper function. This fixes a crash with the stack trace: amdgpu_gem_va_update_vm -> amdgpu_vm_update_page_directory -> amdgpu_ttm_bind

[PATCH 5/5] drm/amd/amdgpu: add check that shadow page tables are GPU-accessible

From: Nicolai Hähnle Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the non-shadow page tables using the new helper function. This fixes a crash with the stack trace: amdgpu_gem_va_update_vm -> amdgpu_vm_update_page_directory -> amdgpu_ttm_bind

[PATCH 4/5] drm/amd/amdgpu: add check that shadow page directory is GPU-accessible

From: Nicolai Hähnle Skip amdgpu_gem_va_update_vm when shadow the page directory is swapped out. Clean up the check for non-shadow BOs as well using the new helper function. This fixes a crash with the stack trace: amdgpu_gem_va_update_vm ->

[PATCH 3/5] drm/amd/amdgpu: add amdgpu_bo_gpu_accessible helper function

From: Nicolai Hähnle Signed-off-by: Nicolai Hähnle --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h index

[PATCH 2/5] drm/amd/amdgpu: move eviction counting to amdgpu_bo_move_notify

From: Nicolai Hähnle This catches evictions of shadow page tables from the GART. Since shadow page tables are always stored in system memory, amdgpu_bo_move is never called for them. This fixes a crash during command submission that occurs when only a shadow page table

[PATCH 1/5] drm/ttm: add evict parameter to ttm_bo_driver::move_notify

From: Nicolai Hähnle Ensure that the driver can listen to evictions even when they don't take the path through ttm_bo_driver::move. This is crucial for amdgpu, which relies on an eviction counter to skip re-binding page tables when possible. Signed-off-by: Nicolai

[PATCH 0/5] drm/ttm, amdgpu: fix crashes due to shadow page table evictions

Fix a bunch of related crashes in amdgpu that occur when shadow page tables are kicked out of the GART. One of the issues was that during command submission, we rely on a device-global evictions counter to skip some of the work of page-table validation. The driver was never informed of evictions

[PATCH v2 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-appear if

[PATCH v2 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH v2 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at

[PATCH v2 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure

[PATCH v2 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off

[PATCH v2 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost

[PATCH v2 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- kernel/locking/mutex.c

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thread #1 - -

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-appear if

[PATCH 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at

[PATCH 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure

[PATCH 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off

[PATCH 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the

[PATCH 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make

[PATCH 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost

[PATCH 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- kernel/locking/mutex.c

  1   2   >