linux-kernel - Re: [RFC 1/5] dma-buf/fence: add .teardown() ops

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]

Message-ID: <20160712105122.GD23520@phenom.ffwll.local>
Date:	Tue, 12 Jul 2016 12:51:22 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Gustavo Padovan <gustavo@...ovan.org>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	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: [RFC 1/5] dma-buf/fence: add .teardown() ops

On Fri, Jun 24, 2016 at 10:19:00AM -0300, Gustavo Padovan wrote:
> 2016-06-23 Chris Wilson <chris@...is-wilson.co.uk>:
> 
> > On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> > > 
> > > fence_array requires a function to clean up its state before we
> > > are able to call fence_put() and release it.
> > 
> > An explanation along the lines of:
> > 
> > As the array of fence callbacks held by an active struct fence_array
> > each has a reference to the struct fence_array, when the owner of the
> > fence_array is freed it must dispose of the callback references before
> > it can free the fence_array. This can not happen simply during
> > fence_release() because of the extra references and so we need a new
> > function to run before the final fence_put().
> > 
> > would help, it is not until you use it in 5/5 that it becomes apparent
> > why it is needed.
> 
> That is much better explanation. Thanks!

What happens if the owner of the fence_array isn't the last reference
holder any more? What if there's a 2nd sync_file that now stops working
because the callbacks went poof? Some other driver that registered
callbacks?

Generally mixing refcounting with explicit teardown is really tricky,
fragile and tends to not work. This smells fishy.

Why exactly do we have a reference count loop here in the first place that
we need to break up using fence_teardown?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch