linux-kernel - Re: [PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

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] [day] [month] [year] [list]

Date:   Mon, 10 Apr 2017 12:15:34 +0200
From:   Martin Kepplinger <martink@...teo.de>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        daniel.vetter@...el.com, Dave Airlie <airlied@...il.com>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs
 under load

Am 07.04.2017 01:23 schrieb Andrea Arcangeli:
> I'm also getting kernel hangs every couple of days. For me it's still
> not fixed here in 4.11-rc5. It's hard to reproduce, the best
> reproducer is to build lineageos 14.1 on host while running LTP in a
> guest to stress the guest VM.
> 
> Initially I thought it was related to the fact I upgraded the xf86
> intel driver just a few weeks ago (I deferred any upgrade of the
> userland intel driver since last July because of a regression that
> never got fixed and broke xterm for me). After I found a workaround
> for the userland regression (appended at the end for reference) I
> started getting kernel hangs but they are separate issues as far as I
> can tell.
> 
> It's not well tested so beware... (it survived a couple of builds and
> some VM reclaim but that's it).
> 
> The first patch 1/5 is the potential fix for the i915 kernel hang. The
> rest are incremental improvements.
> 
> And I've no great solution for when the shrinker was invoked with the
> struct_mutex held and and recurse on the lock. I don't think we can
> possibly wait in such case (other than flush work that the second
> patch does) but then practically it shouldn't be a big deal, the big
> RAM eater is unlikely to be i915 when the system is low on memory.
> 

FWIW without having insight here, -rc6 seems to be good.
No disturbing gpu hangs under load so far.