linux-kernel - Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need

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]

Message-ID: <CAKMK7uFJNviGuT=F4=B8X22en2dOtthXzsmeQoDXmO0kx-DD7g@mail.gmail.com>
Date:	Fri, 13 Sep 2013 10:46:32 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Rob Clark <robdclark@...il.com>
Cc:	DRI Development <dri-devel@...ts.freedesktop.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

On Fri, Sep 13, 2013 at 2:59 AM, Rob Clark <robdclark@...il.com> wrote:
> I guess in i915 (and ttm) case, the issue arises due to need for CPU
> access to buffer via GTT?  In which case I should be safe to drop the
> set_need_resched() as well? (Since CPU always has direct access to the
> pages.)  Or am I missing something about the original issue that
> necessitated set_need_resched()?

For drm/i915 the _only_ reason we've had  it was to avoid life-locking
with our gpu reset work when the gpu hung. We've fixed that properly
now by using a wait-queue to stall when a gpu reset is pending and
proper locking in the gpu reset handler (plus tons of evil tests to
make sure it doesn't break, there's rather fragile lock-dropping and
tricky ordering involved). So if you don't have i915's broken gpu
reset handling from yonder you don't need our cargo-cult.

ttm's usage with a trylock+yield is a different form of duct-tape to
paper over locking inversions between copy_*_user callsites and the
pagefault handler.

In any case there's no way it actually works properly ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/