From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752672AbcFWV1r (ORCPT ); Thu, 23 Jun 2016 17:27:47 -0400 Received: from mail.fireflyinternet.com ([87.106.93.118]:59487 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752179AbcFWV1o (ORCPT ); Thu, 23 Jun 2016 17:27:44 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Thu, 23 Jun 2016 22:27:24 +0100 From: Chris Wilson To: Gustavo Padovan Cc: 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 5/5] dma-buf/sync_file: rework fence storage in struct file Message-ID: <20160623212724.GD1086@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Gustavo Padovan , 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 References: <1466695790-2833-1-git-send-email-gustavo@padovan.org> <1466695790-2833-6-git-send-email-gustavo@padovan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466695790-2833-6-git-send-email-gustavo@padovan.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2016 at 12:29:50PM -0300, Gustavo Padovan wrote: > -static void sync_file_add_pt(struct sync_file *sync_file, int *i, > +static int sync_file_set_fence(struct sync_file *sync_file, > + struct fence **fences) > +{ > + struct fence_array *array; > + > + if (sync_file->num_fences == 1) { > + sync_file->fence = fences[0]; Straightforward pointer assignment. > + } else { > + array = fence_array_create(sync_file->num_fences, fences, > + fence_context_alloc(1), 1, false); > + if (!array) > + return -ENOMEM; > + > + sync_file->fence = &array->base; New reference. Imbalance will promptly go bang after we release the single fence[0]. Would fence_array_create(1, fence) returning fence_get(fence) be too much of a hack? I would suggest dropping the exported fence_get_fences() and use a local instead that could avoid the copy, e.g. static struct fence *get_fences(struct fence **fence, unsigned int *num_fences) { if (fence_is_array(*fence)) { struct fence_array *array = to_fence_array(*fence); *num_fences = array->num_fences; return array->fences; } else { *num_fences = 1; return fence; } } sync_file_merge() { int num_fences, num_a_fences, num_b_fences; struct fence **fences, **a_fences, **b_fences; a_fences = get_fences(&a, &num_a_fences); b_fences = get_fences(&b, &num_b_fences); num_fences = num_a_fences + num_b_fences; > static void sync_file_free(struct kref *kref) > { > struct sync_file *sync_file = container_of(kref, struct sync_file, > kref); > - int i; > - > - for (i = 0; i < sync_file->num_fences; ++i) { > - fence_remove_callback(sync_file->cbs[i].fence, > - &sync_file->cbs[i].cb); > - fence_put(sync_file->cbs[i].fence); > - } > > + fence_remove_callback(sync_file->fence, &sync_file->cb); > + fence_teardown(sync_file->fence); Hmm. Could we detect the removal of the last callback and propagate that to the fence_array? (Rather then introduce a manual call to fence_teardown.) -- Chris Wilson, Intel Open Source Technology Centre