Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

2017-12-08 Thread Peter Zijlstra
On Fri, Dec 08, 2017 at 05:36:28PM +0100, Daniel Vetter wrote: > Aside: Could/should we take some fake lockdep locks around these > callbacks, since not all drivers call them from a hardirq context? Just to > validate that everyone follows the contract. What I typically do is use

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

2017-12-08 Thread Daniel Vetter
On Fri, Dec 08, 2017 at 11:14:16AM +0100, Peter Zijlstra wrote: > On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote: > > On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote: > > > > Is what it says I suppose. Now I don't know enough about that i915 code > > > to say if that

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

2017-12-08 Thread Peter Zijlstra
On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote: > On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote: > > Is what it says I suppose. Now I don't know enough about that i915 code > > to say if that breadcrumbs_signal thread can ever trigger a fault or > > not. I got

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

2017-12-07 Thread Daniel Vetter
On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote: > On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote: > > > [ 85.069417] gem_exec_captur/2810 is trying to acquire lock: > > [ 85.069419] ((completion)>parked){+.+.}, at: [] > > kthread_park+0x3d/0x50 > > [