Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp263049pxf; Thu, 8 Apr 2021 02:31:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6T1R00PO5qU/USABNDGfFY4Wq15p1qH62Ym8LR2DzGrQVC4B5hXb8isLCdbqmhQzIelUq X-Received: by 2002:a17:902:edd5:b029:e9:7477:5f0a with SMTP id q21-20020a170902edd5b02900e974775f0amr4909263plk.81.1617874271703; Thu, 08 Apr 2021 02:31:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617874271; cv=none; d=google.com; s=arc-20160816; b=lLPhUe04olDmr7HMK15Os2ZlarkKJ8mOG7wRNqPXQm6Bh6G6ItCMBeU7ORmUHKc4ls HJUUjHoU8AcCsUX46dUb4iVb+sTszQEbGeec37fMJesqva4Naeq+FQzQhRTHVFIIFzEb z1beOXUmjFNT585YRxrGmJ5rwIt4o8ptVGUbXXc95a3nEJWrRs2N8UwwhK+M9Fm5fDgH +KJZxFmLMgbTWImAYPAdh7bb3hVF/W6pHVIA9SbTfhkW4/4g3+5TyU+xT8+bAFWYKLZw gNxj6B6hxZ9QcqZX3Y/FNRW383R/2r2R+dTOXOtkV8X3Gd32N33r/xNfJHTlNtqmBmaa it/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=5XAETM08UhZJwTK0Ph/sGGuD9pkmUaZXwlb/7bKpHG4=; b=pLj9onWcyZFUAwsaad2S9T0qj/eYzVgqwOeSIa4oIYkVbC/WlCpbYV0UY792sy/BXj 9x3Cg+ok4mHcgGv5PXL7oLVzQcr9iycA77M1TGYdmF3lS7pnrFoijkbUUAfU35wMzdh7 AIcrWdfZeQ4Z9wHVqrHOJRjfylx32V/hEuKfSKMaulp4m/K1WW2Km/1OrtxUNm2fRsjp DVru+wDPHwQkSuINLfa5qnGaeYVU1pvEwCXHSrwpgbWbK//RbqJVyJEv1zwdSnmGH7lY q43qwgBlq5rM0L85ZUxD/AkToYuaXCdHTC0AkAaFVaL6DnSJn+Sg6PF4Zq+v/Ast4pv/ dE9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RXSQzyKQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k6si1507385plt.139.2021.04.08.02.30.58; Thu, 08 Apr 2021 02:31:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RXSQzyKQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231145AbhDHJae (ORCPT + 99 others); Thu, 8 Apr 2021 05:30:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229600AbhDHJae (ORCPT ); Thu, 8 Apr 2021 05:30:34 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D66D1C061760 for ; Thu, 8 Apr 2021 02:30:21 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id x14so1465731qki.10 for ; Thu, 08 Apr 2021 02:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5XAETM08UhZJwTK0Ph/sGGuD9pkmUaZXwlb/7bKpHG4=; b=RXSQzyKQL1eJYRKOZk+dBbXVRZto6VVGAwnc/oQX7tUGkscauRyDo6UQjNJ1X1EvJb 3o0K4zVGa1VZhIe6Xf424YK3j6VNXjD13pXV0TxJEB29hdCGeHEw6mMLl4V+xhtK0ocp Io3hQ2BWehASgwBQIhMcIqohLdCGvYg0677LE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5XAETM08UhZJwTK0Ph/sGGuD9pkmUaZXwlb/7bKpHG4=; b=Qvikqv6/pTPGJl2pY4CowNAJ1Q+xx72E2Op45mSYYXhlS0mMBDGD3G9R7VyHLyEqcl K+Viohf9AhpErfPabcBxRPsBafd7viecVcvdqMYlv7eyEJuTNxulF8wJKTumK1g08okA byJ9U2QbBk3xay3QQueFrg+i3p6SC7b2/YG8tJWDfuWrQkY3yBIK8/hAWUFTCv01hDrY sUmlTMJUPvKu89+x+2GSBAaGqBUKdb6dKAcgRWyxNAxE1VjDI2wTi2TIaZAgCObnCo3t BjSVEMtWJ1VIH7hInYKwPF8rcVwvsGg+wtfho/U9SaSRQO+KNX0YmQis94D3iSGW3JVI 3DRg== X-Gm-Message-State: AOAM533MXaoKICNO6Kw+g20yOmw8btW1AiRjQk2bCYQNeJEv6rOlnAVp KJ/OBOeEynudDYI282qm5M3vuaV95LzYCyaVP7Q6RVPzhtUe2Q== X-Received: by 2002:a37:9bd1:: with SMTP id d200mr7585951qke.328.1617874221077; Thu, 08 Apr 2021 02:30:21 -0700 (PDT) MIME-Version: 1.0 References: <20210408045926.3202160-1-stevensd@google.com> <7f22ac22-dbe0-f056-b7db-24fa60f9724e@amd.com> In-Reply-To: <7f22ac22-dbe0-f056-b7db-24fa60f9724e@amd.com> From: David Stevens Date: Thu, 8 Apr 2021 18:30:10 +0900 Message-ID: Subject: Re: [PATCH] Revert "drm/syncobj: use dma_fence_get_stub" To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Sumit Semwal , ML dri-devel , open list , Linux Media Mailing List , "moderated list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 8, 2021 at 4:03 PM Christian K=C3=B6nig wrote: > > Am 08.04.21 um 06:59 schrieb David Stevens: > > From: David Stevens > > > > This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6. > > > > Using the singleton stub fence in drm_syncobj_assign_null_handle means > > that all syncobjs created in an already signaled state or any syncobjs > > signaled by userspace will reference the singleton fence when exported > > to a sync_file. If those sync_files are queried with SYNC_IOC_FILE_INFO= , > > then the timestamp_ns value returned will correspond to whenever the > > singleton stub fence was first initialized. This can break the ability > > of userspace to use timestamps of these fences, as the singleton stub > > fence's timestamp bears no relationship to any meaningful event. > > And why exactly is having the timestamp of the call to > drm_syncobj_assign_null_handle() better? The timestamp returned by SYNC_IOC_FILE_INFO is the "timestamp of status change in nanoseconds". If userspace signals the fence with DRM_IOCTL_SYNCOBJ_SIGNAL, then a timestamp from drm_syncobj_assign_null_handle corresponds to the status change. If userspace sets DRM_SYNCOBJ_CREATE_SIGNALED when creating a fence, then the status change happens immediately upon creation, which again corresponds to when drm_syncobj_assign_null_handle gets called. > Additional if you really need that please don't revert the patch. > Instead provide a function which returns a newly initialized stub fence > in the dma_fence.c code. Ack. -David > Regards, > Christian. > > > > > Signed-off-by: David Stevens > > --- > > drivers/gpu/drm/drm_syncobj.c | 58 ++++++++++++++++++++++++++--------= - > > 1 file changed, 44 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncob= j.c > > index 349146049849..7cc11f1a83f4 100644 > > --- a/drivers/gpu/drm/drm_syncobj.c > > +++ b/drivers/gpu/drm/drm_syncobj.c > > @@ -211,6 +211,21 @@ struct syncobj_wait_entry { > > static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj, > > struct syncobj_wait_entry *wait); > > > > +struct drm_syncobj_stub_fence { > > + struct dma_fence base; > > + spinlock_t lock; > > +}; > > + > > +static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *f= ence) > > +{ > > + return "syncobjstub"; > > +} > > + > > +static const struct dma_fence_ops drm_syncobj_stub_fence_ops =3D { > > + .get_driver_name =3D drm_syncobj_stub_fence_get_name, > > + .get_timeline_name =3D drm_syncobj_stub_fence_get_name, > > +}; > > + > > /** > > * drm_syncobj_find - lookup and reference a sync object. > > * @file_private: drm file private pointer > > @@ -344,18 +359,24 @@ void drm_syncobj_replace_fence(struct drm_syncobj= *syncobj, > > } > > EXPORT_SYMBOL(drm_syncobj_replace_fence); > > > > -/** > > - * drm_syncobj_assign_null_handle - assign a stub fence to the sync ob= ject > > - * @syncobj: sync object to assign the fence on > > - * > > - * Assign a already signaled stub fence to the sync object. > > - */ > > -static void drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj= ) > > +static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj) > > { > > - struct dma_fence *fence =3D dma_fence_get_stub(); > > + struct drm_syncobj_stub_fence *fence; > > > > - drm_syncobj_replace_fence(syncobj, fence); > > - dma_fence_put(fence); > > + fence =3D kzalloc(sizeof(*fence), GFP_KERNEL); > > + if (fence =3D=3D NULL) > > + return -ENOMEM; > > + > > + spin_lock_init(&fence->lock); > > + dma_fence_init(&fence->base, &drm_syncobj_stub_fence_ops, > > + &fence->lock, 0, 0); > > + dma_fence_signal(&fence->base); > > + > > + drm_syncobj_replace_fence(syncobj, &fence->base); > > + > > + dma_fence_put(&fence->base); > > + > > + return 0; > > } > > > > /* 5s default for wait submission */ > > @@ -469,6 +490,7 @@ EXPORT_SYMBOL(drm_syncobj_free); > > int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t fla= gs, > > struct dma_fence *fence) > > { > > + int ret; > > struct drm_syncobj *syncobj; > > > > syncobj =3D kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL); > > @@ -479,8 +501,13 @@ int drm_syncobj_create(struct drm_syncobj **out_sy= ncobj, uint32_t flags, > > INIT_LIST_HEAD(&syncobj->cb_list); > > spin_lock_init(&syncobj->lock); > > > > - if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) > > - drm_syncobj_assign_null_handle(syncobj); > > + if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) { > > + ret =3D drm_syncobj_assign_null_handle(syncobj); > > + if (ret < 0) { > > + drm_syncobj_put(syncobj); > > + return ret; > > + } > > + } > > > > if (fence) > > drm_syncobj_replace_fence(syncobj, fence); > > @@ -1322,8 +1349,11 @@ drm_syncobj_signal_ioctl(struct drm_device *dev,= void *data, > > if (ret < 0) > > return ret; > > > > - for (i =3D 0; i < args->count_handles; i++) > > - drm_syncobj_assign_null_handle(syncobjs[i]); > > + for (i =3D 0; i < args->count_handles; i++) { > > + ret =3D drm_syncobj_assign_null_handle(syncobjs[i]); > > + if (ret < 0) > > + break; > > + } > > > > drm_syncobj_array_free(syncobjs, args->count_handles); > > >