- Linaro-mm-sig - lists.linaro.org

[PATCH AUTOSEL 5.4 03/37] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Sasha Levin

From: Xin Xiong <xiongx18(a)fudan.edu.cn> [ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 82823d9a8ba8..fddeea2b17e5 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1542,6 +1542,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.34.1

3 years, 8 months

1
0
0 0

[PATCH AUTOSEL 5.10 04/65] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Sasha Levin

From: Xin Xiong <xiongx18(a)fudan.edu.cn> [ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 12598a4b5c78..867fcee6b0d3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1484,6 +1484,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.34.1

3 years, 8 months

1
0
0 0

[PATCH AUTOSEL 5.15 04/98] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Sasha Levin

From: Xin Xiong <xiongx18(a)fudan.edu.cn> [ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 913f9eaa9cd6..aa823f154199 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1508,6 +1508,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.34.1

3 years, 8 months

1
0
0 0

[PATCH AUTOSEL 5.16 007/109] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Sasha Levin

From: Xin Xiong <xiongx18(a)fudan.edu.cn> [ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 0311d799a010..894869789041 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1510,6 +1510,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.34.1

3 years, 8 months

1
0
0 0

[PATCH AUTOSEL 5.17 011/149] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Sasha Levin

From: Xin Xiong <xiongx18(a)fudan.edu.cn> [ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 06d07502a1f6..a34be65c9eaa 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1509,6 +1509,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.34.1

3 years, 8 months

1
0
0 0

[PATCH v2 00/12] iio: buffer-dma: write() and new DMABUF based API

by Paul Cercueil

Hi Jonathan, This is the V2 of my patchset that introduces a new userspace interface based on DMABUF objects to complement the fileio API, and adds write() support to the existing fileio API. Changes since v1: - the patches that were merged in v1 have been (obviously) dropped from this patchset; - the patch that was setting the write-combine cache setting has been dropped as well, as it was simply not useful. - [01/12]: * Only remove the outgoing queue, and keep the incoming queue, as we want the buffer to start streaming data as soon as it is enabled. * Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the same as IIO_BLOCK_STATE_DONE. - [02/12]: * Fix block->state not being reset in iio_dma_buffer_request_update() for output buffers. * Only update block->bytes_used once and add a comment about why we update it. * Add a comment about why we're setting a different state for output buffers in iio_dma_buffer_request_update() * Remove useless cast to bool (!!) in iio_dma_buffer_io() - [05/12]: Only allow the new IOCTLs on the buffer FD created with IIO_BUFFER_GET_FD_IOCTL(). - [12/12]: * Explicitly state that the new interface is optional and is not implemented by all drivers. * The IOCTLs can now only be called on the buffer FD returned by IIO_BUFFER_GET_FD_IOCTL. * Move the page up a bit in the index since it is core stuff and not driver-specific. The patches not listed here have not been modified since v1. Cheers, -Paul Alexandru Ardelean (1): iio: buffer-dma: split iio_dma_buffer_fileio_free() function Paul Cercueil (11): iio: buffer-dma: Get rid of outgoing queue iio: buffer-dma: Enable buffer write support iio: buffer-dmaengine: Support specifying buffer direction iio: buffer-dmaengine: Enable write support iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Use DMABUFs instead of custom solution iio: buffer-dma: Implement new DMABUF based userspace API iio: buffer-dmaengine: Support new DMABUF based userspace API iio: core: Add support for cyclic buffers iio: buffer-dmaengine: Add support for cyclic buffers Documentation: iio: Document high-speed DMABUF based API Documentation/driver-api/dma-buf.rst | 2 + Documentation/iio/dmabuf_api.rst | 94 +++ Documentation/iio/index.rst | 2 + drivers/iio/adc/adi-axi-adc.c | 3 +- drivers/iio/buffer/industrialio-buffer-dma.c | 610 ++++++++++++++---- .../buffer/industrialio-buffer-dmaengine.c | 42 +- drivers/iio/industrialio-buffer.c | 60 ++ include/linux/iio/buffer-dma.h | 38 +- include/linux/iio/buffer-dmaengine.h | 5 +- include/linux/iio/buffer_impl.h | 8 + include/uapi/linux/iio/buffer.h | 30 + 11 files changed, 749 insertions(+), 145 deletions(-) create mode 100644 Documentation/iio/dmabuf_api.rst -- 2.34.1

3 years, 8 months

7
40
0 0

[syzbot] general protection fault in dma_fence_array_first

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 8515d05bf6bc Add linux-next specific files for 20220328 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1694e21b700000 kernel config: https://syzkaller.appspot.com/x/.config?x=530c68bef4e2b8a8 dashboard link: https://syzkaller.appspot.com/bug?extid=5c943fe38e86d615cac2 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1467313b700000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=121b7cb9700000 The issue was bisected to: commit 519f490db07e1a539490612f376487f61e48e39c Author: Christian König <christian.koenig(a)amd.com> Date: Fri Mar 11 09:32:26 2022 +0000 dma-buf/sync-file: fix warning about fence containers bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1058277d700000 final oops: https://syzkaller.appspot.com/x/report.txt?x=1258277d700000 console output: https://syzkaller.appspot.com/x/log.txt?x=1458277d700000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+5c943fe38e86d615cac2(a)syzkaller.appspotmail.com Fixes: 519f490db07e ("dma-buf/sync-file: fix warning about fence containers") general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3595 Comm: syz-executor814 Not tainted 5.17.0-next-20220328-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dma_fence_array_first+0x78/0xb0 drivers/dma-buf/dma-fence-array.c:234 Code: 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 43 48 8b 9b 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 75 1b 4c 8b 23 e8 fa a9 e0 fc 4c 89 e0 5b 41 5c c3 45 RSP: 0018:ffffc90003a4fd48 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000010 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffffff84980052 RDI: ffff888015c76388 RBP: ffff888015c76300 R08: 0000000000000000 R09: ffff888015c7633b R10: ffffffff8498f6ba R11: 0000000000000000 R12: ffff888015c76300 R13: ffff888015c76690 R14: 00000000c0383e04 R15: 0000000020001840 FS: 0000555556872300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020001528 CR3: 000000001e82f000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __dma_fence_unwrap_array include/linux/dma-fence-unwrap.h:42 [inline] dma_fence_unwrap_first include/linux/dma-fence-unwrap.h:57 [inline] sync_file_ioctl_fence_info drivers/dma-buf/sync_file.c:414 [inline] sync_file_ioctl+0x248/0x22c0 drivers/dma-buf/sync_file.c:477 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f6aae8951b9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffedd290238 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6aae8951b9 RDX: 0000000020001840 RSI: 00000000c0383e04 RDI: 0000000000000007 RBP: 00007f6aae8591a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6aae859230 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:dma_fence_array_first+0x78/0xb0 drivers/dma-buf/dma-fence-array.c:234 Code: 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 43 48 8b 9b 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 75 1b 4c 8b 23 e8 fa a9 e0 fc 4c 89 e0 5b 41 5c c3 45 RSP: 0018:ffffc90003a4fd48 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000010 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffffff84980052 RDI: ffff888015c76388 RBP: ffff888015c76300 R08: 0000000000000000 R09: ffff888015c7633b R10: ffffffff8498f6ba R11: 0000000000000000 R12: ffff888015c76300 R13: ffff888015c76690 R14: 00000000c0383e04 R15: 0000000020001840 FS: 0000555556872300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020001528 CR3: 000000001e82f000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess), 4 bytes skipped: 0: df 48 89 fisttps -0x77(%rax) 3: fa cli 4: 48 c1 ea 03 shr $0x3,%rdx 8: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) c: 75 43 jne 0x51 e: 48 8b 9b 88 00 00 00 mov 0x88(%rbx),%rbx 15: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 1c: fc ff df 1f: 48 89 da mov %rbx,%rdx 22: 48 c1 ea 03 shr $0x3,%rdx * 26: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2a: 75 1b jne 0x47 2c: 4c 8b 23 mov (%rbx),%r12 2f: e8 fa a9 e0 fc callq 0xfce0aa2e 34: 4c 89 e0 mov %r12,%rax 37: 5b pop %rbx 38: 41 5c pop %r12 3a: c3 retq 3b: 45 rex.RB --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

3 years, 8 months

2
2
0 0

Re: [PATCH 1/2] dma-buf/sync-file: fix logic error in new fence merge code

by nirmoy.das＠linux.intel.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years, 8 months

1
0
0 0

[PATCH next,v2] kernel: Add 1 ms delay to init handler to fix s3 resume hang

by Zhenneng Li

This is a workaround for s3 resume hang for r7 340(amdgpu). When we test s3 with r7 340 on arm64 platform, graphics card will hang up, the error message are as follows: Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.599374][ 7] [ T291] amdgpu 0000:02:00.0: fb0: amdgpudrmfb frame buffer device Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.612869][ 7] [ T291] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR* late_init of IP block <si_dpm> failed -22 Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.623392][ 7] [ T291] amdgpu 0000:02:00.0: amdgpu_device_ip_late_init failed Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.630696][ 7] [ T291] amdgpu 0000:02:00.0: Fatal error during GPU init Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.637477][ 7] [ T291] [drm] amdgpu: finishing device. On the following hardware: lspci -nn -s 05:00.0 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] [1002:6611] (rev 87) Signed-off-by: Zhenneng Li <lizhenneng(a)kylinos.cn> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 3987ecb24ef4..1eced991b5b2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -2903,6 +2903,8 @@ static void amdgpu_device_delayed_init_work_handler(struct work_struct *work) container_of(work, struct amdgpu_device, delayed_init_work.work); int r; + mdelay(1); + r = amdgpu_ib_ring_tests(adev); if (r) DRM_ERROR("ib ring test failed (%d).\n", r); -- 2.25.1

3 years, 8 months

3
2
0 0

[PATCH 1/2] dma-buf/sync-file: fix logic error in new fence merge code

by Christian König

When the array is empty because everything is signaled we can't use add_fence() to add something because that would filter the signaled fence again. Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixes: 519f490db07e ("dma-buf/sync-file: fix warning about fence containers") --- drivers/dma-buf/sync_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index b8dea4ec123b..514d213261df 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -262,7 +262,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, } if (index == 0) - add_fence(fences, &index, dma_fence_get_stub()); + fences[index++] = dma_fence_get_stub(); if (num_fences > index) { struct dma_fence **tmp; -- 2.25.1

3 years, 8 months

4
6
0 0

[PATCH] drm/amdgpu: resolve s3 hang for r7340

by Zhenneng Li

This is a workaround for s3 hang for r7340(amdgpu). When we test s3 with r7340 on arm64 platform, graphics card will hang up, the error message are as follows: Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.599374][ 7] [ T291] amdgpu 0000:02:00.0: fb0: amdgpudrmfb frame buffer device Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.612869][ 7] [ T291] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR* late_init of IP block <si_dpm> failed -22 Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.623392][ 7] [ T291] amdgpu 0000:02:00.0: amdgpu_device_ip_late_init failed Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.630696][ 7] [ T291] amdgpu 0000:02:00.0: Fatal error during GPU init Mar 4 01:14:11 greatwall-GW-XXXXXX-XXX kernel: [ 1.637477][ 7] [ T291] [drm] amdgpu: finishing device. Change-Id: I5048b3894c0ca9faf2f4847ddab61f9eb17b4823 Signed-off-by: Zhenneng Li <lizhenneng(a)kylinos.cn> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 3987ecb24ef4..1eced991b5b2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -2903,6 +2903,8 @@ static void amdgpu_device_delayed_init_work_handler(struct work_struct *work) container_of(work, struct amdgpu_device, delayed_init_work.work); int r; + mdelay(1); + r = amdgpu_ib_ring_tests(adev); if (r) DRM_ERROR("ib ring test failed (%d).\n", r); -- 2.25.1

3 years, 8 months

3
4
0 0

[PATCH 1/2] dma-buf: add dma_fence_unwrap

by Christian König

Add a general purpose helper to deep dive into dma_fence_chain/dma_fence_array structures and iterate over all the fences in them. This is useful when we need to flatten out all fences in those structures. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/selftests.h | 1 + drivers/dma-buf/st-dma-fence-unwrap.c | 279 ++++++++++++++++++++++++++ include/linux/dma-fence-unwrap.h | 99 +++++++++ 5 files changed, 386 insertions(+) create mode 100644 drivers/dma-buf/st-dma-fence-unwrap.c create mode 100644 include/linux/dma-fence-unwrap.h diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 2cd7db82d9fe..7209500f08c8 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -194,6 +194,12 @@ DMA Fence Chain .. kernel-doc:: include/linux/dma-fence-chain.h :internal: +DMA Fence unwrap +~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/linux/dma-fence-unwrap.h + :internal: + DMA Fence uABI/Sync File ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 511805dbeb75..4c9eb53ba3f8 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -12,6 +12,7 @@ dmabuf_selftests-y := \ selftest.o \ st-dma-fence.o \ st-dma-fence-chain.o \ + st-dma-fence-unwrap.o \ st-dma-resv.o obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h index 97d73aaa31da..851965867d9c 100644 --- a/drivers/dma-buf/selftests.h +++ b/drivers/dma-buf/selftests.h @@ -12,4 +12,5 @@ selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */ selftest(dma_fence, dma_fence) selftest(dma_fence_chain, dma_fence_chain) +selftest(dma_fence_unwrap, dma_fence_unwrap) selftest(dma_resv, dma_resv) diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c new file mode 100644 index 000000000000..d821faaebe93 --- /dev/null +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -0,0 +1,279 @@ +// SPDX-License-Identifier: MIT + +/* + * Copyright (C) 2022 Advanced Micro Devices, Inc. + */ + +#include <linux/dma-fence-unwrap.h> +#if 0 +#include <linux/kernel.h> +#include <linux/kthread.h> +#include <linux/mm.h> +#include <linux/sched/signal.h> +#include <linux/slab.h> +#include <linux/spinlock.h> +#include <linux/random.h> +#endif + +#include "selftest.h" + +#define CHAIN_SZ (4 << 10) + +static struct kmem_cache *slab_fences; + +static inline struct mock_fence { + struct dma_fence base; + spinlock_t lock; +} *to_mock_fence(struct dma_fence *f) { + return container_of(f, struct mock_fence, base); +} + +static const char *mock_name(struct dma_fence *f) +{ + return "mock"; +} + +static void mock_fence_release(struct dma_fence *f) +{ + kmem_cache_free(slab_fences, to_mock_fence(f)); +} + +static const struct dma_fence_ops mock_ops = { + .get_driver_name = mock_name, + .get_timeline_name = mock_name, + .release = mock_fence_release, +}; + +static struct dma_fence *mock_fence(void) +{ + struct mock_fence *f; + + f = kmem_cache_alloc(slab_fences, GFP_KERNEL); + if (!f) + return NULL; + + spin_lock_init(&f->lock); + dma_fence_init(&f->base, &mock_ops, &f->lock, 0, 0); + + return &f->base; +} + +static struct dma_fence *mock_array(unsigned int num_fences, ...) +{ + struct dma_fence_array *array; + struct dma_fence **fences; + va_list valist; + int i; + + fences = kcalloc(num_fences, sizeof(*fences), GFP_KERNEL); + if (!fences) + return NULL; + + va_start(valist, num_fences); + for (i = 0; i < num_fences; ++i) + fences[i] = va_arg(valist, typeof(*fences)); + va_end(valist); + + array = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!array) + goto cleanup; + return &array->base; + +cleanup: + for (i = 0; i < num_fences; ++i) + dma_fence_put(fences[i]); + kfree(fences); + return NULL; +} + +static struct dma_fence *mock_chain(struct dma_fence *prev, + struct dma_fence *fence) +{ + struct dma_fence_chain *f; + + f = dma_fence_chain_alloc(); + if (!f) { + dma_fence_put(prev); + dma_fence_put(fence); + return NULL; + } + + dma_fence_chain_init(f, prev, fence, 1); + return &f->base; +} + +static int sanitycheck(void *arg) +{ + struct dma_fence *f, *chain, *array; + int err = 0; + + f = mock_fence(); + if (!f) + return -ENOMEM; + + array = mock_array(1, f); + if (!array) + return -ENOMEM; + + chain = mock_chain(NULL, array); + if (!chain) + return -ENOMEM; + + dma_fence_signal(f); + dma_fence_put(chain); + return err; +} + +static int unwrap_array(void *arg) +{ + struct dma_fence *fence, *f1, *f2, *array; + struct dma_fence_unwrap iter; + int err = 0; + + f1 = mock_fence(); + if (!f1) + return -ENOMEM; + + f2 = mock_fence(); + if (!f2) { + dma_fence_put(f1); + return -ENOMEM; + } + + array = mock_array(2, f1, f2); + if (!array) + return -ENOMEM; + + dma_fence_unwrap_for_each(fence, &iter, array) { + if (fence == f1) { + f1 = NULL; + } else if (fence == f2) { + f2 = NULL; + } else { + pr_err("Unexpected fence!\n"); + err = -EINVAL; + } + } + + if (f1 || f2) { + pr_err("Not all fences seen!\n"); + err = -EINVAL; + } + + dma_fence_signal(f1); + dma_fence_signal(f2); + dma_fence_put(array); + return 0; +} + +static int unwrap_chain(void *arg) +{ + struct dma_fence *fence, *f1, *f2, *chain; + struct dma_fence_unwrap iter; + int err = 0; + + f1 = mock_fence(); + if (!f1) + return -ENOMEM; + + f2 = mock_fence(); + if (!f2) { + dma_fence_put(f1); + return -ENOMEM; + } + + chain = mock_chain(f1, f2); + if (!chain) + return -ENOMEM; + + dma_fence_unwrap_for_each(fence, &iter, chain) { + if (fence == f1) { + f1 = NULL; + } else if (fence == f2) { + f2 = NULL; + } else { + pr_err("Unexpected fence!\n"); + err = -EINVAL; + } + } + + if (f1 || f2) { + pr_err("Not all fences seen!\n"); + err = -EINVAL; + } + + dma_fence_signal(f1); + dma_fence_signal(f2); + dma_fence_put(chain); + return 0; +} + +static int unwrap_chain_array(void *arg) +{ + struct dma_fence *fence, *f1, *f2, *array, *chain; + struct dma_fence_unwrap iter; + int err = 0; + + f1 = mock_fence(); + if (!f1) + return -ENOMEM; + + f2 = mock_fence(); + if (!f2) { + dma_fence_put(f1); + return -ENOMEM; + } + + array = mock_array(2, f1, f2); + if (!array) + return -ENOMEM; + + chain = mock_chain(NULL, array); + if (!chain) + return -ENOMEM; + + dma_fence_unwrap_for_each(fence, &iter, chain) { + if (fence == f1) { + f1 = NULL; + } else if (fence == f2) { + f2 = NULL; + } else { + pr_err("Unexpected fence!\n"); + err = -EINVAL; + } + } + + if (f1 || f2) { + pr_err("Not all fences seen!\n"); + err = -EINVAL; + } + + dma_fence_signal(f1); + dma_fence_signal(f2); + dma_fence_put(chain); + return 0; +} + +int dma_fence_unwrap(void) +{ + static const struct subtest tests[] = { + SUBTEST(sanitycheck), + SUBTEST(unwrap_array), + SUBTEST(unwrap_chain), + SUBTEST(unwrap_chain_array), + }; + int ret; + + slab_fences = KMEM_CACHE(mock_fence, + SLAB_TYPESAFE_BY_RCU | + SLAB_HWCACHE_ALIGN); + if (!slab_fences) + return -ENOMEM; + + ret = subtests(tests, NULL); + + kmem_cache_destroy(slab_fences); + return ret; +} diff --git a/include/linux/dma-fence-unwrap.h b/include/linux/dma-fence-unwrap.h new file mode 100644 index 000000000000..54963df00c98 --- /dev/null +++ b/include/linux/dma-fence-unwrap.h @@ -0,0 +1,99 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * fence-chain: chain fences together in a timeline + * + * Copyright (C) 2022 Advanced Micro Devices, Inc. + * Authors: + * Christian König <christian.koenig(a)amd.com> + */ + +#ifndef __LINUX_DMA_FENCE_UNWRAP_H +#define __LINUX_DMA_FENCE_UNWRAP_H + +#include <linux/dma-fence-chain.h> +#include <linux/dma-fence-array.h> + +/** + * struct dma_fence_unwrap - cursor into the container structure + */ +struct dma_fence_unwrap { + /** + * @chain: potential dma_fence_chain, but can be other fence as well + */ + struct dma_fence *chain; + /** + * @array: potential dma_fence_array, but can be other fence as well + */ + struct dma_fence *array; + /** + * @index: last returned index if @array is really a dma_fence_array + */ + unsigned int index; +}; + +/** + * dma_fence_unwrap_array - helper to unwrap dma_fence_arrays + * @cursor: cursor to initialize + * + * Helper function to unwrap dma_fence_array containers, don't touch directly. + * Use dma_fence_unwrap_first/next instead. + */ +static inline struct dma_fence * +dma_fence_unwrap_array(struct dma_fence_unwrap * cursor) +{ + cursor->array = dma_fence_chain_contained(cursor->chain); + cursor->index = 0; + return dma_fence_array_first(cursor->array); +} + +/** + * dma_fence_unwrap_first - return the first fence from fence containers + * @head: the entrypoint into the containers + * @cursor: current position inside the containers + * + * Unwraps potential dma_fence_chain/dma_fence_array containers and return the + * first fence. + */ +static inline struct dma_fence * +dma_fence_unwrap_first(struct dma_fence *head, struct dma_fence_unwrap *cursor) +{ + cursor->chain = dma_fence_get(head); + return dma_fence_unwrap_array(cursor); +} + +/** + * dma_fence_unwrap_next - return the next fence from a fence containers + * @cursor: current position inside the containers + * + * Continue unwrapping the dma_fence_chain/dma_fence_array containers and return + * the next fence from them. + */ +static inline struct dma_fence * +dma_fence_unwrap_next(struct dma_fence_unwrap *cursor) +{ + struct dma_fence *tmp; + + ++cursor->index; + tmp = dma_fence_array_next(cursor->array, cursor->index); + if (tmp) + return tmp; + + cursor->chain = dma_fence_chain_walk(cursor->chain); + return dma_fence_unwrap_array(cursor); +} + +/** + * dma_fence_unwrap_for_each - iterate over all fences in containers + * @fence: current fence + * @cursor: current position inside the containers + * @head: starting point for the iterator + * + * Unwrap dma_fence_chain and dma_fence_array containers and deep dive into all + * potential fences in them. If @head is just a normal fence only that one is + * returned. + */ +#define dma_fence_unwrap_for_each(fence, cursor, head) \ + for (fence = dma_fence_unwrap_first(head, cursor); fence; \ + fence = dma_fence_unwrap_next(cursor)) + +#endif -- 2.25.1

3 years, 8 months

5
24
0 0

[PATCH] dma-buf: WIP dma_fence_array_first fix

by Christian König

Looks like somebody is creating an empty dma_fence_array. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-array.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 52b85d292383..5c8a7084577b 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -159,6 +159,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, struct dma_fence_array *array; size_t size = sizeof(*array); + WARN_ON(!num_fences || !fences); + /* Allocate the callback structures behind the array. */ size += num_fences * sizeof(struct dma_fence_array_cb); array = kzalloc(size, GFP_KERNEL); @@ -231,6 +233,9 @@ struct dma_fence *dma_fence_array_first(struct dma_fence *head) if (!array) return head; + if (!array->num_fences) + return NULL; + return array->fences[0]; } EXPORT_SYMBOL(dma_fence_array_first); -- 2.25.1

3 years, 8 months

1
0
0 0

Re: [RFC v3 5/8] dmabuf: Add gpu cgroup charge transfer function

by Michal Koutný

On Mon, Mar 21, 2022 at 04:54:26PM -0700, "T.J. Mercier" <tjmercier(a)google.com> wrote: > Since the charge is duplicated in two cgroups for a short period > before it is uncharged from the source cgroup I guess the situation > you're thinking about is a global (or common ancestor) limit? The common ancestor was on my mind (after the self-shortcut). > I can see how that would be a problem for transfers done this way and > an alternative would be to swap the order of the charge operations: > first uncharge, then try_charge. To be certain the uncharge is > reversible if the try_charge fails, I think I'd need either a mutex > used at all gpucg_*charge call sites or access to the gpucg_mutex, Yes, that'd provide safe conditions for such operations, although I'm not sure these special types of memory can afford global lock on their fast paths. > which implies adding transfer support to gpu.c as part of the gpucg_* > API itself and calling it here. Am I following correctly here? My idea was to provide a special API (apart from gpucp_{try_charge,uncharge}) to facilitate transfers... > This series doesn't actually add limit support just accounting, but > I'd like to get it right here. ...which could be implemented (or changed) depending on how the charging is realized internally. Michal

3 years, 8 months

2
2
0 0

[PATCH 04/23] RDMA: use dma_resv_wait() instead of extracting the fence

by Christian König

Use dma_resv_wait() instead of extracting the exclusive fence and waiting on it manually. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Leon Romanovsky <leon(a)kernel.org> Cc: Maor Gottlieb <maorg(a)nvidia.com> Cc: Gal Pressman <galpress(a)amazon.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/infiniband/core/umem_dmabuf.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c index f0760741f281..d32cd7538835 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -16,7 +16,6 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) { struct sg_table *sgt; struct scatterlist *sg; - struct dma_fence *fence; unsigned long start, end, cur = 0; unsigned int nmap = 0; int i; @@ -68,11 +67,8 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) * may be not up-to-date. Wait for the exporter to finish * the migration. */ - fence = dma_resv_excl_fence(umem_dmabuf->attach->dmabuf->resv); - if (fence) - return dma_fence_wait(fence, false); - - return 0; + return dma_resv_wait_timeout(umem_dmabuf->attach->dmabuf->resv, false, + false, MAX_SCHEDULE_TIMEOUT); } EXPORT_SYMBOL(ib_umem_dmabuf_map_pages); -- 2.25.1

3 years, 9 months

3
3
0 0

[RFC v3 0/8] Proposal for a GPU cgroup controller

by T.J. Mercier

This patch series revisits the proposal for a GPU cgroup controller to track and limit memory allocations by various device/allocator subsystems. The patch series also contains a simple prototype to illustrate how Android intends to implement DMA-BUF allocator attribution using the GPU cgroup controller. The prototype does not include resource limit enforcements. Changelog: v3: Remove Upstreaming Plan from gpu-cgroup.rst per John Stultz Use more common dual author commit message format per John Stultz Remove android from binder changes title per Todd Kjos Add a kselftest for this new behavior per Greg Kroah-Hartman Include details on behavior for all combinations of kernel/userspace versions in changelog (thanks Suren Baghdasaryan) per Greg Kroah-Hartman. Fix pid and uid types in binder UAPI header v2: See the previous revision of this change submitted by Hridya Valsaraju at: https://lore.kernel.org/all/20220115010622.3185921-1-hridya@google.com/ Move dma-buf cgroup charge transfer from a dma_buf_op defined by every heap to a single dma-buf function for all heaps per Daniel Vetter and Christian König. Pointers to struct gpucg and struct gpucg_device tracking the current associations were added to the dma_buf struct to achieve this. Fix incorrect Kconfig help section indentation per Randy Dunlap. History of the GPU cgroup controller ==================================== The GPU/DRM cgroup controller came into being when a consensus[1] was reached that the resources it tracked were unsuitable to be integrated into memcg. Originally, the proposed controller was specific to the DRM subsystem and was intended to track GEM buffers and GPU-specific resources[2]. In order to help establish a unified memory accounting model for all GPU and all related subsystems, Daniel Vetter put forth a suggestion to move it out of the DRM subsystem so that it can be used by other DMA-BUF exporters as well[3]. This RFC proposes an interface that does the same. [1]: https://patchwork.kernel.org/project/dri-devel/cover/20190501140438.9506-1-… [2]: https://lore.kernel.org/amd-gfx/20210126214626.16260-1-brian.welty@intel.co… [3]: https://lore.kernel.org/amd-gfx/YCVOl8%2F87bqRSQei@phenom.ffwll.local/ Hridya Valsaraju (5): gpu: rfc: Proposal for a GPU cgroup controller cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory dmabuf: heaps: export system_heap buffers with GPU cgroup charging dmabuf: Add gpu cgroup charge transfer function binder: Add a buffer flag to relinquish ownership of fds T.J. Mercier (3): dmabuf: Use the GPU cgroup charge/uncharge APIs binder: use __kernel_pid_t and __kernel_uid_t for userspace selftests: Add binder cgroup gpu memory transfer test Documentation/gpu/rfc/gpu-cgroup.rst | 183 +++++++ Documentation/gpu/rfc/index.rst | 4 + drivers/android/binder.c | 26 + drivers/dma-buf/dma-buf.c | 100 ++++ drivers/dma-buf/dma-heap.c | 27 + drivers/dma-buf/heaps/system_heap.c | 3 + include/linux/cgroup_gpu.h | 127 +++++ include/linux/cgroup_subsys.h | 4 + include/linux/dma-buf.h | 22 +- include/linux/dma-heap.h | 11 + include/uapi/linux/android/binder.h | 5 +- init/Kconfig | 7 + kernel/cgroup/Makefile | 1 + kernel/cgroup/gpu.c | 304 +++++++++++ .../selftests/drivers/android/binder/Makefile | 8 + .../drivers/android/binder/binder_util.c | 254 +++++++++ .../drivers/android/binder/binder_util.h | 32 ++ .../selftests/drivers/android/binder/config | 4 + .../binder/test_dmabuf_cgroup_transfer.c | 480 ++++++++++++++++++ 19 files changed, 1598 insertions(+), 4 deletions(-) create mode 100644 Documentation/gpu/rfc/gpu-cgroup.rst create mode 100644 include/linux/cgroup_gpu.h create mode 100644 kernel/cgroup/gpu.c create mode 100644 tools/testing/selftests/drivers/android/binder/Makefile create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.c create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.h create mode 100644 tools/testing/selftests/drivers/android/binder/config create mode 100644 tools/testing/selftests/drivers/android/binder/test_dmabuf_cgroup_transfer.c -- 2.35.1.616.g0bdcbb4464-goog

3 years, 9 months

6
23
0 0

[PATCH] gpu: drm: Fix duplicate included linux/module.h

by Haowen Bai

Clean up the following includecheck warning: drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. No functional change. Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.7.4

3 years, 9 months

1
0
0 0

[syzbot] WARNING in drm_prime_destroy_file_private

by syzbot

Hello, syzbot found the following issue on: HEAD commit: ea4424be1688 Merge tag 'mtd/fixes-for-5.17-rc8' of git://g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14095f9e700000 kernel config: https://syzkaller.appspot.com/x/.config?x=aba0ab2928a512c2 dashboard link: https://syzkaller.appspot.com/bug?extid=2448673875b4e20db46a compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2448673875b4e20db46a(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 1 PID: 16791 at drivers/gpu/drm/drm_prime.c:228 drm_prime_destroy_file_private+0x3e/0x50 drivers/gpu/drm/drm_prime.c:228 Modules linked in: CPU: 1 PID: 16791 Comm: syz-executor.5 Not tainted 5.17.0-rc7-syzkaller-00020-gea4424be1688 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:drm_prime_destroy_file_private+0x3e/0x50 drivers/gpu/drm/drm_prime.c:228 Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 1f 48 8b 83 90 00 00 00 48 85 c0 75 06 5b e9 e7 6c 1d fd e8 e2 6c 1d fd <0f> 0b 5b e9 da 6c 1d fd e8 05 5a 64 fd eb da 0f 1f 00 41 55 49 89 RSP: 0018:ffffc90002af79e0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888025e72370 RCX: 0000000000000000 RDX: ffff8880727aa1c0 RSI: ffffffff845a788e RDI: ffff888025e72400 RBP: ffff8881471d4068 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff817e23e8 R11: 0000000000088078 R12: ffff888025e72000 R13: ffff888025e722b8 R14: ffff8881471d4098 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffea39ef0d8 CR3: 00000000791d8000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_file_free.part.0+0x6e5/0xb80 drivers/gpu/drm/drm_file.c:291 drm_file_free drivers/gpu/drm/drm_file.c:248 [inline] drm_close_helper.isra.0+0x17d/0x1f0 drivers/gpu/drm/drm_file.c:308 drm_release+0x1e6/0x530 drivers/gpu/drm/drm_file.c:495 __fput+0x286/0x9f0 fs/file_table.c:317 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x45a/0x2490 kernel/signal.c:2863 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 RIP: 0033:0x7f836c6a0471 Code: Unable to access opcode bytes at RIP 0x7f836c6a0447. RSP: 002b:00007f836afd22f0 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: 0000000000000000 RBX: 00007f836afd2700 RCX: 00007f836c6a0471 RDX: 00007f836afd29d0 RSI: 00007f836afd22f0 RDI: 00000000003d0f00 RBP: 00007ffed5e285a0 R08: 00007f836afd2700 R09: 00007f836afd2700 R10: 00007f836afd29d0 R11: 0000000000000206 R12: 00007ffed5e2840e R13: 00007ffed5e2840f R14: 00007f836afd2300 R15: 0000000000022000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

3 years, 9 months

1
0
0 0

[PATCH] dma-fence: fix free sync object incorrectly

by wangshumin

The function dma_fence_free() works fine because struct dma_fence is the first member of sync object. Use `kfree` make it more reasonable. Signed-off-by: wangshumin <pdsrazor(a)gmail.com> --- drivers/dma-buf/dma-fence-array.c | 2 +- drivers/dma-buf/dma-fence-chain.c | 2 +- drivers/dma-buf/sw_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index cb1bacb5a42b..fc52d837e579 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -120,7 +120,7 @@ static void dma_fence_array_release(struct dma_fence *fence) dma_fence_put(array->fences[i]); kfree(array->fences); - dma_fence_free(fence); + kfree(array); } const struct dma_fence_ops dma_fence_array_ops = { diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index 06f8ef97c6e8..b29e1f22f08e 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -203,7 +203,7 @@ static void dma_fence_chain_release(struct dma_fence *fence) dma_fence_put(prev); dma_fence_put(chain->fence); - dma_fence_free(fence); + kfree(chain); } const struct dma_fence_ops dma_fence_chain_ops = { diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c index 348b3a9170fa..80432eeb58c3 100644 --- a/drivers/dma-buf/sw_sync.c +++ b/drivers/dma-buf/sw_sync.c @@ -142,7 +142,7 @@ static void timeline_fence_release(struct dma_fence *fence) spin_unlock_irqrestore(fence->lock, flags); sync_timeline_put(parent); - dma_fence_free(fence); + kfree(pt); } static bool timeline_fence_signaled(struct dma_fence *fence) -- 2.17.1

3 years, 9 months

2
1
0 0

completely rework the dma_resv semantic

by Christian König

Hi Daniel, just a gentle ping that you wanted to take a look at this. Not much changed compared to the last version, only a minor bugfix in the dma_resv_get_singleton error handling. Regards, Christian.

3 years, 9 months

3
57
0 0

Re: [Linaro-mm-sig] [PATCH 18/24] dma-buf: add enum dma_resv_usage v3

by Daniel Vetter

On Tue, Dec 07, 2021 at 01:34:05PM +0100, Christian König wrote: > This change adds the dma_resv_usage enum and allows us to specify why a > dma_resv object is queried for its containing fences. > > Additional to that a dma_resv_usage_rw() helper function is added to aid > retrieving the fences for a read or write userspace submission. > > This is then deployed to the different query functions of the dma_resv > object and all of their users. When the write paratermer was previously > true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. > > v2: add KERNEL/OTHER in separate patch > v3: some kerneldoc suggestions by Daniel > > Signed-off-by: Christian König <christian.koenig(a)amd.com> Just commenting on the kerneldoc here. > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h > index 40ac9d486f8f..d96d8ca9af56 100644 > --- a/include/linux/dma-resv.h > +++ b/include/linux/dma-resv.h > @@ -49,6 +49,49 @@ extern struct ww_class reservation_ww_class; > > struct dma_resv_list; > > +/** > + * enum dma_resv_usage - how the fences from a dma_resv obj are used > + * > + * This enum describes the different use cases for a dma_resv object and > + * controls which fences are returned when queried. We need to link here to both dma_buf.resv and from there to here. Also we had a fair amount of text in the old dma_resv fields which should probably be included here. > + */ > +enum dma_resv_usage { > + /** > + * @DMA_RESV_USAGE_WRITE: Implicit write synchronization. > + * > + * This should only be used for userspace command submissions which add > + * an implicit write dependency. > + */ > + DMA_RESV_USAGE_WRITE, > + > + /** > + * @DMA_RESV_USAGE_READ: Implicit read synchronization. > + * > + * This should only be used for userspace command submissions which add > + * an implicit read dependency. I think the above would benefit from at least a link each to &dma_buf.resv for further discusion. Plus the READ flag needs a huge warning that in general it does _not_ guarantee that neither there's no writes possible, nor that the writes can be assumed mistakes and dropped (on buffer moves e.g.). Drivers can only make further assumptions for driver-internal dma_resv objects (e.g. on vm/pagetables) or when the fences are all fences of the same driver (e.g. the special sync rules amd has that takes the fence owner into account). We have this documented in the dma_buf.resv rules, but since it came up again in a discussion with Thomas H. somewhere, it's better to hammer this in a few more time. Specically in generally ignoring READ fences for buffer moves (well the copy job, memory freeing still has to wait for all of them) is a correctness bug. Maybe include a big warning that really the difference between READ and WRITE should only matter for implicit sync, and _not_ for anything else the kernel does. I'm assuming the actual replacement is all mechanical, so I skipped that one for now, that's for next year :-) -Daniel > + */ > + DMA_RESV_USAGE_READ, > +}; > + > +/** > + * dma_resv_usage_rw - helper for implicit sync > + * @write: true if we create a new implicit sync write > + * > + * This returns the implicit synchronization usage for write or read accesses, > + * see enum dma_resv_usage. > + */ > +static inline enum dma_resv_usage dma_resv_usage_rw(bool write) > +{ > + /* This looks confusing at first sight, but is indeed correct. > + * > + * The rational is that new write operations needs to wait for the > + * existing read and write operations to finish. > + * But a new read operation only needs to wait for the existing write > + * operations to finish. > + */ > + return write ? DMA_RESV_USAGE_READ : DMA_RESV_USAGE_WRITE; > +} > + > /** > * struct dma_resv - a reservation object manages fences for a buffer > * > @@ -147,8 +190,8 @@ struct dma_resv_iter { > /** @obj: The dma_resv object we iterate over */ > struct dma_resv *obj; > > - /** @all_fences: If all fences should be returned */ > - bool all_fences; > + /** @usage: Controls which fences are returned */ > + enum dma_resv_usage usage; > > /** @fence: the currently handled fence */ > struct dma_fence *fence; > @@ -178,14 +221,14 @@ struct dma_fence *dma_resv_iter_next(struct dma_resv_iter *cursor); > * dma_resv_iter_begin - initialize a dma_resv_iter object > * @cursor: The dma_resv_iter object to initialize > * @obj: The dma_resv object which we want to iterate over > - * @all_fences: If all fences should be returned or just the exclusive one > + * @usage: controls which fences to include, see enum dma_resv_usage. > */ > static inline void dma_resv_iter_begin(struct dma_resv_iter *cursor, > struct dma_resv *obj, > - bool all_fences) > + enum dma_resv_usage usage) > { > cursor->obj = obj; > - cursor->all_fences = all_fences; > + cursor->usage = usage; > cursor->fence = NULL; > } > > @@ -242,7 +285,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > * dma_resv_for_each_fence - fence iterator > * @cursor: a struct dma_resv_iter pointer > * @obj: a dma_resv object pointer > - * @all_fences: true if all fences should be returned > + * @usage: controls which fences to return > * @fence: the current fence > * > * Iterate over the fences in a struct dma_resv object while holding the > @@ -251,8 +294,8 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > * valid as long as the lock is held and so no extra reference to the fence is > * taken. > */ > -#define dma_resv_for_each_fence(cursor, obj, all_fences, fence) \ > - for (dma_resv_iter_begin(cursor, obj, all_fences), \ > +#define dma_resv_for_each_fence(cursor, obj, usage, fence) \ > + for (dma_resv_iter_begin(cursor, obj, usage), \ > fence = dma_resv_iter_first(cursor); fence; \ > fence = dma_resv_iter_next(cursor)) > > @@ -419,14 +462,14 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence); > void dma_resv_replace_fences(struct dma_resv *obj, uint64_t context, > struct dma_fence *fence); > void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence); > -int dma_resv_get_fences(struct dma_resv *obj, bool write, > +int dma_resv_get_fences(struct dma_resv *obj, enum dma_resv_usage usage, > unsigned int *num_fences, struct dma_fence ***fences); > -int dma_resv_get_singleton(struct dma_resv *obj, bool write, > +int dma_resv_get_singleton(struct dma_resv *obj, enum dma_resv_usage usage, > struct dma_fence **fence); > int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src); > -long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr, > - unsigned long timeout); > -bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all); > +long dma_resv_wait_timeout(struct dma_resv *obj, enum dma_resv_usage usage, > + bool intr, unsigned long timeout); > +bool dma_resv_test_signaled(struct dma_resv *obj, enum dma_resv_usage usage); > void dma_resv_describe(struct dma_resv *obj, struct seq_file *seq); > > #endif /* _LINUX_RESERVATION_H */ > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 9 months

3
2
0 0

[PATCH] ASoC: qcom: Fix error code in lpass_platform_copy()

by Dan Carpenter

The copy_to/from_user() functions return the number of bytes remaining to be copied. This function needs to return negative error codes because snd_soc_pcm_component_copy_user() treats positive returns as success in soc_component_ret(). Fixes: 7d7209557b67 ("ASoC: qcom: Add support for codec dma driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/soc/qcom/lpass-platform.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c index bf180a594c19..620312529c2f 100644 --- a/sound/soc/qcom/lpass-platform.c +++ b/sound/soc/qcom/lpass-platform.c @@ -1228,15 +1228,19 @@ static int lpass_platform_copy(struct snd_soc_component *component, channel * (rt->dma_bytes / rt->channels)); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { - if (is_cdc_dma_port(dai_id)) + if (is_cdc_dma_port(dai_id)) { ret = copy_from_user_toio(dma_buf, buf, bytes); - else - ret = copy_from_user((void __force *)dma_buf, buf, bytes); + } else { + if (copy_from_user((void __force *)dma_buf, buf, bytes)) + ret = -EFAULT; + } } else if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { - if (is_cdc_dma_port(dai_id)) + if (is_cdc_dma_port(dai_id)) { ret = copy_to_user_fromio(buf, dma_buf, bytes); - else - ret = copy_to_user(buf, (void __force *)dma_buf, bytes); + } else { + if (copy_to_user(buf, (void __force *)dma_buf, bytes)) + ret = -EFAULT; + } } return ret; -- 2.20.1

3 years, 9 months

2
1
0 0

[PATCH] dma-fance: Add dma_fence_assert_in_signalling_section

by Daniel Vetter

Useful for checking for dma-fence signalling annotations since they don't quite nest as freely as we'd like to. Cc: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-fence.c | 19 +++++++++++++++++++ include/linux/dma-fence.h | 2 ++ 2 files changed, 21 insertions(+) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 066400ed8841..2b7c3fc965e6 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -307,6 +307,25 @@ bool dma_fence_begin_signalling(void) } EXPORT_SYMBOL(dma_fence_begin_signalling); +/** + * dma_fence_assert_in_signalling_section - check fence signalling annotations + * + * Since dma_fence_begin_signalling() and dma_fence_end_signalling() are built + * using lockdep annotations they have limitations on how freely they can be + * nested. Specifically, they cannot be on both inside and outside of locked + * sections, which in practice means the annotations often have to be pushed out + * to the top level callers. + * + * To ensure low-level functions are only called with the correction + * annotations, this function can be used to check for that. + */ +void dma_fence_assert_in_signalling_section(void) +{ + if (!in_atomic()) + lockdep_assert(lock_is_held(&dma_fence_lockdep_map)); +} +EXPORT_SYMBOL(dma_fence_assert_in_signalling_section); + /** * dma_fence_end_signalling - end a critical DMA fence signalling section * @cookie: opaque cookie from dma_fence_begin_signalling() diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 775cdc0b4f24..7179a5692f72 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -356,6 +356,7 @@ dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep) #ifdef CONFIG_LOCKDEP bool dma_fence_begin_signalling(void); +void dma_fence_assert_in_signalling_section(void); void dma_fence_end_signalling(bool cookie); void __dma_fence_might_wait(void); #else @@ -363,6 +364,7 @@ static inline bool dma_fence_begin_signalling(void) { return true; } +static inline void dma_fence_assert_in_signalling_section(void) {} static inline void dma_fence_end_signalling(bool cookie) {} static inline void __dma_fence_might_wait(void) {} #endif -- 2.34.1

3 years, 9 months

2
1
0 0

[PATCH] dma-buf: check the return value of kstrdup()

by xkernel.wang＠foxmail.com

From: Xiaoke Wang <xkernel.wang(a)foxmail.com> kstrdup() is a memory allocation function which can return NULL when some internaly memory errors happen. It is better to check the return value of it to prevent further wrong memory access. Signed-off-by: Xiaoke Wang <xkernel.wang(a)foxmail.com> --- drivers/dma-buf/selftest.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/selftest.c b/drivers/dma-buf/selftest.c index c60b694..2c29e2a 100644 --- a/drivers/dma-buf/selftest.c +++ b/drivers/dma-buf/selftest.c @@ -50,6 +50,9 @@ static bool apply_subtest_filter(const char *caller, const char *name) bool result = true; filter = kstrdup(__st_filter, GFP_KERNEL); + if (!filter) + return false; + for (sep = filter; (tok = strsep(&sep, ","));) { bool allow = true; char *sl; --

3 years, 9 months

3
2
0 0

[PATCH] drm/amdgpu: check vm bo eviction valuable at last

by Qiang Yu

Workstation application ANSA/META get this error dmesg: [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16) This is caused by: 1. create a 256MB buffer in invisible VRAM 2. CPU map the buffer and access it causes vm_fault and try to move it to visible VRAM 3. force visible VRAM space and traverse all VRAM bos to check if evicting this bo is valuable 4. when checking a VM bo (in invisible VRAM), amdgpu_vm_evictable() will set amdgpu_vm->evicting, but latter due to not in visible VRAM, won't really evict it so not add it to amdgpu_vm->evicted 5. before next CS to clear the amdgpu_vm->evicting, user VM ops ioctl will pass amdgpu_vm_ready() (check amdgpu_vm->evicted) but fail in amdgpu_vm_bo_update_mapping() (check amdgpu_vm->evicting) and get this error log This error won't affect functionality as next CS will finish the waiting VM ops. But we'd better make the amdgpu_vm->evicting correctly reflact the vm status and clear the error log. Signed-off-by: Qiang Yu <qiang.yu(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 85 ++++++++++++++----------- 1 file changed, 47 insertions(+), 38 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 5a32ee66d8c8..88a27911054f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1306,45 +1306,11 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device *adev, struct ttm_tt *ttm, return flags; } -/* - * amdgpu_ttm_bo_eviction_valuable - Check to see if we can evict a buffer - * object. - * - * Return true if eviction is sensible. Called by ttm_mem_evict_first() on - * behalf of ttm_bo_mem_force_space() which tries to evict buffer objects until - * it can find space for a new object and by ttm_bo_force_list_clean() which is - * used to clean out a memory space. - */ -static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, - const struct ttm_place *place) +static bool amdgpu_ttm_mem_eviction_valuable(struct ttm_buffer_object *bo, + const struct ttm_place *place) { unsigned long num_pages = bo->resource->num_pages; struct amdgpu_res_cursor cursor; - struct dma_resv_list *flist; - struct dma_fence *f; - int i; - - /* Swapout? */ - if (bo->resource->mem_type == TTM_PL_SYSTEM) - return true; - - if (bo->type == ttm_bo_type_kernel && - !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo))) - return false; - - /* If bo is a KFD BO, check if the bo belongs to the current process. - * If true, then return false as any KFD process needs all its BOs to - * be resident to run successfully - */ - flist = dma_resv_shared_list(bo->base.resv); - if (flist) { - for (i = 0; i < flist->shared_count; ++i) { - f = rcu_dereference_protected(flist->shared[i], - dma_resv_held(bo->base.resv)); - if (amdkfd_fence_check_mm(f, current->mm)) - return false; - } - } switch (bo->resource->mem_type) { case AMDGPU_PL_PREEMPT: @@ -1377,10 +1343,53 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, return false; default: - break; + return ttm_bo_eviction_valuable(bo, place); } +} - return ttm_bo_eviction_valuable(bo, place); +/* + * amdgpu_ttm_bo_eviction_valuable - Check to see if we can evict a buffer + * object. + * + * Return true if eviction is sensible. Called by ttm_mem_evict_first() on + * behalf of ttm_bo_mem_force_space() which tries to evict buffer objects until + * it can find space for a new object and by ttm_bo_force_list_clean() which is + * used to clean out a memory space. + */ +static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, + const struct ttm_place *place) +{ + struct dma_resv_list *flist; + struct dma_fence *f; + int i; + + /* Swapout? */ + if (bo->resource->mem_type == TTM_PL_SYSTEM) + return true; + + /* If bo is a KFD BO, check if the bo belongs to the current process. + * If true, then return false as any KFD process needs all its BOs to + * be resident to run successfully + */ + flist = dma_resv_shared_list(bo->base.resv); + if (flist) { + for (i = 0; i < flist->shared_count; ++i) { + f = rcu_dereference_protected(flist->shared[i], + dma_resv_held(bo->base.resv)); + if (amdkfd_fence_check_mm(f, current->mm)) + return false; + } + } + + /* Check by different mem type. */ + if (!amdgpu_ttm_mem_eviction_valuable(bo, place)) + return false; + + /* VM bo should be checked at last because it will mark VM evicting. */ + if (bo->type == ttm_bo_type_kernel) + return amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)); + + return true; } static void amdgpu_ttm_vram_mm_access(struct amdgpu_device *adev, loff_t pos, -- 2.25.1

3 years, 10 months

4
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig