linux-kernel - Re: [PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

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:	Sun, 07 Oct 2012 18:31:22 +0200
From:	Maarten Lankhorst <maarten.lankhorst@...onical.com>
To:	jakob@...are.com, thellstrom@...are.com,
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
	sumit.semwal@...aro.org, linux-media@...r.kernel.org
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

Op 28-09-12 14:42, Maarten Lankhorst schreef:
> A 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.
>
> A fence is transient, one-shot deal.  It is allocated and attached
> to one or more dma-buf's.  When the one that attached it is done, with
> the pending operation, it can signal the fence:
>   + fence_signal()
>
> To have a rough approximation whether a fence is fired, call:
>   + fence_is_signaled()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> The one pending on the fence can add an async callback:
>   + fence_add_callback()
>
> The callback can optionally be cancelled with:
>   + fence_remove_callback()
>
> To wait synchronously, optionally with a timeout:
>   + fence_wait()
>   + fence_wait_timeout()
>
...

Implementing this makes the locking feel weird, instead of abusing
fence->event_queue.lock I think it would make sense to remove this part entirely,
and have a simply linked list plus a pointer to a spinlock.

enable_signaling should be called with this spinlock held. This way,
the enable_signaling callback would be easier to implement
and doesn't have to double check for races as much in there.

Also __fence_signal should be exported which would be the
same as fence_signal, but without taking the spinlock as separate
step, so it can be called with the spinlock held.

How do you feel about these proposed changes?

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