From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752778AbcGLKv2 (ORCPT ); Tue, 12 Jul 2016 06:51:28 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:35780 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751014AbcGLKv1 (ORCPT ); Tue, 12 Jul 2016 06:51:27 -0400 Date: Tue, 12 Jul 2016 12:51:22 +0200 From: Daniel Vetter To: Gustavo Padovan , Chris Wilson , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, Daniel Vetter , linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com Subject: Re: [RFC 1/5] dma-buf/fence: add .teardown() ops Message-ID: <20160712105122.GD23520@phenom.ffwll.local> Mail-Followup-To: Gustavo Padovan , Chris Wilson , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com References: <1466695790-2833-1-git-send-email-gustavo@padovan.org> <1466695790-2833-2-git-send-email-gustavo@padovan.org> <20160623204814.GC1086@nuc-i3427.alporthouse.com> <20160624131900.GB2503@joana> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160624131900.GB2503@joana> X-Operating-System: Linux phenom 4.6.0-rc5+ User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2016 at 10:19:00AM -0300, Gustavo Padovan wrote: > 2016-06-23 Chris Wilson : > > > On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > 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