linux-kernel - Re: [PATCH v4 5/5] dma-buf/sync_file: only enable fence signalling on poll()

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:	Thu, 4 Aug 2016 22:32:24 +0100
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Gustavo Padovan <gustavo@...ovan.org>,
	dri-devel@...ts.freedesktop.org, marcheu@...gle.com,
	Daniel Stone <daniels@...labora.com>, seanpaul@...gle.com,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	linux-kernel@...r.kernel.org, laurent.pinchart@...asonboard.com,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>, m.chehab@...sung.com
Subject: Re: [PATCH v4 5/5] dma-buf/sync_file: only enable fence signalling
 on poll()

On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote:
> 2016-08-03 Chris Wilson <chris@...is-wilson.co.uk>:
> 
> > On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> > > 
> > > Signalling doesn't need to be enabled at sync_file creation, it is only
> > > required if userspace waiting the fence to signal through poll().
> > > 
> > > Thus we delay fence_add_callback() until poll is called. It only adds the
> > > callback the first time poll() is called. This avoid re-adding the same
> > > callback multiple times.
> > > 
> > > v2: rebase and update to work with new fence support for sync_file
> > > 
> > > v3: use atomic operation to set enabled and protect fence_add_callback()
> > 
> > There's actually a spare bit in fence->flags you can use for this.
> > 
> > #define POLL_ENABLED FENCE_FLAG_USER_BITS
> 
> Wouldn't it be better to add a new bit to fence_flags_bit?

sync_file is a user of struct fence, so it should claim one of the bits
already reserved for users. Those reserved bits are meant only for the
owner of the fence, if we did indeed need to share that bit with other
consumers of the sync_file->fence_array then adding it to
fence_flags_bits make sense. I don't see any reason at present why it
should be anything other than a private bit to sync_file atm.

Promoting it later (from private to shared) would also not be an issue.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre