Message ID | 20201211155843.3348718-3-daniel.vetter@ffwll.ch (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1knksQ-00FTJs-LS; Fri, 11 Dec 2020 16:02:39 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406668AbgLKQAw (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 11 Dec 2020 11:00:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406340AbgLKP7i (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 11 Dec 2020 10:59:38 -0500 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AF18C0613D6 for <linux-media@vger.kernel.org>; Fri, 11 Dec 2020 07:58:53 -0800 (PST) Received: by mail-wr1-x443.google.com with SMTP id i9so9537456wrc.4 for <linux-media@vger.kernel.org>; Fri, 11 Dec 2020 07:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=eI9svEscFFEDHjZ/6rb7PQ6fCEwvLqPuRGZ41CR0IOE=; b=Ul4NgJKZ+VuEJ9Ke4828Uu1XNWega/19OpNJ46AF4xjJu73b0OspZ1/CGB+nNarjj+ Fwg3F/1wwm77oFGYETrnmGi4o+RcS07Kil3LNJKXFtMLqiD+n7wvHC3A5qSoWeyADFKu c4ES6nJPLpl8XYU+Rtr27hX3fLhwVaY3YJgs4= 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=eI9svEscFFEDHjZ/6rb7PQ6fCEwvLqPuRGZ41CR0IOE=; b=nYnwCylDNrey7JaS0OmfT0W2ikn2TofqKj7dKYNO1DDBvm2sSQeDLoQNSwBm96MLdm bR0zBmCK7XKx2UemNrBd2dLqf4Me0wDkZTuJb+u5k6MyT2kRtbDwqjLj3WGf+vERnhug bToTJ4wcgv/vCxYRnDkYcF59gCb3fAFSy7/4UwP3wE8eMvco4PSo0z7LsOFyZACuDwup 8bPw/jO8Vv9iXNPbyW2fT0uAla3pxIqpiGEG9dmIBj1oCf7rwBP1dUfbSqxGbgOcxr3p mWDoyc6PiTnP5b3Twbk7KV+kjQnPMd04M0agldE9zKKo+x3nLrRm2rpnlN19COQwChkN EnnA== X-Gm-Message-State: AOAM531Mju8z2wuVC3jj+11QU7ThwjXk3A+kweu8SK55N3YjXo7ykz0R 53iV181Ni6BuKIDaN9Cgqu/E3w== X-Google-Smtp-Source: ABdhPJyFxZCqemzt/g6P2XoqMBFJ21XrRke48okT8FQRyUvc+wuGP5q3+cNwooS9ousLaFZvzrTnDw== X-Received: by 2002:a5d:4a10:: with SMTP id m16mr14958011wrq.18.1607702331851; Fri, 11 Dec 2020 07:58:51 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id z21sm14828241wmk.20.2020.12.11.07.58.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Dec 2020 07:58:51 -0800 (PST) From: Daniel Vetter <daniel.vetter@ffwll.ch> To: DRI Development <dri-devel@lists.freedesktop.org> Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>, Daniel Vetter <daniel.vetter@ffwll.ch>, Daniel Vetter <daniel.vetter@intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: [PATCH 3/4] dma-buf: begin/end_cpu might lock the dma_resv lock Date: Fri, 11 Dec 2020 16:58:42 +0100 Message-Id: <20201211155843.3348718-3-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201211155843.3348718-1-daniel.vetter@ffwll.ch> References: <20201211155843.3348718-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
[1/4] dma-buf: Remove kmap kerneldoc vestiges
|
|
Commit Message
Daniel Vetter
Dec. 11, 2020, 3:58 p.m. UTC
At least amdgpu and i915 do, so lets just document this as the rule.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
Hi Daniel, I love your patch! Yet something to improve: [auto build test ERROR on next-20201211] [also build test ERROR on v5.10-rc7] [cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.10-rc7 v5.10-rc6 v5.10-rc5] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/dma-buf-Remove-kmap-kerneldoc-vestiges/20201212-000040 base: 3cc2bd440f2171f093b3a8480a4b54d8c270ed38 config: powerpc64-randconfig-r035-20201210 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 5ff35356f1af2bb92785b38c657463924d9ec386) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://github.com/0day-ci/linux/commit/24d4fcf0e09c80974556c7639cb630f86a544378 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Daniel-Vetter/dma-buf-Remove-kmap-kerneldoc-vestiges/20201212-000040 git checkout 24d4fcf0e09c80974556c7639cb630f86a544378 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): >> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier 'dma_buf' might_lock(&dma_buf->resv.lock); ^ >> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier 'dma_buf' >> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier 'dma_buf' drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier 'dma_buf' might_lock(&dma_buf->resv.lock); ^ drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier 'dma_buf' drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier 'dma_buf' 6 errors generated. vim +/dma_buf +1121 drivers/dma-buf/dma-buf.c 1093 1094 /** 1095 * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from the 1096 * cpu in the kernel context. Calls begin_cpu_access to allow exporter-specific 1097 * preparations. Coherency is only guaranteed in the specified range for the 1098 * specified access direction. 1099 * @dmabuf: [in] buffer to prepare cpu access for. 1100 * @direction: [in] length of range for cpu access. 1101 * 1102 * After the cpu access is complete the caller should call 1103 * dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is 1104 * it guaranteed to be coherent with other DMA access. 1105 * 1106 * This function will also wait for any DMA transactions tracked through 1107 * implicit synchronization in &dma_buf.resv. For DMA transactions with explicit 1108 * synchronization this function will only ensure cache coherency, callers must 1109 * ensure synchronization with such DMA transactions on their own. 1110 * 1111 * Can return negative error values, returns 0 on success. 1112 */ 1113 int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, 1114 enum dma_data_direction direction) 1115 { 1116 int ret = 0; 1117 1118 if (WARN_ON(!dmabuf)) 1119 return -EINVAL; 1120 > 1121 might_lock(&dma_buf->resv.lock); 1122 1123 if (dmabuf->ops->begin_cpu_access) 1124 ret = dmabuf->ops->begin_cpu_access(dmabuf, direction); 1125 1126 /* Ensure that all fences are waited upon - but we first allow 1127 * the native handler the chance to do so more efficiently if it 1128 * chooses. A double invocation here will be reasonably cheap no-op. 1129 */ 1130 if (ret == 0) 1131 ret = __dma_buf_begin_cpu_access(dmabuf, direction); 1132 1133 return ret; 1134 } 1135 EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); 1136 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Am 11.12.20 um 16:58 schrieb Daniel Vetter: > At least amdgpu and i915 do, so lets just document this as the rule. > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Sumit Semwal <sumit.semwal@linaro.org> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: linux-media@vger.kernel.org > Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> > --- > drivers/dma-buf/dma-buf.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index e1fa6c6f02c4..00d5afe904cc 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1118,6 +1118,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > if (WARN_ON(!dmabuf)) > return -EINVAL; > > + might_lock(&dma_buf->resv.lock); > + > if (dmabuf->ops->begin_cpu_access) > ret = dmabuf->ops->begin_cpu_access(dmabuf, direction); > > @@ -1151,6 +1153,8 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf, > > WARN_ON(!dmabuf); > > + might_lock(&dma_buf->resv.lock); > + > if (dmabuf->ops->end_cpu_access) > ret = dmabuf->ops->end_cpu_access(dmabuf, direction); >
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index e1fa6c6f02c4..00d5afe904cc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1118,6 +1118,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, if (WARN_ON(!dmabuf)) return -EINVAL; + might_lock(&dma_buf->resv.lock); + if (dmabuf->ops->begin_cpu_access) ret = dmabuf->ops->begin_cpu_access(dmabuf, direction); @@ -1151,6 +1153,8 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf, WARN_ON(!dmabuf); + might_lock(&dma_buf->resv.lock); + if (dmabuf->ops->end_cpu_access) ret = dmabuf->ops->end_cpu_access(dmabuf, direction);