On Tue, Jan 31, 2017 at 12:28:40PM -0800, Linus Torvalds wrote:
On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst maarten.lankhorst@linux.intel.com wrote:
This is marked for rc6 because it seems the issue is triggerable on mainline and resulting in an oops.
So I did apply my obvious "avoid the oops and just warn about it" patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()").
I haven't actually triggered the problem since, so I don't know if there might be some other downstream issue, but the workaround *may* just be acceptable from a 4.10 standpoint.
You need sufficient memory pressure to start using partial views, and then kill the X server while it's using that partial view still (i.e. not too much memory pressure to prevent them from getting evicted). And it's global gttt pressure, so not much do to with what's going on on your machine. So hard to hit, but when you do the book-keeping is rather completely wreaked since we throw away the views while they're still in use.
Some maintainer who knows the code better should make the judgment call.
It's a lot less scary than what I thought: - the cherry picks needed are a lot less than what I feared, a lot of the prep work landed in 4.10 and a bunch of it in patches in linux-next aren't needed for 4.10 due to other reasons. - we have a testcase to repro this instantly. It uses rotation instead of partial views (which depend upon allocation order to hit the bug, rotation is deterministic), but the same code blows up for the same reasons because it's a bug in the view code, not with a specific view.
The only thing that's mildly scary is that we need a drm core patch to make it happen. But that one has been for a while in linux-next too, so should be acceptable. Only thing left to do is let CI beat on this specifically for a bit, so pull request should be ready for -rc7 I hope. -Daniel