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@xxxxxxxxxxxxxxx> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
