Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3379602imm; Tue, 29 May 2018 06:20:26 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK+d6HevqLdWiQJI8uJuF+ttyuKFJNBEvoZaD0WuacsGtIqizEUSgXYjehOOWTnNO9W+AfN X-Received: by 2002:a17:902:d885:: with SMTP id b5-v6mr6838499plz.218.1527600026590; Tue, 29 May 2018 06:20:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527600026; cv=none; d=google.com; s=arc-20160816; b=bxT9HOiabZhG9fI8kaw2tVMZTyhsV1ADpmykAzkQBxiFqCDxAeSfPukqehyah1uzm+ Y6OWPS1anNz4F++u/nHbv0LJHQMVT/XQCAIxGz8LTgTfGmgp5DdAtDluhq8JEAhNjL0W bBTdJra28Nr1k3ZzWAraME4XArVNuvQve86lvpoAOeDYjrh4sNgxDGFQOgg4yXAmWRvt MPjJP5NZSzMTCuqQFUMyFBXGYJZTVHWVUQJPJe6VDO51dk5/goFvJhBr69xx0o1DkxEF rc61EnrGGb8/bCNS1ZexC/g4gyUC/UfTt+9f8Yvn+oPGAJvXQ4ZcCtVL87IS9wiLJHNK 0GyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=C6bbitIk+//rZaXKE4V4omCxb/uF/QwINJeA69045Lc=; b=h8ZKJEIorVZz/rPUzliT9caa16e+0Y7su0BjoKi7R/LBljdRVBRljMfquyECtyrIPy JrTmpF+ZizkUSrFhVwWaWp29fq0b4hPlh4CYP039y9h5Ec8ik4dnGn2Q1u3X3D+vr4W9 1pIYWUaEJqNJKDGEHXHaBzQpfFvw8yCb8Z4kJn81KORAJHUXx427i02y486/aeD6hoyC 50p8AO86n3tdlxfeuMkxER1VUXFgAsySYccJv1bQNonWaz/ovxqVlRnImSdEfZEIhKj5 SWWuEoZERl4COt5fMV5hi7rcW3KfWZsdt7Q27l5ayq8O/ZAmeumJ2o5Zj1HWRXsdw/8+ mOAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2-v6si13273486pgp.147.2018.05.29.06.20.12; Tue, 29 May 2018 06:20:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934828AbeE2NTF (ORCPT + 99 others); Tue, 29 May 2018 09:19:05 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:60954 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934754AbeE2NS4 (ORCPT ); Tue, 29 May 2018 09:18:56 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 997FD263BF6 Message-ID: Subject: Re: [PATCH v10 01/16] videobuf2: Make struct vb2_buffer refcounted From: Ezequiel Garcia To: sathyam panda Cc: linux-media@vger.kernel.org, kernel@collabora.com, Hans Verkuil , Mauro Carvalho Chehab , Shuah Khan , Pawel Osciak , Alexandre Courbot , Sakari Ailus , Brian Starkey , linux-kernel@vger.kernel.org, Gustavo Padovan Date: Tue, 29 May 2018 10:17:25 -0300 In-Reply-To: References: <20180521165946.11778-1-ezequiel@collabora.com> <20180521165946.11778-2-ezequiel@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-05-25 at 12:11 +0530, sathyam panda wrote: > Hello, > > On 5/21/18, Ezequiel Garcia wrote: > > The in-fence implementation involves having a per-buffer fence callback, > > that triggers on the fence signal. The fence callback is called > > asynchronously > > and needs a valid reference to the associated ideobuf2 buffer. > > > > Allow this by making the vb2_buffer refcounted, so it can be passed > > to other contexts. > > > > -Is it really required, because when a queued buffer with an in_fence > is deallocated, firstly queue is cancelled. > -And __vb2_dqbuf is called which calls dma_fence_remove_callback. > -So if fence callback has been called -__vb2_dqbuf will wait to > acquire fence lock. > -So during execution of fence callback, buffers and queue are still valid. > -And if __vb2_dqbuf remove callback first ,then dma_fence_signal will > wait for lock > - so there won't be any fence callback to call for that buffer when > dma_fence_signal resumes. > Hi Sathyam, Thanks for your review! The refcount is definitely required, as the fence callback only schedules a workqueue, which is completely asynchronous with respect to the rest of the ioctls. In particular, the workqueue is not synchronized with vb2_core_queue_release. Also, another subtle detail, dma_fence_remove_callback can fail to remove the callback. Thanks, Eze