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

[PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory

by Christophe JAILLET

If 'list_limit' is set to a very high value, 'lsize' computation could overflow if 'head.count' is big enough. In such a case, udmabuf_create() will access to memory beyond 'list'. Use size_mul() to saturate the value, and have memdup_user() fail. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..fb4c4b5b3332 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; + size_t lsize; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; if (head.count > list_limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; + lsize = size_mul(sizeof(struct udmabuf_create_item), head.count); list = memdup_user((void __user *)(arg + sizeof(head)), lsize); if (IS_ERR(list)) return PTR_ERR(list); -- 2.34.1

2 years, 2 months

3
3
0 0

Re: [PATCH 00/10] Add mediate-drm secure flow for SVP

by Jeffrey Kardatzke

On Tue, Sep 19, 2023 at 10:26 PM CK Hu (胡俊光) <ck.hu(a)mediatek.com> wrote: > > Hi, Jason: > > On Tue, 2023-09-19 at 11:03 +0800, Jason-JH.Lin wrote: > > The patch series provides drm driver support for enabling secure > > video > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > Memory Definitions: > > secure memory - Memory allocated in the TEE (Trusted Execution > > Environment) which is inaccessible in the REE (Rich Execution > > Environment, i.e. linux kernel/userspace). > > secure handle - Integer value which acts as reference to 'secure > > memory'. Used in communication between TEE and REE to reference > > 'secure memory'. > > secure buffer - 'secure memory' that is used to store decrypted, > > compressed video or for other general purposes in the TEE. > > secure surface - 'secure memory' that is used to store graphic > > buffers. > > > > Memory Usage in SVP: > > The overall flow of SVP starts with encrypted video coming in from an > > outside source into the REE. The REE will then allocate a 'secure > > buffer' and send the corresponding 'secure handle' along with the > > encrypted, compressed video data to the TEE. The TEE will then > > decrypt > > the video and store the result in the 'secure buffer'. The REE will > > then allocate a 'secure surface'. The REE will pass the 'secure > > handles' for both the 'secure buffer' and 'secure surface' into the > > TEE for video decoding. The video decoder HW will then decode the > > contents of the 'secure buffer' and place the result in the 'secure > > surface'. The REE will then attach the 'secure surface' to the > > overlay > > plane for rendering of the video. > > > > Everything relating to ensuring security of the actual contents of > > the > > 'secure buffer' and 'secure surface' is out of scope for the REE and > > is the responsibility of the TEE. > > > > DRM driver handles allocation of gem objects that are backed by a > > 'secure > > surface' and for displaying a 'secure surface' on the overlay plane. > > This introduces a new flag for object creation called > > DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure > > surface'. All changes here are in MediaTek specific code. > > How do you define SVP? Is there standard requirement we could refer to? > If the secure video buffer is read by display hardware and output to > HDMI without any protection and user could capture HDMI signal, is this > secure? SVP (Secure Video Path) is essentially the video being completed isolated from the kernel/userspace. The specific requirements for it vary between implementations. Regarding HDMI/HDCP output; it's the responsibility of the TEE to enforce that. Nothing on the kernel/userspace side needs to be concerned about enforcing HDCP. The only thing userspace is involved in there is actually turning on HDCP via the kernel drivers; and then the TEE ensures that it is active if the policy for the encrypted content requires it. > > Regards, > CK > > > > > --- > > Based on 2 series: > > [1] Add CMDQ secure driver for SVP > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-medi… > > > > > > [2] dma-buf: heaps: Add MediaTek secure heap > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-medi… > > > > --- > > > > CK Hu (1): > > drm/mediatek: Add interface to allocate MediaTek GEM buffer. > > > > Jason-JH.Lin (9): > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag > > drm/mediatek: Add secure buffer control flow to mtk_drm_gem > > drm/mediatek: Add secure identify flag and funcution to > > mtk_drm_plane > > drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info > > drm/mediatek: Add get_sec_port interface to mtk_ddp_comp > > drm/mediatek: Add secure layer config support for ovl > > drm/mediatek: Add secure layer config support for ovl_adaptor > > drm/mediatek: Add secure flow support to mediatek-drm > > arm64: dts: mt8195-cherry: Add secure mbox settings for vdosys > > > > .../boot/dts/mediatek/mt8195-cherry.dtsi | 10 + > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 271 > > +++++++++++++++++- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 +- > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 ++ > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > > include/uapi/drm/mediatek_drm.h | 59 ++++ > > 16 files changed, 575 insertions(+), 17 deletions(-) > > create mode 100644 include/uapi/drm/mediatek_drm.h > >

2 years, 2 months

1
0
0 0

[PATCH 00/10] Add mediate-drm secure flow for SVP

by Jason-JH.Lin

The patch series provides drm driver support for enabling secure video path (SVP) playback on MediaiTek hardware in the Linux kernel. Memory Definitions: secure memory - Memory allocated in the TEE (Trusted Execution Environment) which is inaccessible in the REE (Rich Execution Environment, i.e. linux kernel/userspace). secure handle - Integer value which acts as reference to 'secure memory'. Used in communication between TEE and REE to reference 'secure memory'. secure buffer - 'secure memory' that is used to store decrypted, compressed video or for other general purposes in the TEE. secure surface - 'secure memory' that is used to store graphic buffers. Memory Usage in SVP: The overall flow of SVP starts with encrypted video coming in from an outside source into the REE. The REE will then allocate a 'secure buffer' and send the corresponding 'secure handle' along with the encrypted, compressed video data to the TEE. The TEE will then decrypt the video and store the result in the 'secure buffer'. The REE will then allocate a 'secure surface'. The REE will pass the 'secure handles' for both the 'secure buffer' and 'secure surface' into the TEE for video decoding. The video decoder HW will then decode the contents of the 'secure buffer' and place the result in the 'secure surface'. The REE will then attach the 'secure surface' to the overlay plane for rendering of the video. Everything relating to ensuring security of the actual contents of the 'secure buffer' and 'secure surface' is out of scope for the REE and is the responsibility of the TEE. DRM driver handles allocation of gem objects that are backed by a 'secure surface' and for displaying a 'secure surface' on the overlay plane. This introduces a new flag for object creation called DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure surface'. All changes here are in MediaTek specific code. --- Based on 2 series: [1] Add CMDQ secure driver for SVP - https://patchwork.kernel.org/project/linux-mediatek/list/?series=785332 [2] dma-buf: heaps: Add MediaTek secure heap - https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776 --- CK Hu (1): drm/mediatek: Add interface to allocate MediaTek GEM buffer. Jason-JH.Lin (9): drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag drm/mediatek: Add secure buffer control flow to mtk_drm_gem drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info drm/mediatek: Add get_sec_port interface to mtk_ddp_comp drm/mediatek: Add secure layer config support for ovl drm/mediatek: Add secure layer config support for ovl_adaptor drm/mediatek: Add secure flow support to mediatek-drm arm64: dts: mt8195-cherry: Add secure mbox settings for vdosys .../boot/dts/mediatek/mt8195-cherry.dtsi | 10 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 271 +++++++++++++++++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + include/uapi/drm/mediatek_drm.h | 59 ++++ 16 files changed, 575 insertions(+), 17 deletions(-) create mode 100644 include/uapi/drm/mediatek_drm.h -- 2.18.0

2 years, 2 months

4
13
0 0

[syzbot] [dri?] WARNING in drm_gem_object_handle_put_unlocked

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 0bb80ecc33a8 Linux 6.6-rc1 git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=1002530c680000 kernel config: https://syzkaller.appspot.com/x/.config?x=f4894cf58531f dashboard link: https://syzkaller.appspot.com/bug?extid=ef3256a360c02207a4cb compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a79ca0680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16900402680000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/eeb0cac260c7/disk-0bb80ecc.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/a3c360110254/vmlinux-0bb80ecc.… kernel image: https://storage.googleapis.com/syzbot-assets/22b81065ba5f/bzImage-0bb80ecc.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+ef3256a360c02207a4cb(a)syzkaller.appspotmail.com R10: 0000000000000000 R11: 0000000000000246 R12: 00007fda971e917c R13: 00007fda97153210 R14: 0023647261632f69 R15: 6972642f7665642f </TASK> ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5043 at drivers/gpu/drm/drm_gem.c:225 drm_gem_object_handle_put_unlocked+0x299/0x390 drivers/gpu/drm/drm_gem.c:225 Modules linked in: CPU: 1 PID: 5043 Comm: syz-executor141 Not tainted 6.6.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 RIP: 0010:drm_gem_object_handle_put_unlocked+0x299/0x390 drivers/gpu/drm/drm_gem.c:225 Code: ea 03 0f b6 04 02 84 c0 74 0c 3c 03 7f 08 4c 89 f7 e8 2b 06 2a fd c7 83 20 01 00 00 00 00 00 00 e9 98 fe ff ff e8 57 44 d4 fc <0f> 0b 5b 5d 41 5c 41 5d 41 5e e9 48 44 d4 fc e8 43 44 d4 fc 48 8d RSP: 0018:ffffc90003d5fbb8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888027b61000 RCX: 0000000000000000 RDX: ffff888014fcbb80 RSI: ffffffff84b38a29 RDI: 0000000000000005 RBP: ffff888027b61004 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88801d140000 R13: ffff888027b61008 R14: 0000000000000000 R15: ffff888027b61018 FS: 00007fda971536c0(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda971fe794 CR3: 0000000072975000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_gem_handle_create_tail+0x32f/0x540 drivers/gpu/drm/drm_gem.c:407 drm_gem_shmem_create_with_handle drivers/gpu/drm/drm_gem_shmem_helper.c:417 [inline] drm_gem_shmem_dumb_create+0x21a/0x310 drivers/gpu/drm/drm_gem_shmem_helper.c:505 drm_mode_create_dumb drivers/gpu/drm/drm_dumb_buffers.c:96 [inline] drm_mode_create_dumb_ioctl+0x268/0x2f0 drivers/gpu/drm/drm_dumb_buffers.c:102 drm_ioctl_kernel+0x280/0x4c0 drivers/gpu/drm/drm_ioctl.c:789 drm_ioctl+0x5cb/0xbf0 drivers/gpu/drm/drm_ioctl.c:892 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl fs/ioctl.c:857 [inline] __x64_sys_ioctl+0x18f/0x210 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fda971954e9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fda971531f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fda9721c3e8 RCX: 00007fda971954e9 RDX: 0000000020000080 RSI: 00000000c02064b2 RDI: 0000000000000003 RBP: 00007fda9721c3e0 R08: 00007fda97152f96 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fda971e917c R13: 00007fda97153210 R14: 0023647261632f69 R15: 6972642f7665642f </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. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

2 years, 3 months

1
0
0 0

Re: [syzbot] [mm?] kernel BUG in filemap_unaccount_folio

by syzbot

syzbot has bisected this issue to: commit 5c074eeabbd332b11559f7fc1e89d456f94801fb Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Wed Nov 14 12:20:29 2018 +0000 udmabuf: set read/write flag when exporting bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12b21bbfa80000 start commit: db906f0ca6bb Merge tag 'phy-for-6.6' of git://git.kernel.o.. git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=11b21bbfa80000 console output: https://syzkaller.appspot.com/x/log.txt?x=16b21bbfa80000 kernel config: https://syzkaller.appspot.com/x/.config?x=3bd57a1ac08277b0 dashboard link: https://syzkaller.appspot.com/bug?extid=17a207d226b8a5fb0fd9 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11609f38680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c1fc00680000 Reported-by: syzbot+17a207d226b8a5fb0fd9(a)syzkaller.appspotmail.com Fixes: 5c074eeabbd3 ("udmabuf: set read/write flag when exporting") For information about bisection process see: https://goo.gl/tpsmEJ#bisection

2 years, 3 months

1
0
0 0

[linus:master] [dma] d62c43a953: WARNING:at_mm/slab_common.c:#kmem_cache_destroy

by kernel test robot

hi, Arvind Yadav, we know this commit is quite old, but it shows persistent low rate issue and parent keeps clean even when we run both this commit and parent up to ~300 times. the config to build both kernel is a randconfig as in https://download.01.org/0day-ci/archive/20230913/202309132239.70437559-oliv… c85d00d4fd8b98ea d62c43a953ce02d54521ec06217 ---------------- --------------------------- fail:runs %reproduction fail:runs | | | :300 6% 17:312 dmesg.BUG_mock_fence(Tainted:G_T):Objects_remaining_in_mock_fence_on__kmem_cache_shutdown() :300 11% 33:312 dmesg.EIP:kmem_cache_destroy :300 11% 33:312 dmesg.WARNING:at_mm/slab_common.c:#kmem_cache_destroy at the same time, as in below formal report mentioned, we still observed similar issue on latest linus/master and linux-next/master, so we just send out this report FYI. Hello, kernel test robot noticed "WARNING:at_mm/slab_common.c:#kmem_cache_destroy" on: commit: d62c43a953ce02d54521ec06217d0c2ed6d489af ("dma-buf: Enable signaling on fence for selftests") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master [test failed on linus/master 0bb80ecc33a8fb5a682236443c1e740d5c917d1d] [test failed on linux-next/master 3c13c772fc233a10342c8e1605ff0855dfdf0c89] in testcase: boot compiler: gcc-12 test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G (please refer to attached dmesg/kmsg for entire log/backtrace) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202309132239.70437559-oliver.sang@intel.com [ 21.601153][ T1] ------------[ cut here ]------------ [ 21.693224][ T1] kmem_cache_destroy mock_fence: Slab cache still has objects when called from dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.693275][ T1] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:478 kmem_cache_destroy (mm/slab_common.c:478) [ 21.697039][ T1] Modules linked in: [ 21.697859][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G T 6.0.0-rc2-00744-gd62c43a953ce #1 26be6099e9dfaf1dc1fa091a1f5a61f95afa9121 [ 21.700290][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.702175][ T1] EIP: kmem_cache_destroy (mm/slab_common.c:478) [ 21.707576][ T1] Code: 00 ff 4b 2c 0f 85 b2 00 00 00 89 d8 e8 ea 4a 02 00 85 c0 74 1f ff 75 04 ff 73 40 68 6c ff 96 d7 68 7d 44 09 d8 e8 40 c8 da 00 <0f> 0b 83 c4 10 e9 88 00 00 00 8d 73 44 89 f0 e8 8a 8e 2e 00 84 c0 All code ======== 0: 00 ff add %bh,%bh 2: 4b 2c 0f rex.WXB sub $0xf,%al 5: 85 b2 00 00 00 89 test %esi,-0x77000000(%rdx) b: d8 e8 fsubr %st(0),%st d: ea (bad) e: 4a 02 00 rex.WX add (%rax),%al 11: 85 c0 test %eax,%eax 13: 74 1f je 0x34 15: ff 75 04 push 0x4(%rbp) 18: ff 73 40 push 0x40(%rbx) 1b: 68 6c ff 96 d7 push $0xffffffffd796ff6c 20: 68 7d 44 09 d8 push $0xffffffffd809447d 25: e8 40 c8 da 00 call 0xdac86a 2a:* 0f 0b ud2 <-- trapping instruction 2c: 83 c4 10 add $0x10,%esp 2f: e9 88 00 00 00 jmp 0xbc 34: 8d 73 44 lea 0x44(%rbx),%esi 37: 89 f0 mov %esi,%eax 39: e8 8a 8e 2e 00 call 0x2e8ec8 3e: 84 c0 test %al,%al Code starting with the faulting instruction =========================================== 0: 0f 0b ud2 2: 83 c4 10 add $0x10,%esp 5: e9 88 00 00 00 jmp 0x92 a: 8d 73 44 lea 0x44(%rbx),%esi d: 89 f0 mov %esi,%eax f: e8 8a 8e 2e 00 call 0x2e8e9e 14: 84 c0 test %al,%al [ 21.711048][ T1] EAX: 00000066 EBX: ee62b680 ECX: 00000001 EDX: 80000001 [ 21.712412][ T1] ESI: d87beb98 EDI: ffffffff EBP: c128dee8 ESP: c128decc [ 21.713723][ T1] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010292 [ 21.715192][ T1] CR0: 80050033 CR2: b7d07070 CR3: 189fe000 CR4: 00040690 [ 21.716533][ T1] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 21.717859][ T1] DR6: fffe0ff0 DR7: 00000400 [ 21.718792][ T1] Call Trace: [ 21.719488][ T1] ? dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.720419][ T1] dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709) [ 21.721327][ T1] st_init (drivers/dma-buf/selftest.c:141 drivers/dma-buf/selftest.c:155) [ 21.722117][ T1] ? udmabuf_dev_init (drivers/dma-buf/selftest.c:154) [ 21.723147][ T1] do_one_initcall (init/main.c:1296) [ 21.724108][ T1] do_initcalls (init/main.c:1368 init/main.c:1385) [ 21.725029][ T1] kernel_init_freeable (init/main.c:1615) [ 21.726030][ T1] ? rest_init (init/main.c:1492) [ 21.726907][ T1] kernel_init (init/main.c:1502) [ 21.727732][ T1] ret_from_fork (arch/x86/entry/entry_32.S:770) [ 21.728608][ T1] irq event stamp: 1964001 [ 21.729500][ T1] hardirqs last enabled at (1964011): __up_console_sem (arch/x86/include/asm/irqflags.h:29 (discriminator 1) arch/x86/include/asm/irqflags.h:70 (discriminator 1) arch/x86/include/asm/irqflags.h:130 (discriminator 1) kernel/printk/printk.c:264 (discriminator 1)) [ 21.731230][ T1] hardirqs last disabled at (1964020): __up_console_sem (kernel/printk/printk.c:262 (discriminator 1)) [ 21.735324][ T1] softirqs last enabled at (1963746): __do_softirq (arch/x86/include/asm/preempt.h:27 kernel/softirq.c:415 kernel/softirq.c:600) [ 21.736992][ T1] softirqs last disabled at (1963735): do_softirq_own_stack (arch/x86/kernel/irq_32.c:60 arch/x86/kernel/irq_32.c:150) [ 21.738743][ T1] ---[ end trace 0000000000000000 ]--- [ 21.739776][ T1] dma-buf: Running dma_fence_unwrap The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20230913/202309132239.70437559-oliv… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 3 months

1
0
0 0

[PATCH] spi: tegra: Fix missing IRQ check in tegra_slink_probe()

by Zhang Shurong

This func misses checking for platform_get_irq()'s call and may passes the negative error codes to request_irq(), which takes unsigned IRQ #, causing it to fail with -EINVAL, overriding an original error code. Fix this by stop calling request_irq() with invalid IRQ #s. Fixes: dc4dc3605639 ("spi: tegra: add spi driver for SLINK controller") Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com> --- drivers/spi/spi-tegra20-slink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c index 4d6db6182c5e..f5cd365c913a 100644 --- a/drivers/spi/spi-tegra20-slink.c +++ b/drivers/spi/spi-tegra20-slink.c @@ -1086,6 +1086,8 @@ static int tegra_slink_probe(struct platform_device *pdev) reset_control_deassert(tspi->rst); spi_irq = platform_get_irq(pdev, 0); + if (spi_irq < 0) + return spi_irq; tspi->irq = spi_irq; ret = request_threaded_irq(tspi->irq, tegra_slink_isr, tegra_slink_isr_thread, IRQF_ONESHOT, -- 2.30.2

2 years, 3 months

3
2
0 0

Redukcja mocy na wezwanie

by Dawid Jarocki

Dzień dobry, czy jest możliwość, by na pewien czas Państwa zakład produkcyjny mógł zrezygnować z części lub całości zużywanej energii? W zamian za gotowość do redukcji i jej wykonanie mogą otrzymać Państwo stałe wynagrodzenie, które w przeliczeniu na 1 MW redukcji mocy wynosi od 500 do 720 tys. zł w zależności od czasu zdolności do redukcji. Uczestnictwo w programie DSR (Demand Side Response) to dla Państwa brak kosztów implementacji i wzrost bezpieczeństwa energetycznego. Jeśli interesuje Państwa generowanie wieloletnich przychodów z programu DSR, proszę o wiadomość. Pozdrawiam Dawid Jarocki

2 years, 3 months

1
0
0 0

[PATCH v1 v1 0/7] DRM driver for verisilicon

by Keith Zhao

This patch is a drm driver for Starfive Soc JH7110, I am sending Drm driver part and HDMI driver part. We used GEM framework for buffer management , and for buffer allocation,we use DMA APIs. the Starfive HDMI servers as interface between a LCD Controller and a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and one HDMI transmitter PHY. (Sound support is not include in this patch) This patchset should be applied after the patchset: https://patchwork.kernel.org/project/linux-clk/cover/20230713113902.56519-1… V1: Changes since v1: - Further standardize the yaml file. - Dts naming convention improved. - Fix the problem of compiling and loading ko files. - Use drm new api to automatically manage resources. - Drop struct vs_crtc_funcs&vs_plane_funcs，subdivide the plane's help interface - Reduce the modifiers unused. - Optimize the hdmi driver code Keith Zhao (7): MAINTAINERS: Update starfive maintainers dt-bindings: display: Add yamls for JH7110 display system riscv: dts: starfive: jh7110: add dc controller and hdmi node drm/fourcc: Add drm/vs tiled modifiers drm/vs: Register DRM device drm/vs: Add KMS crtc&plane drm/vs: Add hdmi .../starfive/starfive,display-subsystem.yaml | 41 + .../starfive/starfive,jh7110-dc8200.yaml | 107 + .../starfive/starfive,jh7110-inno-hdmi.yaml | 92 + MAINTAINERS | 7 + .../jh7110-starfive-visionfive-2.dtsi | 87 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 43 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/verisilicon/Kconfig | 25 + drivers/gpu/drm/verisilicon/Makefile | 13 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 940 ++++++++ drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 365 +++ drivers/gpu/drm/verisilicon/vs_crtc.h | 54 + drivers/gpu/drm/verisilicon/vs_dc.c | 1036 +++++++++ drivers/gpu/drm/verisilicon/vs_dc.h | 87 + drivers/gpu/drm/verisilicon/vs_dc_hw.c | 2008 +++++++++++++++++ drivers/gpu/drm/verisilicon/vs_dc_hw.h | 496 ++++ drivers/gpu/drm/verisilicon/vs_drv.c | 274 +++ drivers/gpu/drm/verisilicon/vs_drv.h | 54 + drivers/gpu/drm/verisilicon/vs_gem.c | 298 +++ drivers/gpu/drm/verisilicon/vs_gem.h | 50 + drivers/gpu/drm/verisilicon/vs_modeset.c | 92 + drivers/gpu/drm/verisilicon/vs_modeset.h | 13 + drivers/gpu/drm/verisilicon/vs_plane.c | 502 +++++ drivers/gpu/drm/verisilicon/vs_plane.h | 65 + drivers/gpu/drm/verisilicon/vs_type.h | 70 + include/uapi/drm/drm_fourcc.h | 27 + include/uapi/drm/vs_drm.h | 50 + 29 files changed, 7194 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml create mode 100644 drivers/gpu/drm/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.c create mode 100644 drivers/gpu/drm/verisilicon/vs_gem.h create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1

2 years, 3 months

7
25
0 0

[syzbot] [dri?] WARNING in drm_syncobj_array_find

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 0468be89b3fa Merge tag 'iommu-updates-v6.6' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13571367a80000 kernel config: https://syzkaller.appspot.com/x/.config?x=39744401c57166fc dashboard link: https://syzkaller.appspot.com/bug?extid=95416f957d84e858b377 compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111c39a8680000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1267d83fa80000 Downloadable assets: disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk… vmlinux: https://storage.googleapis.com/syzbot-assets/7feba36779de/vmlinux-0468be89.… kernel image: https://storage.googleapis.com/syzbot-assets/b1cdc0506491/bzImage-0468be89.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+95416f957d84e858b377(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 2 PID: 5141 at mm/page_alloc.c:4415 __alloc_pages+0x3ab/0x4a0 mm/page_alloc.c:4415 Modules linked in: CPU: 2 PID: 5141 Comm: syz-executor127 Not tainted 6.5.0-syzkaller-10885-g0468be89b3fa #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:__alloc_pages+0x3ab/0x4a0 mm/page_alloc.c:4415 Code: ff ff 00 0f 84 2f fe ff ff 80 ce 01 e9 27 fe ff ff 83 fe 0a 0f 86 3a fd ff ff 80 3d c9 37 e6 0c 00 75 09 c6 05 c0 37 e6 0c 01 <0f> 0b 45 31 f6 e9 97 fe ff ff e8 b6 10 9e ff 84 c0 0f 85 8a fe ff RSP: 0018:ffffc900030b7a18 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000016 RDI: 0000000000040cc0 RBP: 1ffff92000616f44 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000ffffff1f R11: 0000000000000000 R12: 0000000000000016 R13: 0000000000000000 R14: ffffffff84b4e215 R15: ffff888013722000 FS: 00005555555a4380(0000) GS:ffff88806b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 000000002accd000 CR4: 0000000000350ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x87/0x1c0 mm/slab_common.c:1164 __do_kmalloc_node mm/slab_common.c:1011 [inline] __kmalloc.cold+0xb/0xe0 mm/slab_common.c:1036 kmalloc_array include/linux/slab.h:636 [inline] drm_syncobj_array_find+0x35/0x3c0 drivers/gpu/drm/drm_syncobj.c:1246 drm_syncobj_timeline_signal_ioctl+0x21f/0x860 drivers/gpu/drm/drm_syncobj.c:1533 drm_ioctl_kernel+0x280/0x4c0 drivers/gpu/drm/drm_ioctl.c:789 drm_ioctl+0x5cb/0xbf0 drivers/gpu/drm/drm_ioctl.c:892 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl fs/ioctl.c:857 [inline] __x64_sys_ioctl+0x18f/0x210 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ff62d53f129 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe7c669ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe7c66a078 RCX: 00007ff62d53f129 RDX: 0000000020000500 RSI: 00000000c01864cd RDI: 0000000000000003 RBP: 00007ff62d5b2610 R08: 0023647261632f69 R09: 00007ffe7c66a078 R10: 000000000000001f R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffe7c66a068 R14: 0000000000000001 R15: 0000000000000001 </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. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

2 years, 3 months

1
0
0 0

[PATCH v2 0/2] doc: uapi: Document dma-buf interop design & semantics

by Daniel Stone

Hi all, This is v2 to the linked patch series; thanks to everyone for reviewing the initial version. I've moved this out of a pure DRM scope and into the general userspace-API design section. Hopefully it helps others and answers a bunch of questions. I think it'd be great to have input/links/reflections from other subsystems as well here. Cheers, Daniel

2 years, 3 months

4
3
0 0

[PATCH v2] dma-buf/sw_sync: Avoid recursive lock during fence signal

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> If a signal callback releases the sw_sync fence, that will trigger a deadlock as the timeline_fence_release recurses onto the fence->lock (used both for signaling and the the timeline tree). To avoid that, temporarily hold an extra reference to the signalled fences until after we drop the lock. (This is an alternative implementation of https://patchwork.kernel.org/patch/11664717/ which avoids some potential UAF issues with the original patch.) v2: Remove now obsolete comment, use list_move_tail() and list_del_init() Reported-by: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free") Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/dma-buf/sw_sync.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c index 63f0aeb66db6..f0a35277fd84 100644 --- a/drivers/dma-buf/sw_sync.c +++ b/drivers/dma-buf/sw_sync.c @@ -191,6 +191,7 @@ static const struct dma_fence_ops timeline_fence_ops = { */ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc) { + LIST_HEAD(signalled); struct sync_pt *pt, *next; trace_sync_timeline(obj); @@ -203,21 +204,20 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc) if (!timeline_fence_signaled(&pt->base)) break; - list_del_init(&pt->link); + dma_fence_get(&pt->base); + + list_move_tail(&pt->link, &signalled); rb_erase(&pt->node, &obj->pt_tree); - /* - * A signal callback may release the last reference to this - * fence, causing it to be freed. That operation has to be - * last to avoid a use after free inside this loop, and must - * be after we remove the fence from the timeline in order to - * prevent deadlocking on timeline->lock inside - * timeline_fence_release(). - */ dma_fence_signal_locked(&pt->base); } spin_unlock_irq(&obj->lock); + + list_for_each_entry_safe(pt, next, &signalled, link) { + list_del_init(&pt->link); + dma_fence_put(&pt->base); + } } /** -- 2.41.0

2 years, 3 months

3
3
0 0

[BUG] KCSAN: data-race in drm_sched_entity_is_ready [gpu_sched] / drm_sched_entity_push_job [gpu_sched]

by Mirsad Todorovac

Hi, This is your friendly bug reporter. The environment is vanilla torvalds tree kernel on Ubuntu 22.04 LTS and a Ryzen 7950X box. Please find attached the complete dmesg output from the ring buffer and lshw output. NOTE: The kernel reports tainted kernel, but to my knowledge there are no proprietary (G) modules, but this taint is turned on by the previous bugs. dmesg excerpt: [ 8791.864576] ================================================================== [ 8791.864648] BUG: KCSAN: data-race in drm_sched_entity_is_ready [gpu_sched] / drm_sched_entity_push_job [gpu_sched] [ 8791.864776] write (marked) to 0xffff9b74491b7c40 of 8 bytes by task 3807 on cpu 18: [ 8791.864788] drm_sched_entity_push_job+0xf4/0x2a0 [gpu_sched] [ 8791.864852] amdgpu_cs_ioctl+0x3888/0x3de0 [amdgpu] [ 8791.868731] drm_ioctl_kernel+0x127/0x210 [drm] [ 8791.869222] drm_ioctl+0x38f/0x6f0 [drm] [ 8791.869711] amdgpu_drm_ioctl+0x7e/0xe0 [amdgpu] [ 8791.873660] __x64_sys_ioctl+0xd2/0x120 [ 8791.873676] do_syscall_64+0x58/0x90 [ 8791.873688] entry_SYSCALL_64_after_hwframe+0x73/0xdd [ 8791.873710] read to 0xffff9b74491b7c40 of 8 bytes by task 1119 on cpu 27: [ 8791.873722] drm_sched_entity_is_ready+0x16/0x50 [gpu_sched] [ 8791.873786] drm_sched_select_entity+0x1c7/0x220 [gpu_sched] [ 8791.873849] drm_sched_main+0xd2/0x500 [gpu_sched] [ 8791.873912] kthread+0x18b/0x1d0 [ 8791.873924] ret_from_fork+0x43/0x70 [ 8791.873939] ret_from_fork_asm+0x1b/0x30 [ 8791.873955] value changed: 0x0000000000000000 -> 0xffff9b750ebcfc00 [ 8791.873971] Reported by Kernel Concurrency Sanitizer on: [ 8791.873980] CPU: 27 PID: 1119 Comm: gfx_0.0.0 Tainted: G L 6.5.0-rc6-net-cfg-kcsan-00038-g16931859a650 #35 [ 8791.873994] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023 [ 8791.874002] ================================================================== Best regards, Mirsad Todorovac

2 years, 3 months

3
7
0 0

[QUESTION] drm/crtc: precondition for drm_crtc_init_with_planes()

by e.orlova＠ispras.ru

Documentation for drm_crtc_init_with_planes() in drivers/gpu/drm/drm_crtc.c states: «The crtc structure should not be allocated with devm_kzalloc()». However, in drivers/gpu/drm/stm/ltdc.c the 2nd argument of the function drm_crtc_init_with_planes() is a structure allocated with devm_kzalloc() Also, in drivers/gpu/drm/mediatek/mtk_drm_crtc.c drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c drivers/gpu/drm/logicvc/logicvc_crtc.c drivers/gpu/drm/meson/meson_crtc.c drivers/gpu/drm/mxsfb/lcdif_kms.c drivers/gpu/drm/mxsfb/mxsfb_kms.c drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c drivers/gpu/drm/rockchip/rockchip_drm_vop.c drivers/gpu/drm/rockchip/rockchip_drm_vop2.c drivers/gpu/drm/sun4i/sun4i_crtc.c drivers/gpu/drm/tegra/dc.c drivers/gpu/drm/tilcdc/tilcdc_crtc.c the 2nd argument of the function drm_crtc_init_with_planes() is a field of the structure allocated with devm_kzalloc() Is it correct or can it lead to any problems? -- Ekaterina Orlova Linux Verification Center, ISPRAS

2 years, 3 months

2
1
0 0

[PATCH (set 1) 00/20] Rid W=1 warnings from GPU

by Lee Jones

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: amd-gfx(a)lists.freedesktop.org Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Danilo Krummrich <dakr(a)redhat.com> Cc: David Airlie <airlied(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Gourav Samaiya <gsamaiya(a)nvidia.com> Cc: Hawking Zhang <Hawking.Zhang(a)amd.com> Cc: Hyun Kwon <hyun.kwon(a)xilinx.com> Cc: Jerome Glisse <glisse(a)freedesktop.org> Cc: Jonathan Hunter <jonathanh(a)nvidia.com> Cc: Karol Herbst <kherbst(a)redhat.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-media(a)vger.kernel.org Cc: linux-tegra(a)vger.kernel.org Cc: Luben Tuikov <luben.tuikov(a)amd.com> Cc: Lyude Paul <lyude(a)redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: "Maíra Canal" <mairacanal(a)riseup.net> Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Michal Simek <michal.simek(a)xilinx.com> Cc: Mikko Perttunen <mperttunen(a)nvidia.com> Cc: nouveau(a)lists.freedesktop.org Cc: NXP Linux Team <linux-imx(a)nxp.com> Cc: "Pan, Xinhui" <Xinhui.Pan(a)amd.com> Cc: Pengutronix Kernel Team <kernel(a)pengutronix.de> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Shashank Sharma <shashank.sharma(a)amd.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Stanley Yang <Stanley.Yang(a)amd.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Lee Jones (20): drm/xlnx/zynqmp_disp: Use correct kerneldoc formatting in zynqmp_disp drm/nouveau/nvkm/subdev/acr/lsfw: Remove unused variable 'loc' drm/nouveau/nvkm/subdev/bios/init: Demote a bunch of kernel-doc abuses drm/nouveau/nvkm/subdev/volt/gk20a: Demote kerneldoc abuses drm/nouveau/nvkm/engine/gr/gf100: Demote kerneldoc abuse drm/nouveau/dispnv04/crtc: Demote kerneldoc abuses drm/radeon/radeon_ttm: Remove unused variable 'rbo' from radeon_bo_move() drm/amd/amdgpu/sdma_v6_0: Demote a bunch of half-completed function headers drm/tests/drm_kunit_helpers: Place correct function name in the comment header drm/scheduler/sched_main: Provide short description of missing param 'result' drm/amd/amdgpu/amdgpu_doorbell_mgr: Correct misdocumented param 'doorbell_index' drm/amd/amdgpu/amdgpu_device: Provide suitable description for param 'xcc_id' drm/tests/drm_kunit_helpers: Correct possible double-entry typo in 'ddrm_kunit_helper_acquire_ctx_alloc' drm/imx/ipuv3/imx-ldb: Increase buffer size to ensure all possible values can be stored drm/tegra/hub: Increase buffer size to ensure all possible values can be stored drm/drm_connector: Provide short description of param 'supported_colorspaces' drm/amd/amdgpu/amdgpu_ras: Increase buffer size to account for all possible values drm/drm_gpuva_mgr: Remove set but unused variable 'prev' drm/amd/amdgpu/amdgpu_sdma: Increase buffer size to account for all possible values drm/amd/amdgpu/imu_v11_0: Increase buffer size to ensure all possible values can be stored drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + .../gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 2 +- drivers/gpu/drm/amd/amdgpu/imu_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 8 +- drivers/gpu/drm/drm_connector.c | 2 + drivers/gpu/drm/drm_gpuva_mgr.c | 10 +- drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c | 3 +- .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 136 +++++++++--------- .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 - drivers/gpu/drm/scheduler/sched_main.c | 1 + drivers/gpu/drm/tegra/hub.c | 2 +- drivers/gpu/drm/tests/drm_kunit_helpers.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +- 19 files changed, 96 insertions(+), 97 deletions(-) -- 2.42.0.rc1.204.g551eb34607-goog

2 years, 3 months

8
17
0 0

[PATCH] dma-buf/heaps: map CMA all pages for user

by Hsia-Jun Li

Page fault would raise a CPU interrupt, it is not a good idea. Signed-off-by: Hsia-Jun(Randy) Li <randy.li(a)synaptics.com> --- drivers/dma-buf/heaps/cma_heap.c | 26 +++----------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index ee899f8e6721..7d0b15ad21a7 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -160,35 +160,15 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, return 0; } -static vm_fault_t cma_heap_vm_fault(struct vm_fault *vmf) -{ - struct vm_area_struct *vma = vmf->vma; - struct cma_heap_buffer *buffer = vma->vm_private_data; - - if (vmf->pgoff > buffer->pagecount) - return VM_FAULT_SIGBUS; - - vmf->page = buffer->pages[vmf->pgoff]; - get_page(vmf->page); - - return 0; -} - -static const struct vm_operations_struct dma_heap_vm_ops = { - .fault = cma_heap_vm_fault, -}; - static int cma_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) { struct cma_heap_buffer *buffer = dmabuf->priv; - if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0) return -EINVAL; - vma->vm_ops = &dma_heap_vm_ops; - vma->vm_private_data = buffer; - - return 0; + return remap_pfn_range(vma, vma->vm_start, + page_to_pfn(buffer->pages[vma->vm_pgoff]), + vma->vm_end - vma->vm_start, vma->vm_page_prot); } static void *cma_heap_do_vmap(struct cma_heap_buffer *buffer) -- 2.17.1

2 years, 3 months

1
0
0 0

[PATCH] dma-buf/sw_sync: Avoid recursive lock during fence signal

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> If a signal callback releases the sw_sync fence, that will trigger a deadlock as the timeline_fence_release recurses onto the fence->lock (used both for signaling and the the timeline tree). To avoid that, temporarily hold an extra reference to the signalled fences until after we drop the lock. (This is an alternative implementation of https://patchwork.kernel.org/patch/11664717/ which avoids some potential UAF issues with the original patch.) Reported-by: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free") Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/dma-buf/sw_sync.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c index 63f0aeb66db6..ceb6a0408624 100644 --- a/drivers/dma-buf/sw_sync.c +++ b/drivers/dma-buf/sw_sync.c @@ -191,6 +191,7 @@ static const struct dma_fence_ops timeline_fence_ops = { */ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc) { + LIST_HEAD(signalled); struct sync_pt *pt, *next; trace_sync_timeline(obj); @@ -203,9 +204,13 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc) if (!timeline_fence_signaled(&pt->base)) break; + dma_fence_get(&pt->base); + list_del_init(&pt->link); rb_erase(&pt->node, &obj->pt_tree); + list_add_tail(&pt->link, &signalled); + /* * A signal callback may release the last reference to this * fence, causing it to be freed. That operation has to be @@ -218,6 +223,11 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc) } spin_unlock_irq(&obj->lock); + + list_for_each_entry_safe(pt, next, &signalled, link) { + list_del(&pt->link); + dma_fence_put(&pt->base); + } } /** -- 2.41.0

2 years, 4 months

2
2
0 0

[PATCH -next] drm/scheduler: Remove unused declarations

by Yue Haibing

Commit 06a2d7cc3f04 ("drm/amdgpu: revert "implement tdr advanced mode"") removed drm_sched_reset_karma()/drm_sched_increase_karma_ext() but leave the declarations. Commit 2cf9886e2816 ("drm/scheduler: remove drm_sched_dependency_optimized") removed drm_sched_dependency_optimized() but not its declaration. Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> --- include/drm/gpu_scheduler.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h index f9544d9b670d..cd8ac90865fc 100644 --- a/include/drm/gpu_scheduler.h +++ b/include/drm/gpu_scheduler.h @@ -554,10 +554,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad); void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery); void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched); void drm_sched_increase_karma(struct drm_sched_job *bad); -void drm_sched_reset_karma(struct drm_sched_job *bad); -void drm_sched_increase_karma_ext(struct drm_sched_job *bad, int type); -bool drm_sched_dependency_optimized(struct dma_fence* fence, - struct drm_sched_entity *entity); void drm_sched_fault(struct drm_gpu_scheduler *sched); void drm_sched_rq_add_entity(struct drm_sched_rq *rq, -- 2.34.1

2 years, 4 months

1
0
0 0

[PATCH v3] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

by Andrew Davis

This new export type exposes to userspace the SRAM area as a DMA-BUF Heap, this allows for allocations of DMA-BUFs that can be consumed by various DMA-BUF supporting devices. Signed-off-by: Andrew Davis <afd(a)ti.com> --- Changes from v2: - Make sram_dma_heap_allocate static (kernel test robot) - Rebase on v6.5-rc1 drivers/misc/Kconfig | 7 + drivers/misc/Makefile | 1 + drivers/misc/sram-dma-heap.c | 245 +++++++++++++++++++++++++++++++++++ drivers/misc/sram.c | 6 + drivers/misc/sram.h | 16 +++ 5 files changed, 275 insertions(+) create mode 100644 drivers/misc/sram-dma-heap.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 75e427f124b28..ee34dfb61605f 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -448,6 +448,13 @@ config SRAM config SRAM_EXEC bool +config SRAM_DMA_HEAP + bool "Export on-chip SRAM pools using DMA-Heaps" + depends on DMABUF_HEAPS && SRAM + help + This driver allows the export of on-chip SRAM marked as both pool + and exportable to userspace using the DMA-Heaps interface. + config DW_XDATA_PCIE depends on PCI tristate "Synopsys DesignWare xData PCIe driver" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index f2a4d1ff65d46..5e7516bfaa8de 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -47,6 +47,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o obj-$(CONFIG_SRAM) += sram.o obj-$(CONFIG_SRAM_EXEC) += sram-exec.o +obj-$(CONFIG_SRAM_DMA_HEAP) += sram-dma-heap.o obj-$(CONFIG_GENWQE) += genwqe/ obj-$(CONFIG_ECHO) += echo/ obj-$(CONFIG_CXL_BASE) += cxl/ diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c new file mode 100644 index 0000000000000..c054c04dff33e --- /dev/null +++ b/drivers/misc/sram-dma-heap.c @@ -0,0 +1,245 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * SRAM DMA-Heap userspace exporter + * + * Copyright (C) 2019-2022 Texas Instruments Incorporated - https://www.ti.com/ + * Andrew Davis <afd(a)ti.com> + */ + +#include <linux/dma-mapping.h> +#include <linux/err.h> +#include <linux/genalloc.h> +#include <linux/io.h> +#include <linux/mm.h> +#include <linux/scatterlist.h> +#include <linux/slab.h> +#include <linux/dma-buf.h> +#include <linux/dma-heap.h> + +#include "sram.h" + +struct sram_dma_heap { + struct dma_heap *heap; + struct gen_pool *pool; +}; + +struct sram_dma_heap_buffer { + struct gen_pool *pool; + struct list_head attachments; + struct mutex attachments_lock; + unsigned long len; + void *vaddr; + phys_addr_t paddr; +}; + +struct dma_heap_attachment { + struct device *dev; + struct sg_table *table; + struct list_head list; +}; + +static int dma_heap_attach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct sram_dma_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a; + struct sg_table *table; + + a = kzalloc(sizeof(*a), GFP_KERNEL); + if (!a) + return -ENOMEM; + + table = kmalloc(sizeof(*table), GFP_KERNEL); + if (!table) { + kfree(a); + return -ENOMEM; + } + if (sg_alloc_table(table, 1, GFP_KERNEL)) { + kfree(table); + kfree(a); + return -ENOMEM; + } + sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)), buffer->len, 0); + + a->table = table; + a->dev = attachment->dev; + INIT_LIST_HEAD(&a->list); + + attachment->priv = a; + + mutex_lock(&buffer->attachments_lock); + list_add(&a->list, &buffer->attachments); + mutex_unlock(&buffer->attachments_lock); + + return 0; +} + +static void dma_heap_detatch(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct sram_dma_heap_buffer *buffer = dmabuf->priv; + struct dma_heap_attachment *a = attachment->priv; + + mutex_lock(&buffer->attachments_lock); + list_del(&a->list); + mutex_unlock(&buffer->attachments_lock); + + sg_free_table(a->table); + kfree(a->table); + kfree(a); +} + +static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment *attachment, + enum dma_data_direction direction) +{ + struct dma_heap_attachment *a = attachment->priv; + struct sg_table *table = a->table; + + /* + * As this heap is backed by uncached SRAM memory we do not need to + * perform any sync operations on the buffer before allowing device + * domain access. For this reason we use SKIP_CPU_SYNC and also do + * not use or provide begin/end_cpu_access() dma-buf functions. + */ + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents, + direction, DMA_ATTR_SKIP_CPU_SYNC)) + return ERR_PTR(-ENOMEM); + + return table; +} + +static void dma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, + struct sg_table *table, + enum dma_data_direction direction) +{ + dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents, + direction, DMA_ATTR_SKIP_CPU_SYNC); +} + +static void dma_heap_dma_buf_release(struct dma_buf *dmabuf) +{ + struct sram_dma_heap_buffer *buffer = dmabuf->priv; + + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len); + kfree(buffer); +} + +static int dma_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) +{ + struct sram_dma_heap_buffer *buffer = dmabuf->priv; + int ret; + + /* SRAM mappings are not cached */ + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot); + + ret = vm_iomap_memory(vma, buffer->paddr, buffer->len); + if (ret) + pr_err("Could not map buffer to userspace\n"); + + return ret; +} + +static int dma_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + struct sram_dma_heap_buffer *buffer = dmabuf->priv; + + iosys_map_set_vaddr(map, buffer->vaddr); + + return 0; +} + +static const struct dma_buf_ops sram_dma_heap_buf_ops = { + .attach = dma_heap_attach, + .detach = dma_heap_detatch, + .map_dma_buf = dma_heap_map_dma_buf, + .unmap_dma_buf = dma_heap_unmap_dma_buf, + .release = dma_heap_dma_buf_release, + .mmap = dma_heap_mmap, + .vmap = dma_heap_vmap, +}; + +static struct dma_buf *sram_dma_heap_allocate(struct dma_heap *heap, + unsigned long len, + unsigned long fd_flags, + unsigned long heap_flags) +{ + struct sram_dma_heap *sram_dma_heap = dma_heap_get_drvdata(heap); + struct sram_dma_heap_buffer *buffer; + + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + struct dma_buf *dmabuf; + int ret = 0; + + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL); + if (!buffer) + return ERR_PTR(-ENOMEM); + buffer->pool = sram_dma_heap->pool; + INIT_LIST_HEAD(&buffer->attachments); + mutex_init(&buffer->attachments_lock); + buffer->len = len; + + buffer->vaddr = (void *)gen_pool_alloc(buffer->pool, buffer->len); + if (!buffer->vaddr) { + ret = -ENOMEM; + goto free_buffer; + } + + buffer->paddr = gen_pool_virt_to_phys(buffer->pool, (unsigned long)buffer->vaddr); + if (buffer->paddr == -1) { + ret = -ENOMEM; + goto free_pool; + } + + /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); + exp_info.ops = &sram_dma_heap_buf_ops; + exp_info.size = buffer->len; + exp_info.flags = fd_flags; + exp_info.priv = buffer; + dmabuf = dma_buf_export(&exp_info); + if (IS_ERR(dmabuf)) { + ret = PTR_ERR(dmabuf); + goto free_pool; + } + + return dmabuf; + +free_pool: + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len); +free_buffer: + kfree(buffer); + + return ERR_PTR(ret); +} + +static struct dma_heap_ops sram_dma_heap_ops = { + .allocate = sram_dma_heap_allocate, +}; + +int sram_add_dma_heap(struct sram_dev *sram, + struct sram_reserve *block, + phys_addr_t start, + struct sram_partition *part) +{ + struct sram_dma_heap *sram_dma_heap; + struct dma_heap_export_info exp_info; + + dev_info(sram->dev, "Exporting SRAM Heap '%s'\n", block->label); + + sram_dma_heap = kzalloc(sizeof(*sram_dma_heap), GFP_KERNEL); + if (!sram_dma_heap) + return -ENOMEM; + sram_dma_heap->pool = part->pool; + + exp_info.name = kasprintf(GFP_KERNEL, "sram_%s", block->label); + exp_info.ops = &sram_dma_heap_ops; + exp_info.priv = sram_dma_heap; + sram_dma_heap->heap = dma_heap_add(&exp_info); + if (IS_ERR(sram_dma_heap->heap)) { + int ret = PTR_ERR(sram_dma_heap->heap); + kfree(sram_dma_heap); + return ret; + } + + return 0; +} diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c index 5757adf418b1d..6dd173a2fba8e 100644 --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -120,6 +120,12 @@ static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block, ret = sram_add_pool(sram, block, start, part); if (ret) return ret; + + if (block->export) { + ret = sram_add_dma_heap(sram, block, start, part); + if (ret) + return ret; + } } if (block->export) { ret = sram_add_export(sram, block, start, part); diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h index 397205b8bf6ff..062bdd25fa068 100644 --- a/drivers/misc/sram.h +++ b/drivers/misc/sram.h @@ -60,4 +60,20 @@ static inline int sram_add_protect_exec(struct sram_partition *part) return -ENODEV; } #endif /* CONFIG_SRAM_EXEC */ + +#ifdef CONFIG_SRAM_DMA_HEAP +int sram_add_dma_heap(struct sram_dev *sram, + struct sram_reserve *block, + phys_addr_t start, + struct sram_partition *part); +#else +static inline int sram_add_dma_heap(struct sram_dev *sram, + struct sram_reserve *block, + phys_addr_t start, + struct sram_partition *part) +{ + return 0; +} +#endif /* CONFIG_SRAM_DMA_HEAP */ + #endif /* __SRAM_H */ -- 2.39.2

2 years, 4 months

4
5
0 0

Re: [PATCH v2] dma-contiguous: define proper name for global cma region

by Christoph Hellwig

Hi Pintu, On Sat, Jul 29, 2023 at 08:05:15AM +0530, Pintu Kumar wrote: > The current global cma region name defined as "reserved" > which is misleading, creates confusion and too generic. > > Also, the default cma allocation happens from global cma region, > so, if one has to figure out all allocations happening from > global cma region, this seems easier. > > Thus, change the name from "reserved" to "global-cma-region". I agree that reserved is not a very useful name. Unfortuately the name of the region leaks to userspace through cma_heap. So I think we need prep patches to hardcode "reserved" in add_default_cma_heap first, and then remove the cma_get_name first.

2 years, 4 months

3
7
0 0

[PATCH] drm: manager: Remove the unused variable prev

by Jiapeng Chong

Variable prev is not effectively used, so delete it. drivers/gpu/drm/drm_gpuva_mgr.c:1079:32: warning: variable ‘prev’ set but not used. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gpuva_mgr.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c index f86bfad74ff8..afa5330445b3 100644 --- a/drivers/gpu/drm/drm_gpuva_mgr.c +++ b/drivers/gpu/drm/drm_gpuva_mgr.c @@ -1076,7 +1076,7 @@ __drm_gpuva_sm_map(struct drm_gpuva_manager *mgr, u64 req_addr, u64 req_range, struct drm_gem_object *req_obj, u64 req_offset) { - struct drm_gpuva *va, *next, *prev = NULL; + struct drm_gpuva *va, *next = NULL; u64 req_end = req_addr + req_range; int ret; @@ -1206,7 +1206,6 @@ __drm_gpuva_sm_map(struct drm_gpuva_manager *mgr, } } next: - prev = va; } return op_map_cb(ops, priv, -- 2.20.1.7.g153144c

2 years, 4 months

2
1
0 0

[PATCH AUTOSEL 6.4 1/7] drm/sched: Make sure we wait for all dependencies in kill_jobs_cb()

by Sasha Levin

From: Boris Brezillon <boris.brezillon(a)collabora.com> [ Upstream commit e30cb0599799aac099209e3b045379613c80730e ] drm_sched_entity_kill_jobs_cb() logic is omitting the last fence popped from the dependency array that was waited upon before drm_sched_entity_kill() was called (drm_sched_entity::dependency field), so we're basically waiting for all dependencies except one. In theory, this wait shouldn't be needed because resources should have their users registered to the dma_resv object, thus guaranteeing that future jobs wanting to access these resources wait on all the previous users (depending on the access type, of course). But we want to keep these explicit waits in the kill entity path just in case. Let's make sure we keep all dependencies in the array in drm_sched_job_dependency(), so we can iterate over the array and wait in drm_sched_entity_kill_jobs_cb(). We also make sure we wait on drm_sched_fence::finished if we were originally asked to wait on drm_sched_fence::scheduled. In that case, we assume the intent was to delegate the wait to the firmware/GPU or rely on the pipelining done at the entity/scheduler level, but when killing jobs, we really want to wait for completion not just scheduling. v2: - Don't evict deps in drm_sched_job_dependency() v3: - Always wait for drm_sched_fence::finished fences in drm_sched_entity_kill_jobs_cb() when we see a sched_fence v4: - Fix commit message - Fix a use-after-free bug v5: - Flag deps on which we should only wait for the scheduled event at insertion time v6: - Back to v4 implementation - Add Christian's R-b Cc: Frank Binns <frank.binns(a)imgtec.com> Cc: Sarah Walker <sarah.walker(a)imgtec.com> Cc: Donald Robson <donald.robson(a)imgtec.com> Cc: Luben Tuikov <luben.tuikov(a)amd.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> Suggested-by: "Christian König" <christian.koenig(a)amd.com> Reviewed-by: "Christian König" <christian.koenig(a)amd.com> Acked-by: Luben Tuikov <luben.tuikov(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230619071921.3465992-1-bori… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/scheduler/sched_entity.c | 41 +++++++++++++++++++----- 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index e0a8890a62e23..42021d1f7e016 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -155,16 +155,32 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f, { struct drm_sched_job *job = container_of(cb, struct drm_sched_job, finish_cb); - int r; + unsigned long index; dma_fence_put(f); /* Wait for all dependencies to avoid data corruptions */ - while (!xa_empty(&job->dependencies)) { - f = xa_erase(&job->dependencies, job->last_dependency++); - r = dma_fence_add_callback(f, &job->finish_cb, - drm_sched_entity_kill_jobs_cb); - if (!r) + xa_for_each(&job->dependencies, index, f) { + struct drm_sched_fence *s_fence = to_drm_sched_fence(f); + + if (s_fence && f == &s_fence->scheduled) { + /* The dependencies array had a reference on the scheduled + * fence, and the finished fence refcount might have + * dropped to zero. Use dma_fence_get_rcu() so we get + * a NULL fence in that case. + */ + f = dma_fence_get_rcu(&s_fence->finished); + + /* Now that we have a reference on the finished fence, + * we can release the reference the dependencies array + * had on the scheduled fence. + */ + dma_fence_put(&s_fence->scheduled); + } + + xa_erase(&job->dependencies, index); + if (f && !dma_fence_add_callback(f, &job->finish_cb, + drm_sched_entity_kill_jobs_cb)) return; dma_fence_put(f); @@ -394,8 +410,17 @@ static struct dma_fence * drm_sched_job_dependency(struct drm_sched_job *job, struct drm_sched_entity *entity) { - if (!xa_empty(&job->dependencies)) - return xa_erase(&job->dependencies, job->last_dependency++); + struct dma_fence *f; + + /* We keep the fence around, so we can iterate over all dependencies + * in drm_sched_entity_kill_jobs_cb() to ensure all deps are signaled + * before killing the job. + */ + f = xa_load(&job->dependencies, job->last_dependency); + if (f) { + job->last_dependency++; + return dma_fence_get(f); + } if (job->sched->ops->prepare_job) return job->sched->ops->prepare_job(job, entity); -- 2.40.1

2 years, 4 months

1
0
0 0

[RFC PATCH 00/10] Device Memory TCP

by Mina Almasry

* TL;DR: Device memory TCP (devmem TCP) is a proposal for transferring data to and/or from device memory efficiently, without bouncing the data to a host memory buffer. * Problem: A large amount of data transfers have device memory as the source and/or destination. Accelerators drastically increased the volume of such transfers. Some examples include: - ML accelerators transferring large amounts of training data from storage into GPU/TPU memory. In some cases ML training setup time can be as long as 50% of TPU compute time, improving data transfer throughput & efficiency can help improving GPU/TPU utilization. - Distributed training, where ML accelerators, such as GPUs on different hosts, exchange data among them. - Distributed raw block storage applications transfer large amounts of data with remote SSDs, much of this data does not require host processing. Today, the majority of the Device-to-Device data transfers the network are implemented as the following low level operations: Device-to-Host copy, Host-to-Host network transfer, and Host-to-Device copy. The implementation is suboptimal, especially for bulk data transfers, and can put significant strains on system resources, such as host memory bandwidth, PCIe bandwidth, etc. One important reason behind the current state is the kernel’s lack of semantics to express device to network transfers. * Proposal: In this patch series we attempt to optimize this use case by implementing socket APIs that enable the user to: 1. send device memory across the network directly, and 2. receive incoming network packets directly into device memory. Packet _payloads_ go directly from the NIC to device memory for receive and from device memory to NIC for transmit. Packet _headers_ go to/from host memory and are processed by the TCP/IP stack normally. The NIC _must_ support header split to achieve this. Advantages: - Alleviate host memory bandwidth pressure, compared to existing network-transfer + device-copy semantics. - Alleviate PCIe BW pressure, by limiting data transfer to the lowest level of the PCIe tree, compared to traditional path which sends data through the root complex. With this proposal we're able to reach ~96.6% line rate speeds with data sent and received directly from/to device memory. * Patch overview: ** Part 1: struct paged device memory Currently the standard for device memory sharing is DMABUF, which doesn't generate struct pages. On the other hand, networking stack (skbs, drivers, and page pool) operate on pages. We have 2 options: 1. Generate struct pages for dmabuf device memory, or, 2. Modify the networking stack to understand a new memory type. This proposal implements option #1. We implement a small framework to generate struct pages for an sg_table returned from dma_buf_map_attachment(). The support added here should be generic and easily extended to other use cases interested in struct paged device memory. We use this framework to generate pages that can be used in the networking stack. ** Part 2: recvmsg() & sendmsg() APIs We define user APIs for the user to send and receive these dmabuf pages. ** part 3: support for unreadable skb frags Dmabuf pages are not accessible by the host; we implement changes throughput the networking stack to correctly handle skbs with unreadable frags. ** part 4: page pool support We piggy back on Jakub's page pool memory providers idea: https://github.com/kuba-moo/linux/tree/pp-providers It allows the page pool to define a memory provider that provides the page allocation and freeing. It helps abstract most of the device memory TCP changes from the driver. This is not strictly necessary, the driver can choose to allocate dmabuf pages and use them directly without going through the page pool (if acceptable to their maintainers). Not included with this RFC is the GVE devmem TCP support, just to simplify the review. Code available here if desired: https://github.com/mina/linux/tree/tcpdevmem This RFC is built on top of v6.4-rc7 with Jakub's pp-providers changes cherry-picked. * NIC dependencies: 1. (strict) Devmem TCP require the NIC to support header split, i.e. the capability to split incoming packets into a header + payload and to put each into a separate buffer. Devmem TCP works by using dmabuf pages for the packet payload, and host memory for the packet headers. 2. (optional) Devmem TCP works better with flow steering support & RSS support, i.e. the NIC's ability to steer flows into certain rx queues. This allows the sysadmin to enable devmem TCP on a subset of the rx queues, and steer devmem TCP traffic onto these queues and non devmem TCP elsewhere. The NIC I have access to with these properties is the GVE with DQO support running in Google Cloud, but any NIC that supports these features would suffice. I may be able to help reviewers bring up devmem TCP on their NICs. * Testing: The series includes a udmabuf kselftest that show a simple use case of devmem TCP and validates the entire data path end to end without a dependency on a specific dmabuf provider. Not included in this series is our devmem TCP benchmark, which transfers data to/from GPU dmabufs directly. With this implementation & benchmark we're able to reach ~96.6% line rate speeds with 4 GPU/NIC pairs running bi-direction traffic, with all the packet payloads going straight to the GPU memory (no host buffer bounce). ** Test Setup Kernel: v6.4-rc7, with this RFC and Jakub's memory provider API cherry-picked locally. Hardware: Google Cloud A3 VMs. NIC: GVE with header split & RSS & flow steering support. Benchmark: custom devmem TCP benchmark not yet open sourced. Mina Almasry (10): dma-buf: add support for paged attachment mappings dma-buf: add support for NET_RX pages dma-buf: add support for NET_TX pages net: add support for skbs with unreadable frags tcp: implement recvmsg() RX path for devmem TCP net: add SO_DEVMEM_DONTNEED setsockopt to release RX pages tcp: implement sendmsg() TX path for for devmem tcp selftests: add ncdevmem, netcat for devmem TCP memory-provider: updates core provider API for devmem TCP memory-provider: add dmabuf devmem provider drivers/dma-buf/dma-buf.c | 444 ++++++++++++++++ include/linux/dma-buf.h | 142 +++++ include/linux/netdevice.h | 1 + include/linux/skbuff.h | 34 +- include/linux/socket.h | 1 + include/net/page_pool.h | 21 + include/net/sock.h | 4 + include/net/tcp.h | 6 +- include/uapi/asm-generic/socket.h | 6 + include/uapi/linux/dma-buf.h | 12 + include/uapi/linux/uio.h | 10 + net/core/datagram.c | 3 + net/core/page_pool.c | 111 +++- net/core/skbuff.c | 81 ++- net/core/sock.c | 47 ++ net/ipv4/tcp.c | 262 +++++++++- net/ipv4/tcp_input.c | 13 +- net/ipv4/tcp_ipv4.c | 8 + net/ipv4/tcp_output.c | 5 +- net/packet/af_packet.c | 4 +- tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/net/ncdevmem.c | 693 +++++++++++++++++++++++++ 23 files changed, 1868 insertions(+), 42 deletions(-) create mode 100644 tools/testing/selftests/net/ncdevmem.c -- 2.41.0.390.g38632f3daf-goog

2 years, 4 months

8
29
0 0

[PATCH v2] dma-buf: Fix the typo in DMA-BUF statistics doc

by Luc Ma

From: Luc Ma <luc(a)sietium.com> The kernel-doc for DMA-BUF statistics mentions /sys/kernel/dma-buf/buffers but the correct path is /sys/kernel/dmabuf/buffers instead. Signed-off-by: Luc Ma <luc(a)sietium.com> Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> --- drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 6cfbbf0720bd..b5b62e40ccc1 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -33,7 +33,7 @@ * into their address space. This necessitated the creation of the DMA-BUF sysfs * statistics interface to provide per-buffer information on production systems. * - * The interface at ``/sys/kernel/dma-buf/buffers`` exposes information about + * The interface at ``/sys/kernel/dmabuf/buffers`` exposes information about * every DMA-BUF when ``CONFIG_DMABUF_SYSFS_STATS`` is enabled. * * The following stats are exposed by the interface: -- 2.25.1

2 years, 4 months

2
1
0 0

[PATCH v2] scsi: lpfc: Fix potential deadlock on &ndlp->lock

by Chengfeng Ye

As &ndlp->lock is acquired by timer lpfc_els_retry_delay() under softirq context, process context code acquiring the lock &ndlp->lock should disable irq or bh, otherwise deadlock could happen if the timer preempt the execution while the lock is held in process context on the same CPU. The two lock acquisition inside lpfc_cleanup_pending_mbox() does not disable irq or softirq. [Deadlock Scenario] lpfc_cmpl_els_fdisc() -> lpfc_cleanup_pending_mbox() -> spin_lock(&ndlp->lock); <irq> -> lpfc_els_retry_delay() -> lpfc_nlp_get() -> spin_lock_irqsave(&ndlp->lock, flags); (deadlock here) This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. The patch fix the potential deadlock by spin_lock_irq() to disable irq. Signed-off-by: Chengfeng Ye <dg573847474(a)gmail.com> --- drivers/scsi/lpfc/lpfc_sli.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 58d10f8f75a7..8555f6bb9742 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -21049,9 +21049,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) mb->mbox_flag |= LPFC_MBX_IMED_UNREG; restart_loop = 1; spin_unlock_irq(&phba->hbalock); - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); spin_lock_irq(&phba->hbalock); break; } @@ -21067,9 +21067,9 @@ lpfc_cleanup_pending_mbox(struct lpfc_vport *vport) ndlp = (struct lpfc_nodelist *)mb->ctx_ndlp; mb->ctx_ndlp = NULL; if (ndlp) { - spin_lock(&ndlp->lock); + spin_lock_irq(&ndlp->lock); ndlp->nlp_flag &= ~NLP_IGNR_REG_CMPL; - spin_unlock(&ndlp->lock); + spin_unlock_irq(&ndlp->lock); lpfc_nlp_put(ndlp); } } -- 2.17.1

2 years, 4 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig