diff mbox series

[3/4] dma-buf: begin/end_cpu might lock the dma_resv lock

Message ID 20201211155843.3348718-3-daniel.vetter@ffwll.ch (mailing list archive)
State New, archived
Headers show
Series [1/4] dma-buf: Remove kmap kerneldoc vestiges | expand

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

kernel test robot Dec. 11, 2020, 10:31 p.m. UTC | #1 
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
Christian König Dec. 14, 2020, 10:33 a.m. UTC | #2 
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 mbox series

Patch

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);