Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp136398ybf; Wed, 26 Feb 2020 10:11:50 -0800 (PST) X-Google-Smtp-Source: APXvYqx6ZBaWiFAbEz1QVmasMZQiy/IxavF/TJZ23WDgQKrYfw0G/HXDGXhx6lUTjl9Fb/lrIJqN X-Received: by 2002:aca:aa0a:: with SMTP id t10mr203280oie.156.1582740710108; Wed, 26 Feb 2020 10:11:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582740710; cv=none; d=google.com; s=arc-20160816; b=gQ3lB94bnSQ6xX9h1H3sUYg0/xlVgZ2pSJfQ56X3FXKgtog9tKuLGa8X7/PkWQ1kjG 2lFSF/VOIgPmF3dok7/rkFPYrzwtA+oN+T1biU+DyuPj0PHGtbXC7cS2YShLsQ6xMox2 zHsQ2r5kH0ue1NwBdEslgAmJLEFdNFh2I7dyY39NrI1vYzE16mF4nkSj4M+vVbC2GeX1 fbhPGk+GUuiXSok3jgf1Q8qxT30AJYEBD33lNKPzo0LM76B6p65sMe2gCbYF1DxkMvCJ RG5hZuWiErx6/sGeGqW+I2ctXYkXVsbcIi51WKPHtMoVrJoUN7RRtuAIUlH6f78aGdZQ UKyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:from :dkim-signature; bh=DPo4JQy+OIw8xQQ5dONz5jNXosQ5NdHl3oIG8inea88=; b=Uf/jwvvLWArg6bWReTqej4LvAfaiZCDbg2GIOGwy4CRFtvNEF5Hm61pNYDstTOGIxt DxqEQKCdBdHQN+AzUZlPUsf6Yzshd+odtes5iHGgOPLJ7sEL+r2NJrbfgYApfsWFU5og pYYSK3MZnCoVHYlGGNfSeF3dPt7bPHLMs0slof7sUJ16hqRuTm1Y9pGkfCQqb2BJsRgd IfVzjAa5urDlJMKr9rQnPVxkl0Avim5Cjuv3DrtD07EEYrSEXuybRIFmd7aMX1rxUbs+ n5etMvIWcjtbpfd+qLHJK+C+WkLmlWdKzli2c9XKXdIehiwKJv/xFejGAIgP4xSensRe np/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@jlekstrand-net.20150623.gappssmtp.com header.s=20150623 header.b=nByzsO4+; 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 t10si143959otd.219.2020.02.26.10.11.36; Wed, 26 Feb 2020 10:11:50 -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; dkim=fail header.i=@jlekstrand-net.20150623.gappssmtp.com header.s=20150623 header.b=nByzsO4+; 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 S1727517AbgBZSKB (ORCPT + 99 others); Wed, 26 Feb 2020 13:10:01 -0500 Received: from mail-pj1-f66.google.com ([209.85.216.66]:35477 "EHLO mail-pj1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727501AbgBZSJ6 (ORCPT ); Wed, 26 Feb 2020 13:09:58 -0500 Received: by mail-pj1-f66.google.com with SMTP id q39so1586699pjc.0 for ; Wed, 26 Feb 2020 10:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DPo4JQy+OIw8xQQ5dONz5jNXosQ5NdHl3oIG8inea88=; b=nByzsO4+AJgDleN3uGx4+dv2LTO0oVKrKq2nhGHcGxXx/g+FELYjW8M7Rdys4d4VcA Rk3I2oukXtveRjXEHZR5vgAZ02ax6/AkZM+ugRQiObAZpwEnTAvPwAodWVXuXEC1kvBe zK0Ev0VYNYU+qKl+OAajA5Lr4NNSRCNwHUUIjqjcPoOZqZ2+LbeApwcFpxNsM/VbhYJk 8a/lbOQ2Aw2c33pEfasFEtlw4+wARUSL7cqJ4DNusuCTKsT0OE8QH6xrprIpHDrmOnd2 I5nPu94hsTY9YuRcKk86FQhIJYIrEOzD9zFSlGn241VdEZ7fH5uAfyYWHzmE+eWJSYs1 hIEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DPo4JQy+OIw8xQQ5dONz5jNXosQ5NdHl3oIG8inea88=; b=o5WVACu0qxpCVhVaDgvm+yyPBUqC2VEFt8I5LtPAVEXiW2Bt59PZF2271kx7ai4d6O 1/0LUGvjqOsYFUFOisKn4+fqP2J62oMIT9zJXYkLE2/qI21iyxvk0zAt1o80k4z4tc2C 3fywjI/G4GOZPmsz/RLJxdYc+rN5Dhp7Z6VBwTi4itwdXw6TvopiZVZGOqibkwI37qtH j3zB4MSqvprMIAq+Rf/B3rPkCbI5tMNRbx3CX3QZ2aGM32ukc00QUhpYinLghZWKBTfi uAqx7cfxWfWAZIAFYJKY8VhrxsjefmqXXf180vC+Q++xljDVszS9g9UPkzch5GGHx3kg XNZw== X-Gm-Message-State: APjAAAWI+cJWz9L8aGEChhfMijoYqtXo2BXgl22eF7zcsgV0bGPc7VXF 6lwCONd1v/pFSjtYmbPZwegxxw== X-Received: by 2002:a17:90a:868b:: with SMTP id p11mr358160pjn.60.1582740596700; Wed, 26 Feb 2020 10:09:56 -0800 (PST) Received: from omlet.com ([2605:6000:1026:c273::ce4]) by smtp.gmail.com with ESMTPSA id h7sm4059498pfq.36.2020.02.26.10.09.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2020 10:09:55 -0800 (PST) From: Jason Ekstrand Cc: airlied@redhat.com, christian.koenig@amd.com, jessehall@google.com, jajones@nvidia.com, daniels@collabora.com, hoegsberg@google.com, daniel.vetter@ffwll.ch, bas@basnieuwenhuizen.nl, Jason Ekstrand , Sumit Semwal , Greg Hackmann , Chenbo Feng , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files (v2) Date: Wed, 26 Feb 2020 12:09:35 -0600 Message-Id: <20200226180937.106875-1-jason@jlekstrand.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200225235856.975366-1-jason@jlekstrand.net> References: <20200225235856.975366-1-jason@jlekstrand.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on. This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times. There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages. The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video. v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence. Signed-off-by: Jason Ekstrand --- drivers/dma-buf/dma-buf.c | 162 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++- 2 files changed, 173 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..162f90e8896b 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -348,6 +349,161 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; } +/* This function takes a ref to add_fence on success. The caller still + * owns its ref and has to dma_fence_put it. + */ +static struct dma_fence *dma_buf_get_unified_fence(struct dma_buf *dmabuf, + struct dma_fence *add_fence) +{ + struct dma_fence **fences = NULL; + struct dma_fence_array *array; + unsigned i, num_fences = 0; + int ret; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + return NULL; /* ret can only be 0 or -ENOMEM */ + + if (num_fences == 0) { + if (add_fence) { + return add_fence; + } else { + return dma_fence_get_stub(); + } + } else if (num_fences == 1 && (!add_fence || add_fence == fences[0])) { + struct dma_fence *fence = fences[0]; + kfree(fences); + return fence; + } + + if (add_fence) { + struct dma_fence **nfences; + size_t sz; + + /* Get a ref to add_fence so that we have a ref to every + * fence we are going to put in the array. + */ + dma_fence_get(add_fence); + + sz = (num_fences + 1) * sizeof(*fences); + nfences = krealloc(fences, sz, GFP_NOWAIT | __GFP_NOWARN); + if (!nfences) + goto err_put_fences; + + nfences[num_fences++] = add_fence; + } + + array = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!array) + goto err_put_fences; + + /* The fence array now owns fences_arr and our references to each + * of the individual fences. We only own a reference to the one + * array fence. + */ + + return &array->base; + +err_put_fences: + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[0]); + dma_fence_put(add_fence); + kfree(fences); + return NULL; +} + +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence, *unified_fence; + int ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + dma_resv_lock(dmabuf->resv, NULL); + unified_fence = dma_buf_get_unified_fence(dmabuf, fence); + if (unified_fence) + dma_resv_add_excl_fence(dmabuf->resv, fence); + else + ret = -ENOMEM; + dma_resv_unlock(dmabuf->resv); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + dma_fence_put(fence); + + return ret; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + fence = dma_buf_get_unified_fence(dmabuf, NULL); + if (!fence) { + ret = -ENOMEM; + goto err_put_fd; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +546,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg); + case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..825b9a913c89 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync { #define DMA_BUF_NAME_LEN 32 +struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_sync) #endif -- 2.24.1