linux-kernel - Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)

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

Date:	Tue, 07 Aug 2012 20:47:51 +0200
From:	Maarten Lankhorst <maarten.lankhorst@...onical.com>
To:	Sumit Semwal <sumit.semwal@...aro.org>, rob.clark@...aro.org
CC:	linaro-mm-sig@...ts.linaro.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	patches@...aro.org
Subject: Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)

Op 07-08-12 19:53, Maarten Lankhorst schreef:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device.  For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering.  The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.

I implemented this for intel and debugged it with intel <-> nouveau
interaction. Unfortunately the nouveau patches aren't ready at this point,
but the git repo I'm using is available at:

http://cgit.freedesktop.org/~mlankhorst/linux/

It has the patch series and a sample implementation for intel, based on
drm-intel-next tree.

I tried to keep it deadlock and race condition free as much as possible,
but locking gets complicated enough that if I'm unlucky something might
have slipped through regardless.

Especially the locking in i915_gem_reset_requests, is screwed up.
This shows what a real PITA it is to abort callbacks prematurely while
keeping everything stable. As such, aborting requests should only be done
in exceptional circumstances, in this case hardware died and things are
already locked up anyhow..

~Maarten

--
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/