Received: by 10.223.164.202 with SMTP id h10csp3699481wrb; Mon, 20 Nov 2017 03:42:28 -0800 (PST) X-Google-Smtp-Source: AGs4zMbTtLBFJlreOmR9ruM4+yQb1rMFhrY/yXI87izdX8HEOCorHxbCLs7VL/pcgPs9JHC89uHl X-Received: by 10.84.168.162 with SMTP id f31mr13569022plb.249.1511178147968; Mon, 20 Nov 2017 03:42:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511178147; cv=none; d=google.com; s=arc-20160816; b=Oa86nA9ZvX0OFGRL9yMGmMqklcG3YEBAwNrFGOXspw8p98RqcPoJ6Y43zNvpL20Fix RcfG5wfYJ3gD9o/rXJG06HIl6rSSjkdTXdBb0NnROmf84+8Ttq3UIZcmy7380lG6i17E nIoLWuhLyQUfWnZdhxOMJsYdFoGHpUTGzzVanIjuua9rmyxZ9VbeeIx73D9KpBpqxg9q pkH9FEEOdv/9vx4Nz+IC1ULWn5U2aIjIh0yx+2RLnWqI7hQsiNgruFIt6QfS03WQ24nL KxppSntj6ljXkXVL1pQvumV6SeOwCDJqVMpuJzlXbrajdkYLFx9sMYUqcJ7wsAkcQ/r5 scoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=ntQxE714E/9lI67V/m9EaveG+4sbhc4LWkIsCbHhiLM=; b=f91FkRvYqmrSSwM2OkmfczC3nPEbh+QWRiwSlq8v7T/XMCf4c1uwI062ZEJLTvZXPe 18DE9sLeoHlSJrlkP6ixhsHOQecHuf47lXeeETguOn8QfrEZc6jWWUGNPYCQAohv3FOY uHPQmVsf7Ph1CwbMmgJ2xgLTw7cs++kF4QyjZkpj3CfwHYThp611uFab1iMCn4WkoUFQ 9PNpKz9xeTvfuS+vXHPhWCFXOUj/IoRpthLqlhagfRc85UFLrtxHAiswjAEPTZ5VfL4v /GnzvX8SgTZ6FrDqDuw7FqoKitwRD2Nnezp3UTOyuT4MPuwahZ+8KR/ApZUeN1+tMDyH bPkg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t64si2563678pgc.821.2017.11.20.03.42.17; Mon, 20 Nov 2017 03:42:27 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751228AbdKTLlb (ORCPT + 67 others); Mon, 20 Nov 2017 06:41:31 -0500 Received: from foss.arm.com ([217.140.101.70]:56168 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751151AbdKTLl2 (ORCPT ); Mon, 20 Nov 2017 06:41:28 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4985D1435; Mon, 20 Nov 2017 03:41:28 -0800 (PST) Received: from e107564-lin.cambridge.arm.com (e107564-lin.cambridge.arm.com [10.2.130.44]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 57E9D3F246; Mon, 20 Nov 2017 03:41:26 -0800 (PST) Date: Mon, 20 Nov 2017 11:41:17 +0000 From: Brian Starkey To: Mauro Carvalho Chehab Cc: Gustavo Padovan , Alexandre Courbot , linux-media@vger.kernel.org, Hans Verkuil , Shuah Khan , Pawel Osciak , Sakari Ailus , Thierry Escande , linux-kernel@vger.kernel.org, Gustavo Padovan Subject: Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF Message-ID: <20171120114101.GA37281@e107564-lin.cambridge.arm.com> References: <20171115171057.17340-1-gustavo@padovan.org> <20171115171057.17340-8-gustavo@padovan.org> <422c5326-374b-487f-9ef1-594f239438f1@chromium.org> <20171117110025.2a49db49@vento.lan> <20171117130801.GH19033@jade> <20171117111905.5070bacd@vento.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20171117111905.5070bacd@vento.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 17, 2017 at 11:19:05AM -0200, Mauro Carvalho Chehab wrote: >Em Fri, 17 Nov 2017 11:08:01 -0200 >Gustavo Padovan escreveu: > >> 2017-11-17 Mauro Carvalho Chehab : >> >> > Em Fri, 17 Nov 2017 15:49:23 +0900 >> > Alexandre Courbot escreveu: >> > >> > > > @@ -178,6 +179,12 @@ static int vb2_queue_or_prepare_buf(struct >> > > > vb2_queue *q, struct v4l2_buffer *b, >> > > > return -EINVAL; >> > > > } >> > > > >> > > > + if ((b->fence_fd != 0 && b->fence_fd != -1) && >> > > >> > > Why do we need to consider both values invalid? Can 0 ever be a valid fence >> > > fd? >> > >> > Programs that don't use fences will initialize reserved2/fence_fd field >> > at the uAPI call to zero. >> > >> > So, I guess using fd=0 here could be a problem. Anyway, I would, instead, >> > do: >> > >> > if ((b->fence_fd < 1) && >> > ... >> > >> > as other negative values are likely invalid as well. >> >> We are checking when the fence_fd is set but the flag wasn't. Checking >> for < 1 is exactly the opposite. so we keep as is or do it fence_fd > 0. > >Ah, yes. Anyway, I would stick with: > if ((b->fence_fd > 0) && > ... > 0 is a valid fence_fd right? If I close stdin, and create a sync_file, couldn't I get a fence with fd zero? -Brian >> >> Gustavo > > >-- >Thanks, >Mauro From 1584551947772359298@xxx Mon Nov 20 02:54:55 +0000 2017 X-GM-THRID: 1584155088810136583 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread