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

Re: [PATCH v3,03/21] v4l2: verify secure dmabufs are used in secure queue

by Jeffrey Kardatzke

On Mon, Dec 11, 2023 at 2:58 AM Hans Verkuil <hverkuil-cisco(a)xs4all.nl> wrote: > > On 06/12/2023 09:15, Yunfei Dong wrote: > > From: Jeffrey Kardatzke <jkardatzke(a)google.com> > > > > Verfies in the dmabuf implementations that if the secure memory flag is > > Verfies -> Verifies Thanks. Yunfei, change that please. > > > set for a queue that the dmabuf submitted to the queue is unmappable. > > > > Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> > > Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> > > --- > > drivers/media/common/videobuf2/videobuf2-dma-contig.c | 6 ++++++ > > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 6 ++++++ > > 2 files changed, 12 insertions(+) > > > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > > index 3d4fd4ef5310..ad58ef8dc231 100644 > > --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > > +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > > @@ -710,6 +710,12 @@ static int vb2_dc_map_dmabuf(void *mem_priv) > > return -EINVAL; > > } > > > > + /* verify the dmabuf is secure if we are in secure mode */ > > + if (buf->vb->vb2_queue->secure_mem && sg_page(sgt->sgl)) { > > This needs a bit more explanation. I guess that for secure memory > sg_page returns NULL? How about if we change it to: /* verify the dmabuf is secure if we are in secure mode, this is done by validating there is no page entry for the dmabuf */ > > > + pr_err("secure queue requires secure dma_buf"); > > + return -EINVAL; > > + } > > + > > /* checking if dmabuf is big enough to store contiguous chunk */ > > contig_size = vb2_dc_get_contiguous_size(sgt); > > if (contig_size < buf->size) { > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > index 28f3fdfe23a2..55428c73c380 100644 > > --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c > > @@ -564,6 +564,12 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv) > > return -EINVAL; > > } > > > > + /* verify the dmabuf is secure if we are in secure mode */ > > + if (buf->vb->vb2_queue->secure_mem && !sg_dma_secure(sgt->sgl)) { > > I can't find the sg_dma_secure function. I suspect this patch series > depends on another series? That was an oversight, it should be the same as in videobuf2-dma-contig.c. Yunfei, can you change this to match what's in videobuf2-dma-contig.c after the comment is reworded? > > > + pr_err("secure queue requires secure dma_buf"); > > + return -EINVAL; > > + } > > + > > buf->dma_sgt = sgt; > > buf->vaddr = NULL; > > > > Regards, > > Hans

2 years, 1 month

1
0
0 0

Re: [PATCH v3,04/21] v4l: add documentation for secure memory flag

by Jeffrey Kardatzke

On Mon, Dec 11, 2023 at 3:05 AM Hans Verkuil <hverkuil-cisco(a)xs4all.nl> wrote: > > On 06/12/2023 09:15, Yunfei Dong wrote: > > From: Jeffrey Kardatzke <jkardatzke(a)google.com> > > > > Adds documentation for V4L2_MEMORY_FLAG_SECURE. > > > > Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> > > Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> > > --- > > Documentation/userspace-api/media/v4l/buffer.rst | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst > > index 52bbee81c080..a5a7d1c72d53 100644 > > --- a/Documentation/userspace-api/media/v4l/buffer.rst > > +++ b/Documentation/userspace-api/media/v4l/buffer.rst > > @@ -696,7 +696,7 @@ enum v4l2_memory > > > > .. _memory-flags: > > > > -Memory Consistency Flags > > +Memory Flags > > ------------------------ > > > > .. raw:: latex > > @@ -728,6 +728,12 @@ Memory Consistency Flags > > only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the > > queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS > > <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. > > + * .. _`V4L2-MEMORY-FLAG-SECURE`: > > + > > + - ``V4L2_MEMORY_FLAG_SECURE`` > > + - 0x00000002 > > + - DMA bufs passed into the queue will be validated to ensure they were > > + allocated from a secure dma-heap. > > Hmm, that needs a bit more work. How about: > > - The queued buffers are expected to be in secure memory. If not, an error will be > returned. This flag can only be used with ``V4L2_MEMORY_DMABUF``. Typically > secure buffers are allocated using a secure dma-heap. This flag can only be > specified if the ``V4L2_BUF_CAP_SUPPORTS_SECURE_MEM`` is set. > Thanks Hans. Yunfei, can you integrate this change into the patch please? > In addition, the title of this table is currently "Memory Consistency Flags": that > should be renamed to "Memory Flags". Hans, the patch is already renaming the table as you suggested. :) (unless there's some other spot I'm missing) > > Regards, > > Hans > > > > > .. raw:: latex > > >

2 years, 1 month

1
0
0 0

Re: [PATCH v3,02/21] v4l2: handle secure memory flags in queue setup

by Jeffrey Kardatzke

Yunfei, Can you please integrate these changes into the patch? Thanks, Jeff On Mon, Dec 11, 2023 at 2:45 AM Hans Verkuil <hverkuil-cisco(a)xs4all.nl> wrote: > > Hi Yunfei, Jeffrey, > > Some comments below: > > On 06/12/2023 09:15, Yunfei Dong wrote: > > From: Jeffrey Kardatzke <jkardatzke(a)google.com> > > > > Validates the secure memory flags when setting up a queue and ensures > > the queue has the proper capability. > > > > Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> > > Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> > > --- > > .../media/common/videobuf2/videobuf2-core.c | 23 +++++++++++++ > > .../media/common/videobuf2/videobuf2-v4l2.c | 34 +++++++++++++------ > > 2 files changed, 46 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c > > index 8c1df829745b..09dc030484be 100644 > > --- a/drivers/media/common/videobuf2/videobuf2-core.c > > +++ b/drivers/media/common/videobuf2/videobuf2-core.c > > @@ -813,6 +813,15 @@ static bool verify_coherency_flags(struct vb2_queue *q, bool non_coherent_mem) > > return true; > > } > > > > +static bool verify_secure_mem_flags(struct vb2_queue *q, bool secure_mem) > > +{ > > + if (secure_mem != q->secure_mem) { > > + dprintk(q, 1, "secure memory model mismatch\n"); > > + return false; > > + } > > + return true; > > +} > > + > > int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > unsigned int flags, unsigned int *count) > > { > > @@ -820,6 +829,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > unsigned int q_num_bufs = vb2_get_num_buffers(q); > > unsigned plane_sizes[VB2_MAX_PLANES] = { }; > > bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT; > > + bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE; > > unsigned int i; > > int ret = 0; > > > > @@ -836,6 +846,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > if (*count == 0 || q_num_bufs != 0 || > > (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory) || > > !verify_coherency_flags(q, non_coherent_mem)) { > > + bool no_previous_buffers = !q->num_buffers; > > + > > /* > > * We already have buffers allocated, so first check if they > > * are not in use and can be freed. > > @@ -854,6 +866,12 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > __vb2_queue_free(q, q_num_bufs); > > mutex_unlock(&q->mmap_lock); > > > > + /* > > + * Do not allow switching secure buffer mode. > > + */ > > + if (!no_previous_buffers && !verify_secure_mem_flags(q, secure_mem)) > > + return -EINVAL; > > + > > Why is this needed? Here VIDIOC_REQBUFS is called either to just delete > all existing buffers (count == 0), or to delete all existing buffers and > allocate new buffers (count > 0). > > Since in both cases all existing buffers are deleted, you are free to choose > whatever new secure mode you want. > > > /* > > * In case of REQBUFS(0) return immediately without calling > > * driver's queue_setup() callback and allocating resources. > > @@ -882,6 +900,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory, > > if (ret) > > return ret; > > set_queue_coherency(q, non_coherent_mem); > > + q->secure_mem = secure_mem; > > > > /* > > * Ask the driver how many buffers and planes per buffer it requires. > > @@ -986,6 +1005,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory, > > unsigned plane_sizes[VB2_MAX_PLANES] = { }; > > bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT; > > unsigned int q_num_bufs = vb2_get_num_buffers(q); > > + bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE; > > bool no_previous_buffers = !q_num_bufs; > > int ret = 0; > > > > @@ -1015,6 +1035,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory, > > return ret; > > q->waiting_for_buffers = !q->is_output; > > set_queue_coherency(q, non_coherent_mem); > > + q->secure_mem = secure_mem; > > } else { > > if (q->memory != memory) { > > dprintk(q, 1, "memory model mismatch\n"); > > @@ -1022,6 +1043,8 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory, > > } > > if (!verify_coherency_flags(q, non_coherent_mem)) > > return -EINVAL; > > + if (!verify_secure_mem_flags(q, secure_mem)) > > + return -EINVAL; > > } > > > > num_buffers = min(*count, q->max_num_buffers - q_num_bufs); > > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c > > index 54d572c3b515..0a530830276c 100644 > > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c > > +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c > > @@ -686,22 +686,30 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps) > > *caps |= V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS; > > if (q->supports_requests) > > *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS; > > + if (q->allow_secure_mem && q->io_modes & VB2_DMABUF) > > + *caps |= V4L2_BUF_CAP_SUPPORTS_SECURE_MEM; > > } > > > > -static void validate_memory_flags(struct vb2_queue *q, > > +static bool validate_memory_flags(struct vb2_queue *q, > > int memory, > > u32 *flags) > > { > > + if (*flags & V4L2_MEMORY_FLAG_SECURE && > > + (!q->allow_secure_mem || memory != V4L2_MEMORY_DMABUF)) { > > + return false; > > + } > > + > > This check belongs to videobuf2-core.c and the check should be done > in vb2_core_reqbufs and vb2_core_create_bufs. > > So just leave this function as a void. > > > if (!q->allow_cache_hints || memory != V4L2_MEMORY_MMAP) { > > /* > > - * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only, > > - * but in order to avoid bugs we zero out all bits. > > + * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only. > > Just drop this as well since it adds no useful information anymore. > > > */ > > - *flags = 0; > > - } else { > > - /* Clear all unknown flags. */ > > - *flags &= V4L2_MEMORY_FLAG_NON_COHERENT; > > + *flags &= ~V4L2_MEMORY_FLAG_NON_COHERENT; > > } > > + > > + /* Clear all unknown flags. */ > > + *flags &= V4L2_MEMORY_FLAG_NON_COHERENT | V4L2_MEMORY_FLAG_SECURE; > > This is still needed here. > > > + > > + return true; > > } > > > > So the following changes from here... > > > int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) > > @@ -710,7 +718,8 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) > > u32 flags = req->flags; > > > > fill_buf_caps(q, &req->capabilities); > > - validate_memory_flags(q, req->memory, &flags); > > + if (!validate_memory_flags(q, req->memory, &flags)) > > + return -EINVAL; > > req->flags = flags; > > return ret ? ret : vb2_core_reqbufs(q, req->memory, > > req->flags, &req->count); > > @@ -752,7 +761,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create) > > unsigned i; > > > > fill_buf_caps(q, &create->capabilities); > > - validate_memory_flags(q, create->memory, &create->flags); > > + if (!validate_memory_flags(q, create->memory, &create->flags)) > > + return -EINVAL; > > create->index = vb2_get_num_buffers(q); > > create->max_num_buffers = q->max_num_buffers; > > create->capabilities |= V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS; > > @@ -1007,7 +1017,8 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv, > > u32 flags = p->flags; > > > > fill_buf_caps(vdev->queue, &p->capabilities); > > - validate_memory_flags(vdev->queue, p->memory, &flags); > > + if (!validate_memory_flags(vdev->queue, p->memory, &flags)) > > + return -EINVAL; > > p->flags = flags; > > if (res) > > return res; > > @@ -1031,7 +1042,8 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv, > > > > p->index = vdev->queue->num_buffers; > > fill_buf_caps(vdev->queue, &p->capabilities); > > - validate_memory_flags(vdev->queue, p->memory, &p->flags); > > + if (!validate_memory_flags(vdev->queue, p->memory, &p->flags)) > > + return -EINVAL; > > /* > > * If count == 0, then just check if memory and type are valid. > > * Any -EBUSY result from vb2_verify_memory_type can be mapped to 0. > > ...to the end should all be dropped since the vb2 core will do the checks. > > Regards, > > Hans

2 years, 1 month

1
0
0 0

Re: [syzbot] [dri?] WARNING in drm_prime_destroy_file_private (2)

by Christian König

Am 28.12.23 um 03:57 schrieb Qi Zheng: > > > On 2023/12/28 04:51, syzbot wrote: >> Hello, >> >> syzbot found the following issue on: >> >> HEAD commit: 5254c0cbc92d Merge tag 'block-6.7-2023-12-22' of >> git://git.. >> git tree: upstream >> console+strace: https://syzkaller.appspot.com/x/log.txt?x=10cc6995e80000 >> kernel config: >> https://syzkaller.appspot.com/x/.config?x=314e9ad033a7d3a7 >> dashboard link: >> https://syzkaller.appspot.com/bug?extid=59dcc2e7283a6f5f5ba1 >> 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=13e35809e80000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155d5fd6e80000 >> >> Downloadable assets: >> disk image: >> https://storage.googleapis.com/syzbot-assets/ebe09a5995ee/disk-5254c0cb.raw… >> vmlinux: >> https://storage.googleapis.com/syzbot-assets/02178d7f5f98/vmlinux-5254c0cb.… >> kernel image: >> https://storage.googleapis.com/syzbot-assets/12307f47d87c/bzImage-5254c0cb.… >> >> The issue was bisected to: >> >> commit ea4452de2ae987342fadbdd2c044034e6480daad >> Author: Qi Zheng <zhengqi.arch(a)bytedance.com> >> Date: Fri Nov 18 10:00:11 2022 +0000 >> >> mm: fix unexpected changes to {failslab|fail_page_alloc}.attr >> >> bisection log: >> https://syzkaller.appspot.com/x/bisect.txt?x=13027f76e80000 >> final oops: https://syzkaller.appspot.com/x/report.txt?x=10827f76e80000 >> console output: https://syzkaller.appspot.com/x/log.txt?x=17027f76e80000 >> >> IMPORTANT: if you fix the issue, please add the following tag to the >> commit: >> Reported-by: syzbot+59dcc2e7283a6f5f5ba1(a)syzkaller.appspotmail.com >> Fixes: ea4452de2ae9 ("mm: fix unexpected changes to >> {failslab|fail_page_alloc}.attr") >> >> R10: 0000000000000000 R11: 0000000000000246 R12: 00007efe98069194 >> R13: 00007efe97fd2210 R14: 0000000000000002 R15: 6972642f7665642f >> </TASK> >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 5107 at drivers/gpu/drm/drm_prime.c:227 >> drm_prime_destroy_file_private+0x43/0x60 drivers/gpu/drm/drm_prime.c:227 > > The warning is caused by !RB_EMPTY_ROOT(&prime_fpriv->dmabufs): > > drm_prime_destroy_file_private > --> WARN_ON(!RB_EMPTY_ROOT(&prime_fpriv->dmabufs)); > > It seems irrelevant to the logic of fault injection. So I don't see > why the commit ea4452de2ae9 can cause this warning. :( Making an educated guess I strongly think syzbot incorrectly bisected this. What basically happens is that a DRM test case crashes because a file private data structure is destroyed before all DMA-bufs referring to it are destroyed. Looks like a random race condition in a test case to me. Question is really what test is syzbot running and who is maintaining this test case? Regards, Christian. > >> Modules linked in: >> CPU: 0 PID: 5107 Comm: syz-executor227 Not tainted >> 6.7.0-rc6-syzkaller-00248-g5254c0cbc92d #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 11/17/2023 >> RIP: 0010:drm_prime_destroy_file_private+0x43/0x60 >> drivers/gpu/drm/drm_prime.c:227 >> Code: 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 21 48 8b 83 >> 90 00 00 00 48 85 c0 75 06 5b e9 13 f1 93 fc e8 0e f1 93 fc 90 <0f> >> 0b 90 5b e9 04 f1 93 fc e8 3f 9b ea fc eb d8 66 66 2e 0f 1f 84 >> RSP: 0018:ffffc90003bdf9e0 EFLAGS: 00010293 >> RAX: 0000000000000000 RBX: ffff888019f28378 RCX: ffffc90003bdf9b0 >> RDX: ffff888018ff9dc0 RSI: ffffffff84f380c2 RDI: ffff888019f28408 >> RBP: ffff888019f28000 R08: 0000000000000001 R09: 0000000000000001 >> R10: ffffffff8f193a57 R11: 0000000000000000 R12: ffff88814829a000 >> R13: ffff888019f282a8 R14: ffff88814829a068 R15: ffff88814829a0a0 >> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 00007efe98050410 CR3: 000000006d1ff000 CR4: 0000000000350ef0 >> Call Trace: >> <TASK> >> drm_file_free.part.0+0x738/0xb90 drivers/gpu/drm/drm_file.c:290 >> drm_file_free drivers/gpu/drm/drm_file.c:247 [inline] >> drm_close_helper.isra.0+0x180/0x1f0 drivers/gpu/drm/drm_file.c:307 >> drm_release+0x22a/0x4f0 drivers/gpu/drm/drm_file.c:494 >> __fput+0x270/0xb70 fs/file_table.c:394 >> task_work_run+0x14d/0x240 kernel/task_work.c:180 >> exit_task_work include/linux/task_work.h:38 [inline] >> do_exit+0xa8a/0x2ad0 kernel/exit.c:869 >> do_group_exit+0xd4/0x2a0 kernel/exit.c:1018 >> get_signal+0x23b5/0x2790 kernel/signal.c:2904 >> arch_do_signal_or_restart+0x90/0x7f0 arch/x86/kernel/signal.c:309 >> exit_to_user_mode_loop kernel/entry/common.c:168 [inline] >> exit_to_user_mode_prepare+0x121/0x240 kernel/entry/common.c:204 >> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] >> syscall_exit_to_user_mode+0x1e/0x60 kernel/entry/common.c:296 >> do_syscall_64+0x4d/0x110 arch/x86/entry/common.c:89 >> entry_SYSCALL_64_after_hwframe+0x63/0x6b >> RIP: 0033:0x7efe98014769 >> Code: Unable to access opcode bytes at 0x7efe9801473f. >> RSP: 002b:00007efe97fd2208 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca >> RAX: fffffffffffffe00 RBX: 00007efe9809c408 RCX: 00007efe98014769 >> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007efe9809c408 >> RBP: 00007efe9809c400 R08: 0000000000003131 R09: 0000000000003131 >> R10: 0000000000000000 R11: 0000000000000246 R12: 00007efe98069194 >> R13: 00007efe97fd2210 R14: 0000000000000002 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. >> For information about bisection process see: >> https://goo.gl/tpsmEJ#bisection >> >> If the report is already addressed, 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 report's subsystems, reply with: >> #syz set subsystems: new-subsystem >> (See the list of subsystem names on the web dashboard) >> >> If the report is a duplicate of another one, reply with: >> #syz dup: exact-subject-of-another-report >> >> If you want to undo deduplication, reply with: >> #syz undup

2 years, 1 month

1
0
0 0

[PATCH] drm/scheduler: Unwrap job dependencies

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> Container fences have burner contexts, which makes the trick to store at most one fence per context somewhat useless if we don't unwrap array or chain fences. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/scheduler/sched_main.c | 47 ++++++++++++++++++-------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 9762464e3f99..16b550949c57 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -52,6 +52,7 @@ #include <linux/wait.h> #include <linux/sched.h> #include <linux/completion.h> +#include <linux/dma-fence-unwrap.h> #include <linux/dma-resv.h> #include <uapi/linux/sched/types.h> @@ -684,27 +685,14 @@ void drm_sched_job_arm(struct drm_sched_job *job) } EXPORT_SYMBOL(drm_sched_job_arm); -/** - * drm_sched_job_add_dependency - adds the fence as a job dependency - * @job: scheduler job to add the dependencies to - * @fence: the dma_fence to add to the list of dependencies. - * - * Note that @fence is consumed in both the success and error cases. - * - * Returns: - * 0 on success, or an error on failing to expand the array. - */ -int drm_sched_job_add_dependency(struct drm_sched_job *job, - struct dma_fence *fence) +static int drm_sched_job_add_single_dependency(struct drm_sched_job *job, + struct dma_fence *fence) { struct dma_fence *entry; unsigned long index; u32 id = 0; int ret; - if (!fence) - return 0; - /* Deduplicate if we already depend on a fence from the same context. * This lets the size of the array of deps scale with the number of * engines involved, rather than the number of BOs. @@ -728,6 +716,35 @@ int drm_sched_job_add_dependency(struct drm_sched_job *job, return ret; } + +/** + * drm_sched_job_add_dependency - adds the fence as a job dependency + * @job: scheduler job to add the dependencies to + * @fence: the dma_fence to add to the list of dependencies. + * + * Note that @fence is consumed in both the success and error cases. + * + * Returns: + * 0 on success, or an error on failing to expand the array. + */ +int drm_sched_job_add_dependency(struct drm_sched_job *job, + struct dma_fence *fence) +{ + struct dma_fence_unwrap iter; + struct dma_fence *f; + int ret = 0; + + dma_fence_unwrap_for_each (f, &iter, fence) { + dma_fence_get(f); + ret = drm_sched_job_add_single_dependency(job, f); + if (ret) + break; + } + + dma_fence_put(fence); + + return ret; +} EXPORT_SYMBOL(drm_sched_job_add_dependency); /** -- 2.42.0

2 years, 1 month

2
1
0 0

[syzbot] [dri?] KMSAN: uninit-value in drm_mode_setcrtc

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 2741f1b02117 string: use __builtin_memcpy() in strlcpy/str.. git tree: https://github.com/google/kmsan.git master console+strace: https://syzkaller.appspot.com/x/log.txt?x=17bb33d1280000 kernel config: https://syzkaller.appspot.com/x/.config?x=753079601b2300f9 dashboard link: https://syzkaller.appspot.com/bug?extid=4fad2e57beb6397ab2fc compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d669a5280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14d8f095280000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/ebd05512d8d7/disk-2741f1b0.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/aa555b09582c/vmlinux-2741f1b0.… kernel image: https://storage.googleapis.com/syzbot-assets/5ea0934e02cc/bzImage-2741f1b0.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4fad2e57beb6397ab2fc(a)syzkaller.appspotmail.com ===================================================== BUG: KMSAN: uninit-value in drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716 slab_alloc_node mm/slub.c:3451 [inline] __kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490 __do_kmalloc_node mm/slab_common.c:965 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:979 kmalloc_array include/linux/slab.h:596 [inline] drm_mode_setcrtc+0x1dba/0x24a0 drivers/gpu/drm/drm_crtc.c:846 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 4955 Comm: syz-executor275 Not tainted 6.4.0-rc4-syzkaller-g2741f1b02117 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 ===================================================== --- 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 change 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, 2 months

4
5
0 0

Re: [PATCH] media: medkatek: vcodec: support tee decoder

by kernel test robot

Hi Yunfei, kernel test robot noticed the following build errors: [auto build test ERROR on media-tree/master] [also build test ERROR on linus/master v6.7-rc4 next-20231206] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-v… base: git://linuxtv.org/media_tree.git master patch link: https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com patch subject: [PATCH] media: medkatek: vcodec: support tee decoder config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp@…) compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202312070723.APrpMLj9-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:11: error: no member named 'is_secure_playback' in 'struct mtk_vcodec_dec_ctx' 313 | if (ctx->is_secure_playback) | ~~~ ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: error: call to undeclared function 'mtk_vcodec_dec_optee_release'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: note: did you mean 'mtk_vcodec_dec_release'? drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:88:6: note: 'mtk_vcodec_dec_release' declared here 88 | void mtk_vcodec_dec_release(struct mtk_vcodec_dec_ctx *ctx); | ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:37: error: no member named 'optee_private' in 'struct mtk_vcodec_dec_dev' 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ~~~ ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: error: call to undeclared function 'mtk_vcodec_dec_optee_private_init'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 472 | ret = mtk_vcodec_dec_optee_private_init(dev); | ^ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: note: did you mean 'mtk_vcodec_dec_queue_init'? drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:85:5: note: 'mtk_vcodec_dec_queue_init' declared here 85 | int mtk_vcodec_dec_queue_init(void *priv, struct vb2_queue *src_vq, | ^ 4 errors generated. vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c 291 292 static int fops_vcodec_release(struct file *file) 293 { 294 struct mtk_vcodec_dec_dev *dev = video_drvdata(file); 295 struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data); 296 297 mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id); 298 mutex_lock(&dev->dev_mutex); 299 300 /* 301 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it 302 * makes sure the worker thread is not running after vdec_if_deinit. 303 * Second, the decoder will be flushed and all the buffers will be 304 * returned in stop_streaming. 305 */ 306 v4l2_m2m_ctx_release(ctx->m2m_ctx); 307 mtk_vcodec_dec_release(ctx); 308 309 v4l2_fh_del(&ctx->fh); 310 v4l2_fh_exit(&ctx->fh); 311 v4l2_ctrl_handler_free(&ctx->ctrl_hdl); 312 > 313 if (ctx->is_secure_playback) > 314 mtk_vcodec_dec_optee_release(dev->optee_private); 315 316 mtk_vcodec_dbgfs_remove(dev, ctx->id); 317 list_del_init(&ctx->list); 318 kfree(ctx); 319 mutex_unlock(&dev->dev_mutex); 320 return 0; 321 } 322 323 static const struct v4l2_file_operations mtk_vcodec_fops = { 324 .owner = THIS_MODULE, 325 .open = fops_vcodec_open, 326 .release = fops_vcodec_release, 327 .poll = v4l2_m2m_fop_poll, 328 .unlocked_ioctl = video_ioctl2, 329 .mmap = v4l2_m2m_fop_mmap, 330 }; 331 332 static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev) 333 { 334 struct device *dev = &vdec_dev->plat_dev->dev; 335 336 if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec")) 337 vdec_dev->chip_name = MTK_VDEC_MT8173; 338 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec")) 339 vdec_dev->chip_name = MTK_VDEC_MT8183; 340 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec")) 341 vdec_dev->chip_name = MTK_VDEC_MT8192; 342 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec")) 343 vdec_dev->chip_name = MTK_VDEC_MT8195; 344 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec")) 345 vdec_dev->chip_name = MTK_VDEC_MT8186; 346 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec")) 347 vdec_dev->chip_name = MTK_VDEC_MT8188; 348 else 349 vdec_dev->chip_name = MTK_VDEC_INVAL; 350 } 351 352 static int mtk_vcodec_probe(struct platform_device *pdev) 353 { 354 struct mtk_vcodec_dec_dev *dev; 355 struct video_device *vfd_dec; 356 phandle rproc_phandle; 357 enum mtk_vcodec_fw_type fw_type; 358 int i, ret; 359 360 dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); 361 if (!dev) 362 return -ENOMEM; 363 364 INIT_LIST_HEAD(&dev->ctx_list); 365 dev->plat_dev = pdev; 366 367 mtk_vcodec_dec_get_chip_name(dev); 368 if (dev->chip_name == MTK_VDEC_INVAL) { 369 dev_err(&pdev->dev, "Failed to get decoder chip name"); 370 return -EINVAL; 371 } 372 373 dev->vdec_pdata = of_device_get_match_data(&pdev->dev); 374 if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu", 375 &rproc_phandle)) { 376 fw_type = VPU; 377 } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp", 378 &rproc_phandle)) { 379 fw_type = SCP; 380 } else { 381 dev_dbg(&pdev->dev, "Could not get vdec IPI device"); 382 return -ENODEV; 383 } 384 dma_set_max_seg_size(&pdev->dev, UINT_MAX); 385 386 dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER); 387 if (IS_ERR(dev->fw_handler)) 388 return PTR_ERR(dev->fw_handler); 389 390 ret = mtk_vcodec_init_dec_resources(dev); 391 if (ret) { 392 dev_err(&pdev->dev, "Failed to init dec resources"); 393 goto err_dec_pm; 394 } 395 396 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) { 397 dev->core_workqueue = 398 alloc_ordered_workqueue("core-decoder", 399 WQ_MEM_RECLAIM | WQ_FREEZABLE); 400 if (!dev->core_workqueue) { 401 dev_dbg(&pdev->dev, "Failed to create core workqueue"); 402 ret = -EINVAL; 403 goto err_res; 404 } 405 } 406 407 for (i = 0; i < MTK_VDEC_HW_MAX; i++) 408 mutex_init(&dev->dec_mutex[i]); 409 mutex_init(&dev->dev_mutex); 410 spin_lock_init(&dev->irqlock); 411 412 snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s", 413 "[/MTK_V4L2_VDEC]"); 414 415 ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev); 416 if (ret) { 417 dev_err(&pdev->dev, "v4l2_device_register err=%d", ret); 418 goto err_core_workq; 419 } 420 421 vfd_dec = video_device_alloc(); 422 if (!vfd_dec) { 423 dev_err(&pdev->dev, "Failed to allocate video device"); 424 ret = -ENOMEM; 425 goto err_dec_alloc; 426 } 427 vfd_dec->fops = &mtk_vcodec_fops; 428 vfd_dec->ioctl_ops = &mtk_vdec_ioctl_ops; 429 vfd_dec->release = video_device_release; 430 vfd_dec->lock = &dev->dev_mutex; 431 vfd_dec->v4l2_dev = &dev->v4l2_dev; 432 vfd_dec->vfl_dir = VFL_DIR_M2M; 433 vfd_dec->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | 434 V4L2_CAP_STREAMING; 435 436 snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s", 437 MTK_VCODEC_DEC_NAME); 438 video_set_drvdata(vfd_dec, dev); 439 dev->vfd_dec = vfd_dec; 440 platform_set_drvdata(pdev, dev); 441 442 dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops); 443 if (IS_ERR((__force void *)dev->m2m_dev_dec)) { 444 dev_err(&pdev->dev, "Failed to init mem2mem dec device"); 445 ret = PTR_ERR((__force void *)dev->m2m_dev_dec); 446 goto err_dec_alloc; 447 } 448 449 dev->decode_workqueue = 450 alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME, 451 WQ_MEM_RECLAIM | WQ_FREEZABLE); 452 if (!dev->decode_workqueue) { 453 dev_err(&pdev->dev, "Failed to create decode workqueue"); 454 ret = -EINVAL; 455 goto err_event_workq; 456 } 457 458 if (dev->vdec_pdata->is_subdev_supported) { 459 ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, 460 &pdev->dev); 461 if (ret) { 462 dev_err(&pdev->dev, "Main device of_platform_populate failed."); 463 goto err_reg_cont; 464 } 465 } else { 466 set_bit(MTK_VDEC_CORE, dev->subdev_bitmap); 467 } 468 469 atomic_set(&dev->dec_active_cnt, 0); 470 memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info)); 471 mutex_init(&dev->dec_racing_info_mutex); > 472 ret = mtk_vcodec_dec_optee_private_init(dev); 473 if (ret) { 474 dev_err(&pdev->dev, "Failed to init svp private."); 475 goto err_reg_cont; 476 } 477 478 ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1); 479 if (ret) { 480 dev_err(&pdev->dev, "Failed to register video device"); 481 goto err_reg_cont; 482 } 483 484 if (dev->vdec_pdata->uses_stateless_api) { 485 v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD); 486 v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD); 487 488 dev->mdev_dec.dev = &pdev->dev; 489 strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME, 490 sizeof(dev->mdev_dec.model)); 491 492 media_device_init(&dev->mdev_dec); 493 dev->mdev_dec.ops = &mtk_vcodec_media_ops; 494 dev->v4l2_dev.mdev = &dev->mdev_dec; 495 496 ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec, 497 MEDIA_ENT_F_PROC_VIDEO_DECODER); 498 if (ret) { 499 dev_err(&pdev->dev, "Failed to register media controller"); 500 goto err_dec_mem_init; 501 } 502 503 ret = media_device_register(&dev->mdev_dec); 504 if (ret) { 505 dev_err(&pdev->dev, "Failed to register media device"); 506 goto err_media_reg; 507 } 508 509 dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor); 510 } 511 512 mtk_vcodec_dbgfs_init(dev, false); 513 dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor); 514 515 return 0; 516 517 err_media_reg: 518 v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec); 519 err_dec_mem_init: 520 video_unregister_device(vfd_dec); 521 err_reg_cont: 522 if (dev->vdec_pdata->uses_stateless_api) 523 media_device_cleanup(&dev->mdev_dec); 524 destroy_workqueue(dev->decode_workqueue); 525 err_event_workq: 526 v4l2_m2m_release(dev->m2m_dev_dec); 527 err_dec_alloc: 528 v4l2_device_unregister(&dev->v4l2_dev); 529 err_core_workq: 530 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) 531 destroy_workqueue(dev->core_workqueue); 532 err_res: 533 if (!dev->vdec_pdata->is_subdev_supported) 534 pm_runtime_disable(dev->pm.dev); 535 err_dec_pm: 536 mtk_vcodec_fw_release(dev->fw_handler); 537 return ret; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 2 months

1
0
0 0

Re: [PATCH] media: medkatek: vcodec: support tee decoder

by kernel test robot

Hi Yunfei, kernel test robot noticed the following build errors: [auto build test ERROR on media-tree/master] [also build test ERROR on linus/master v6.7-rc4 next-20231206] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-v… base: git://linuxtv.org/media_tree.git master patch link: https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com patch subject: [PATCH] media: medkatek: vcodec: support tee decoder config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202312070717.a86rODYn-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'fops_vcodec_release': >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:16: error: 'struct mtk_vcodec_dec_ctx' has no member named 'is_secure_playback' 313 | if (ctx->is_secure_playback) | ^~ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:17: error: implicit declaration of function 'mtk_vcodec_dec_optee_release'; did you mean 'mtk_vcodec_dec_release'? [-Werror=implicit-function-declaration] 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | mtk_vcodec_dec_release >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:49: error: 'struct mtk_vcodec_dec_dev' has no member named 'optee_private' 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^~ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'mtk_vcodec_probe': >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:15: error: implicit declaration of function 'mtk_vcodec_dec_optee_private_init'; did you mean 'mtk_vcodec_dec_queue_init'? [-Werror=implicit-function-declaration] 472 | ret = mtk_vcodec_dec_optee_private_init(dev); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | mtk_vcodec_dec_queue_init cc1: some warnings being treated as errors vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c 291 292 static int fops_vcodec_release(struct file *file) 293 { 294 struct mtk_vcodec_dec_dev *dev = video_drvdata(file); 295 struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data); 296 297 mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id); 298 mutex_lock(&dev->dev_mutex); 299 300 /* 301 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it 302 * makes sure the worker thread is not running after vdec_if_deinit. 303 * Second, the decoder will be flushed and all the buffers will be 304 * returned in stop_streaming. 305 */ 306 v4l2_m2m_ctx_release(ctx->m2m_ctx); 307 mtk_vcodec_dec_release(ctx); 308 309 v4l2_fh_del(&ctx->fh); 310 v4l2_fh_exit(&ctx->fh); 311 v4l2_ctrl_handler_free(&ctx->ctrl_hdl); 312 > 313 if (ctx->is_secure_playback) > 314 mtk_vcodec_dec_optee_release(dev->optee_private); 315 316 mtk_vcodec_dbgfs_remove(dev, ctx->id); 317 list_del_init(&ctx->list); 318 kfree(ctx); 319 mutex_unlock(&dev->dev_mutex); 320 return 0; 321 } 322 323 static const struct v4l2_file_operations mtk_vcodec_fops = { 324 .owner = THIS_MODULE, 325 .open = fops_vcodec_open, 326 .release = fops_vcodec_release, 327 .poll = v4l2_m2m_fop_poll, 328 .unlocked_ioctl = video_ioctl2, 329 .mmap = v4l2_m2m_fop_mmap, 330 }; 331 332 static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev) 333 { 334 struct device *dev = &vdec_dev->plat_dev->dev; 335 336 if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec")) 337 vdec_dev->chip_name = MTK_VDEC_MT8173; 338 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec")) 339 vdec_dev->chip_name = MTK_VDEC_MT8183; 340 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec")) 341 vdec_dev->chip_name = MTK_VDEC_MT8192; 342 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec")) 343 vdec_dev->chip_name = MTK_VDEC_MT8195; 344 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec")) 345 vdec_dev->chip_name = MTK_VDEC_MT8186; 346 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec")) 347 vdec_dev->chip_name = MTK_VDEC_MT8188; 348 else 349 vdec_dev->chip_name = MTK_VDEC_INVAL; 350 } 351 352 static int mtk_vcodec_probe(struct platform_device *pdev) 353 { 354 struct mtk_vcodec_dec_dev *dev; 355 struct video_device *vfd_dec; 356 phandle rproc_phandle; 357 enum mtk_vcodec_fw_type fw_type; 358 int i, ret; 359 360 dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); 361 if (!dev) 362 return -ENOMEM; 363 364 INIT_LIST_HEAD(&dev->ctx_list); 365 dev->plat_dev = pdev; 366 367 mtk_vcodec_dec_get_chip_name(dev); 368 if (dev->chip_name == MTK_VDEC_INVAL) { 369 dev_err(&pdev->dev, "Failed to get decoder chip name"); 370 return -EINVAL; 371 } 372 373 dev->vdec_pdata = of_device_get_match_data(&pdev->dev); 374 if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu", 375 &rproc_phandle)) { 376 fw_type = VPU; 377 } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp", 378 &rproc_phandle)) { 379 fw_type = SCP; 380 } else { 381 dev_dbg(&pdev->dev, "Could not get vdec IPI device"); 382 return -ENODEV; 383 } 384 dma_set_max_seg_size(&pdev->dev, UINT_MAX); 385 386 dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER); 387 if (IS_ERR(dev->fw_handler)) 388 return PTR_ERR(dev->fw_handler); 389 390 ret = mtk_vcodec_init_dec_resources(dev); 391 if (ret) { 392 dev_err(&pdev->dev, "Failed to init dec resources"); 393 goto err_dec_pm; 394 } 395 396 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) { 397 dev->core_workqueue = 398 alloc_ordered_workqueue("core-decoder", 399 WQ_MEM_RECLAIM | WQ_FREEZABLE); 400 if (!dev->core_workqueue) { 401 dev_dbg(&pdev->dev, "Failed to create core workqueue"); 402 ret = -EINVAL; 403 goto err_res; 404 } 405 } 406 407 for (i = 0; i < MTK_VDEC_HW_MAX; i++) 408 mutex_init(&dev->dec_mutex[i]); 409 mutex_init(&dev->dev_mutex); 410 spin_lock_init(&dev->irqlock); 411 412 snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s", 413 "[/MTK_V4L2_VDEC]"); 414 415 ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev); 416 if (ret) { 417 dev_err(&pdev->dev, "v4l2_device_register err=%d", ret); 418 goto err_core_workq; 419 } 420 421 vfd_dec = video_device_alloc(); 422 if (!vfd_dec) { 423 dev_err(&pdev->dev, "Failed to allocate video device"); 424 ret = -ENOMEM; 425 goto err_dec_alloc; 426 } 427 vfd_dec->fops = &mtk_vcodec_fops; 428 vfd_dec->ioctl_ops = &mtk_vdec_ioctl_ops; 429 vfd_dec->release = video_device_release; 430 vfd_dec->lock = &dev->dev_mutex; 431 vfd_dec->v4l2_dev = &dev->v4l2_dev; 432 vfd_dec->vfl_dir = VFL_DIR_M2M; 433 vfd_dec->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | 434 V4L2_CAP_STREAMING; 435 436 snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s", 437 MTK_VCODEC_DEC_NAME); 438 video_set_drvdata(vfd_dec, dev); 439 dev->vfd_dec = vfd_dec; 440 platform_set_drvdata(pdev, dev); 441 442 dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops); 443 if (IS_ERR((__force void *)dev->m2m_dev_dec)) { 444 dev_err(&pdev->dev, "Failed to init mem2mem dec device"); 445 ret = PTR_ERR((__force void *)dev->m2m_dev_dec); 446 goto err_dec_alloc; 447 } 448 449 dev->decode_workqueue = 450 alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME, 451 WQ_MEM_RECLAIM | WQ_FREEZABLE); 452 if (!dev->decode_workqueue) { 453 dev_err(&pdev->dev, "Failed to create decode workqueue"); 454 ret = -EINVAL; 455 goto err_event_workq; 456 } 457 458 if (dev->vdec_pdata->is_subdev_supported) { 459 ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, 460 &pdev->dev); 461 if (ret) { 462 dev_err(&pdev->dev, "Main device of_platform_populate failed."); 463 goto err_reg_cont; 464 } 465 } else { 466 set_bit(MTK_VDEC_CORE, dev->subdev_bitmap); 467 } 468 469 atomic_set(&dev->dec_active_cnt, 0); 470 memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info)); 471 mutex_init(&dev->dec_racing_info_mutex); > 472 ret = mtk_vcodec_dec_optee_private_init(dev); 473 if (ret) { 474 dev_err(&pdev->dev, "Failed to init svp private."); 475 goto err_reg_cont; 476 } 477 478 ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1); 479 if (ret) { 480 dev_err(&pdev->dev, "Failed to register video device"); 481 goto err_reg_cont; 482 } 483 484 if (dev->vdec_pdata->uses_stateless_api) { 485 v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD); 486 v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD); 487 488 dev->mdev_dec.dev = &pdev->dev; 489 strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME, 490 sizeof(dev->mdev_dec.model)); 491 492 media_device_init(&dev->mdev_dec); 493 dev->mdev_dec.ops = &mtk_vcodec_media_ops; 494 dev->v4l2_dev.mdev = &dev->mdev_dec; 495 496 ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec, 497 MEDIA_ENT_F_PROC_VIDEO_DECODER); 498 if (ret) { 499 dev_err(&pdev->dev, "Failed to register media controller"); 500 goto err_dec_mem_init; 501 } 502 503 ret = media_device_register(&dev->mdev_dec); 504 if (ret) { 505 dev_err(&pdev->dev, "Failed to register media device"); 506 goto err_media_reg; 507 } 508 509 dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor); 510 } 511 512 mtk_vcodec_dbgfs_init(dev, false); 513 dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor); 514 515 return 0; 516 517 err_media_reg: 518 v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec); 519 err_dec_mem_init: 520 video_unregister_device(vfd_dec); 521 err_reg_cont: 522 if (dev->vdec_pdata->uses_stateless_api) 523 media_device_cleanup(&dev->mdev_dec); 524 destroy_workqueue(dev->decode_workqueue); 525 err_event_workq: 526 v4l2_m2m_release(dev->m2m_dev_dec); 527 err_dec_alloc: 528 v4l2_device_unregister(&dev->v4l2_dev); 529 err_core_workq: 530 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) 531 destroy_workqueue(dev->core_workqueue); 532 err_res: 533 if (!dev->vdec_pdata->is_subdev_supported) 534 pm_runtime_disable(dev->pm.dev); 535 err_dec_pm: 536 mtk_vcodec_fw_release(dev->fw_handler); 537 return ret; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 2 months

1
0
0 0

[RFC] drm/scheduler: Unwrap job dependencies

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> Container fences have burner contexts, which makes the trick to store at most one fence per context somewhat useless if we don't unwrap array or chain fences. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- tbh, I'm not sure why we weren't doing this already, unless there is something I'm overlooking drivers/gpu/drm/scheduler/sched_main.c | 43 +++++++++++++++++--------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index c2ee44d6224b..f59e5335afbb 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -41,20 +41,21 @@ * 4. Entities themselves maintain a queue of jobs that will be scheduled on * the hardware. * * The jobs in a entity are always scheduled in the order that they were pushed. */ #include <linux/kthread.h> #include <linux/wait.h> #include <linux/sched.h> #include <linux/completion.h> +#include <linux/dma-fence-unwrap.h> #include <linux/dma-resv.h> #include <uapi/linux/sched/types.h> #include <drm/drm_print.h> #include <drm/drm_gem.h> #include <drm/gpu_scheduler.h> #include <drm/spsc_queue.h> #define CREATE_TRACE_POINTS #include "gpu_scheduler_trace.h" @@ -665,41 +666,27 @@ void drm_sched_job_arm(struct drm_sched_job *job) sched = entity->rq->sched; job->sched = sched; job->s_priority = entity->rq - sched->sched_rq; job->id = atomic64_inc_return(&sched->job_id_count); drm_sched_fence_init(job->s_fence, job->entity); } EXPORT_SYMBOL(drm_sched_job_arm); -/** - * drm_sched_job_add_dependency - adds the fence as a job dependency - * @job: scheduler job to add the dependencies to - * @fence: the dma_fence to add to the list of dependencies. - * - * Note that @fence is consumed in both the success and error cases. - * - * Returns: - * 0 on success, or an error on failing to expand the array. - */ -int drm_sched_job_add_dependency(struct drm_sched_job *job, - struct dma_fence *fence) +static int _add_dependency(struct drm_sched_job *job, struct dma_fence *fence) { struct dma_fence *entry; unsigned long index; u32 id = 0; int ret; - if (!fence) - return 0; - /* Deduplicate if we already depend on a fence from the same context. * This lets the size of the array of deps scale with the number of * engines involved, rather than the number of BOs. */ xa_for_each(&job->dependencies, index, entry) { if (entry->context != fence->context) continue; if (dma_fence_is_later(fence, entry)) { dma_fence_put(entry); @@ -709,20 +696,46 @@ int drm_sched_job_add_dependency(struct drm_sched_job *job, } return 0; } ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b, GFP_KERNEL); if (ret != 0) dma_fence_put(fence); return ret; } + +/** + * drm_sched_job_add_dependency - adds the fence as a job dependency + * @job: scheduler job to add the dependencies to + * @fence: the dma_fence to add to the list of dependencies. + * + * Note that @fence is consumed in both the success and error cases. + * + * Returns: + * 0 on success, or an error on failing to expand the array. + */ +int drm_sched_job_add_dependency(struct drm_sched_job *job, + struct dma_fence *fence) +{ + struct dma_fence_unwrap iter; + struct dma_fence *f; + int ret = 0; + + dma_fence_unwrap_for_each (f, &iter, fence) { + ret = _add_dependency(job, f); + if (ret) + break; + } + + return ret; +} EXPORT_SYMBOL(drm_sched_job_add_dependency); /** * drm_sched_job_add_resv_dependencies - add all fences from the resv to the job * @job: scheduler job to add the dependencies to * @resv: the dma_resv object to get the fences from * @usage: the dma_resv_usage to use to filter the fences * * This adds all fences matching the given usage from @resv to @job. * Must be called with the @resv lock held. -- 2.39.2

2 years, 2 months

3
11
0 0

[PATCH v9 0/3] dma-fence: Deadline awareness (uabi edition)

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> This is a re-post of the remaining patches from: https://patchwork.freedesktop.org/series/114490/ Part of the hold-up of the remaining uabi patches was compositor support, but now an MR for kwin exists: https://invent.kde.org/plasma/kwin/-/merge_requests/4358 The syncobj userspace is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21973 v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. v9: Repost the remaining patches that expose new uabi to userspace. Rob Clark (3): drm/syncobj: Add deadline support for syncobj waits dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sw_sync: Add fence deadline support drivers/dma-buf/dma-fence.c | 3 +- drivers/dma-buf/sw_sync.c | 82 ++++++++++++++++++++++++++++++++++ drivers/dma-buf/sync_debug.h | 2 + drivers/dma-buf/sync_file.c | 19 ++++++++ drivers/gpu/drm/drm_syncobj.c | 64 ++++++++++++++++++++------ include/uapi/drm/drm.h | 17 +++++++ include/uapi/linux/sync_file.h | 22 +++++++++ 7 files changed, 195 insertions(+), 14 deletions(-) -- 2.41.0

2 years, 2 months

2
3
0 0

Re: [PATCH v5] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote: > This patch introduces an initial KUnit test suite for GEM objects > backed by shmem buffers. > > Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> > Signed-off-by: Marco Pagani <marpagan(a)redhat.com> > > v5: > - using __drm_kunit_helper_alloc_drm_device() to avoid local struct > v4: > - Add missing MMU dependency for DRM_GEM_SHMEM_HELPER (kernel test robot) > v3: > - Explicitly cast pointers in the helpers > - Removed unused pointer to parent dev in struct fake_dev > - Test entries reordering in Kconfig and Makefile sent as a separate patch > v2: > - Improved description of test cases > - Cleaner error handling using KUnit actions > - Alphabetical order in Kconfig and Makefile Applied to drm-misc-next, thanks! Maxime

2 years, 2 months

1
0
0 0

Re: [PATCH] dma-buf: Correct the documentation of name and exp_name symbols

by Christian König

Am 22.11.23 um 17:05 schrieb Ramesh Errabolu: > Fix the documentation of struct dma_buf members name and exp_name > as to how these members are to be used and accessed. > > Signed-off-by: Ramesh Errabolu <Ramesh.Errabolu(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > include/linux/dma-buf.h | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index 3f31baa3293f..8ff4add71f88 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -343,16 +343,19 @@ struct dma_buf { > /** > * @exp_name: > * > - * Name of the exporter; useful for debugging. See the > - * DMA_BUF_SET_NAME IOCTL. > + * Name of the exporter; useful for debugging. Must not be NULL > */ > const char *exp_name; > > /** > * @name: > * > - * Userspace-provided name; useful for accounting and debugging, > - * protected by dma_resv_lock() on @resv and @name_lock for read access. > + * Userspace-provided name. Default value is NULL. If not NULL, > + * length cannot be longer than DMA_BUF_NAME_LEN, including NIL > + * char. Useful for accounting and debugging. Read/Write accesses > + * are protected by @name_lock > + * > + * See the IOCTLs DMA_BUF_SET_NAME or DMA_BUF_SET_NAME_A/B > */ > const char *name; >

2 years, 2 months

3
2
0 0

[PATCH v2 0/6] 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 V2: Changes since v2: - fix the error about checking the yaml file. - match drm driver GEM DMA API. - Delete the custom crtc property . - hdmi use drmm_ new api to automatically manage resources. - update the modifiers comments. - enabling KASAN, fix the error during removing module Keith Zhao (6): 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 driver .../starfive/starfive,display-subsystem.yaml | 41 + .../starfive/starfive,jh7110-dc8200.yaml | 109 + .../starfive/starfive,jh7110-inno-hdmi.yaml | 85 + MAINTAINERS | 7 + .../jh7110-starfive-visionfive-2.dtsi | 91 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/verisilicon/Kconfig | 21 + drivers/gpu/drm/verisilicon/Makefile | 12 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 949 ++++++++ drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 257 +++ drivers/gpu/drm/verisilicon/vs_crtc.h | 43 + drivers/gpu/drm/verisilicon/vs_dc.c | 1002 +++++++++ drivers/gpu/drm/verisilicon/vs_dc.h | 80 + drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959 +++++++++++++++++ drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 +++++ drivers/gpu/drm/verisilicon/vs_drv.c | 234 ++ drivers/gpu/drm/verisilicon/vs_drv.h | 31 + drivers/gpu/drm/verisilicon/vs_modeset.c | 36 + drivers/gpu/drm/verisilicon/vs_modeset.h | 10 + drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++++ drivers/gpu/drm/verisilicon/vs_plane.h | 58 + drivers/gpu/drm/verisilicon/vs_type.h | 69 + include/uapi/drm/drm_fourcc.h | 57 + include/uapi/drm/vs_drm.h | 50 + 27 files changed, 6558 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_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, 2 months

7
35
0 0

Re: [PATCH v4] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Fri, Nov 24, 2023 at 11:15:12AM +0100, Marco Pagani wrote: > > > On 2023-11-24 09:49, Maxime Ripard wrote: > > Hi, > > > > On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote: > >> +static int drm_gem_shmem_test_init(struct kunit *test) > >> +{ > >> + struct device *dev; > >> + struct fake_dev { > >> + struct drm_device drm_dev; > >> + } *fdev; > >> + > > > > [...] > > > >> + > >> + /* > >> + * The DRM core will automatically initialize the GEM core and create > >> + * a DRM Memory Manager object which provides an address space pool > >> + * for GEM objects allocation. > >> + */ > >> + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > >> + drm_dev, DRIVER_GEM); > >> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); > > > > Sorry I missed it earlier, but you don't need the intermediate structure > > if you use > > > > struct drm_device *drm; > > > > drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0, DRIVER_GEM); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm); > > > > I prefer to use drm_kunit_helper_alloc_drm_device() with the intermediate > structure. It makes the code clearer, in my opinion. Initially, when > developing the suite, I was using __drm_kunit_helper_alloc_drm_device() > as most test suites do, but I feel the list of arguments including > "sizeof(*drm), 0," is less straightforward to understand. Then we can create an init helper, and you can allocate the drm_device through drmm_kzalloc, but I'd like tests to use consistent constructs. This can of course be made as a later patch: you use the same construct the other tests do here, and later we work on the init function and convert all tests to use it. Maxime

2 years, 2 months

1
0
0 0

[PATCH] dma-buf: fix check in dma_resv_add_fence

by Christian König

It's valid to add the same fence multiple times to a dma-resv object and we shouldn't need one extra slot for each. Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later") Cc: stable(a)vger.kernel.org # v5.19+ --- drivers/dma-buf/dma-resv.c | 2 +- include/linux/dma-fence.h | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 38b4110378de..eb8b733065b2 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -301,7 +301,7 @@ void dma_resv_add_fence(struct dma_resv *obj, struct dma_fence *fence, dma_resv_list_entry(fobj, i, obj, &old, &old_usage); if ((old->context == fence->context && old_usage >= usage && - dma_fence_is_later(fence, old)) || + dma_fence_is_later_or_same(fence, old)) || dma_fence_is_signaled(old)) { dma_resv_list_set(fobj, i, fence, usage); dma_fence_put(old); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index ebe78bd3d121..b3772edca2e6 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -498,6 +498,21 @@ static inline bool dma_fence_is_later(struct dma_fence *f1, return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops); } +/** + * dma_fence_is_later_or_same - return true if f1 is later or same as f2 + * @f1: the first fence from the same context + * @f2: the second fence from the same context + * + * Returns true if f1 is chronologically later than f2 or the same fence. Both + * fences must be from the same context, since a seqno is not re-used across + * contexts. + */ +static inline bool dma_fence_is_later_or_same(struct dma_fence *f1, + struct dma_fence *f2) +{ + return f1 == f2 || dma_fence_is_later(f1, f2); +} + /** * dma_fence_later - return the chronologically later fence * @f1: the first fence from the same context -- 2.34.1

2 years, 2 months

2
2
0 0

Re: [PATCH v4] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi, On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote: > +static int drm_gem_shmem_test_init(struct kunit *test) > +{ > + struct device *dev; > + struct fake_dev { > + struct drm_device drm_dev; > + } *fdev; > + [...] > + > + /* > + * The DRM core will automatically initialize the GEM core and create > + * a DRM Memory Manager object which provides an address space pool > + * for GEM objects allocation. > + */ > + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > + drm_dev, DRIVER_GEM); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); Sorry I missed it earlier, but you don't need the intermediate structure if you use struct drm_device *drm; drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0, DRIVER_GEM); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm); Maxime

2 years, 2 months

1
0
0 0

Re: [PATCH v3] drm/test: add a test suite for GEM objects backed by shmem

by kernel test robot

Hi Marco, kernel test robot noticed the following build warnings: [auto build test WARNING on c79b972eb88b077d2765e7790d0902b3dc94d55c] url: https://github.com/intel-lab-lkp/linux/commits/Marco-Pagani/drm-test-add-a-… base: c79b972eb88b077d2765e7790d0902b3dc94d55c patch link: https://lore.kernel.org/r/20231120150339.104257-1-marpagan%40redhat.com patch subject: [PATCH v3] drm/test: add a test suite for GEM objects backed by shmem config: arm-kismet-CONFIG_DRM_GEM_SHMEM_HELPER-CONFIG_DRM_KUNIT_TEST-0-0 (https://download.01.org/0day-ci/archive/20231121/202311211542.3ZrZO6J2-lkp@…) reproduce: (https://download.01.org/0day-ci/archive/20231121/202311211542.3ZrZO6J2-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202311211542.3ZrZO6J2-lkp@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER when selected by DRM_KUNIT_TEST WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && MMU [=n] Selected by [y]: - DRM_KUNIT_TEST [=y] && HAS_IOMEM [=y] && DRM [=y] && KUNIT [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 2 months

1
0
0 0

[PATCH v6] drm/mediatek: add dma buffer control for drm plane disable

by Yongqiang Niu

the DMA buffer is released when still accessed by Mediatek display hardware, this flow can lead to M4U reporting a translation fault warning add dma buffer control flow in mediatek driver: get dma buffer when drm plane disable put dma buffer when overlay really disable Fixes: 41016fe1028e ("drm: Rename plane->state variables in atomic update and disable") Signed-off-by: Yongqiang Niu <yongqiang.niu(a)mediatek.com> --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 ++++++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_plane.c | 12 ++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_plane.h | 1 + 4 files changed, 39 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index c277b9fae950..188aaa97e5e3 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -4,6 +4,7 @@ */ #include <linux/clk.h> +#include <linux/dma-buf.h> #include <linux/dma-mapping.h> #include <linux/mailbox_controller.h> #include <linux/of.h> @@ -283,6 +284,23 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc, return NULL; } +static void mtk_drm_dma_buf_put(struct mtk_drm_crtc *mtk_crtc) +{ + unsigned int i; + + for (i = 0; i < mtk_crtc->layer_nr; i++) { + struct drm_plane *plane = &mtk_crtc->planes[i]; + struct mtk_plane_state *plane_state; + + plane_state = to_mtk_plane_state(plane->state); + + if (plane_state && plane_state->pending.dma_buf) { + dma_buf_put(plane_state->pending.dma_buf); + plane_state->pending.dma_buf = NULL; + } + } +} + #if IS_REACHABLE(CONFIG_MTK_CMDQ) static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg) { @@ -323,6 +341,8 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg) mtk_crtc->pending_async_planes = false; } + mtk_drm_dma_buf_put(mtk_crtc); + mtk_crtc->cmdq_vblank_cnt = 0; wake_up(&mtk_crtc->cb_blocking_queue); } @@ -627,9 +647,14 @@ static void mtk_crtc_ddp_irq(void *data) else if (mtk_crtc->cmdq_vblank_cnt > 0 && --mtk_crtc->cmdq_vblank_cnt == 0) DRM_ERROR("mtk_crtc %d CMDQ execute command timeout!\n", drm_crtc_index(&mtk_crtc->base)); + + if (!mtk_crtc->cmdq_client.chan) + mtk_drm_dma_buf_put(mtk_crtc); #else if (!priv->data->shadow_register) mtk_crtc_ddp_config(crtc, NULL); + + mtk_drm_dma_buf_put(mtk_crtc); #endif mtk_drm_finish_page_flip(mtk_crtc); } diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 2dfaa613276a..4fd232644383 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -1019,4 +1019,5 @@ module_exit(mtk_drm_exit); MODULE_AUTHOR("YT SHEN <yt.shen(a)mediatek.com>"); MODULE_DESCRIPTION("Mediatek SoC DRM driver"); +MODULE_IMPORT_NS(DMA_BUF); MODULE_LICENSE("GPL v2"); diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index ddc9355b06d5..fbfcd0d1a56c 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -12,6 +12,7 @@ #include <drm/drm_framebuffer.h> #include <drm/drm_gem_atomic_helper.h> #include <linux/align.h> +#include <linux/dma-buf.h> #include "mtk_drm_crtc.h" #include "mtk_drm_ddp_comp.h" @@ -283,6 +284,17 @@ static void mtk_plane_atomic_disable(struct drm_plane *plane, struct drm_plane_state *new_state = drm_atomic_get_new_plane_state(state, plane); struct mtk_plane_state *mtk_plane_state = to_mtk_plane_state(new_state); + struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(state, + plane); + + if (old_state && old_state->fb) { + struct drm_gem_object *gem = old_state->fb->obj[0]; + + if (gem && gem->dma_buf) { + get_dma_buf(gem->dma_buf); + mtk_plane_state->pending.dma_buf = gem->dma_buf; + } + } mtk_plane_state->pending.enable = false; wmb(); /* Make sure the above parameter is set before update */ mtk_plane_state->pending.dirty = true; diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h b/drivers/gpu/drm/mediatek/mtk_drm_plane.h index 99aff7da0831..3aba0b58ef3c 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h @@ -33,6 +33,7 @@ struct mtk_plane_pending_state { bool async_dirty; bool async_config; enum drm_color_encoding color_encoding; + struct dma_buf *dma_buf; }; struct mtk_plane_state { -- 2.25.1

2 years, 2 months

1
0
0 0

[PATCH] dma-buf: Replace strlcpy() with strscpy()

by Kees Cook

strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated[1]. Additionally, it returns the size of the source string, not the resulting size of the destination string. In an effort to remove strlcpy() completely[2], replace strlcpy() here with strscpy(). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [1] Link: https://github.com/KSPP/linux/issues/89 [2] Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Azeem Shaikh <azeemshaikh38(a)gmail.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/dma-buf/dma-buf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 21916bba77d5..8fe5aa67b167 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -46,12 +46,12 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) { struct dma_buf *dmabuf; char name[DMA_BUF_NAME_LEN]; - size_t ret = 0; + ssize_t ret = 0; dmabuf = dentry->d_fsdata; spin_lock(&dmabuf->name_lock); if (dmabuf->name) - ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); + ret = strscpy(name, dmabuf->name, sizeof(name)); spin_unlock(&dmabuf->name_lock); return dynamic_dname(buffer, buflen, "/%s:%s", -- 2.34.1

2 years, 2 months

3
2
0 0

[PATCH v2 0/8] dma-buf: heaps: Add secure heap

by Yong Wu

This patchset adds three secure heaps: 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). The buffer is reserved for the secure world after bootup and it is used for vcodec's ES/working buffer; 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is dynamically reserved for the secure world and will be got when we start playing secure videos, Once the security video playing is complete, the CMA will be released. This heap is used for the vcodec's frame buffer. 3) secure_cma: Use the kerne CMA ops as the allocation ops. currently it is a draft version for Vijay and Jaskaran. For the first two MediaTek heaps will be used v4l2[1] and drm[2], thus we cannot put it in v4l2 or drm, and create a common heap for them. Meanwhile We have a limited number of hardware entries to protect memory, we cannot protect memory arbitrarily, thus the secure memory management is actually inside OPTEE. The kernel just tells the TEE what size I want and the TEE will return a "secure handle". [1] https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@m… [2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin@… Change note: v2: 1) Move John's patches into the vcodec patchset since they use the new dma heap interface directly. https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@m… 2) Reword the dt-binding description. 3) Rename the heap name from mtk_svp to secure_mtk_cm. This means the current vcodec/DRM upstream code doesn't match this. 4) Add a normal CMA heap. currently it should be a draft version. 5) Regarding the UUID, I still use hard code, but put it in a private data which allow the others could set their own UUID. What's more, UUID is necessary for the session with TEE. If we don't have it, we can't communicate with the TEE, including the get_uuid interface, which tries to make uuid more generic, not working. If there is other way to make UUID more general, please free to tell me. v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@media… Base on v6.6-rc1. Yong Wu (8): dma-buf: heaps: Initialize a secure heap dma-buf: heaps: secure_heap: Add private heap ops dma-buf: heaps: secure_heap: Initialize tee session dma-buf: heaps: secure_heap: Add tee memory service call dma-buf: heaps: secure_heap: Add dma_ops dt-bindings: reserved-memory: Add secure CMA reserved memory range dma_buf: heaps: secure_heap: Add a new MediaTek CMA heap dma-buf: heaps: secure_heap: Add normal CMA heap .../reserved-memory/secure_cma_region.yaml | 44 ++ drivers/dma-buf/heaps/Kconfig | 7 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/secure_heap.c | 602 ++++++++++++++++++ 4 files changed, 654 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml create mode 100644 drivers/dma-buf/heaps/secure_heap.c -- 2.25.1

2 years, 2 months

7
22
0 0

Re: [PATCH v2 0/8] dma-buf: heaps: Add secure heap

by Jeffrey Kardatzke

The main goal is for secure video playback, and to also enable other potential uses of this in the future. The 'secure dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/unmappable by the non-secure (i.e. kernel/userspace) world. That memory will be used by the secure world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. Hope that helps. Cheers, Jeff On Mon, Nov 13, 2023 at 3:38 AM Pavel Machek <pavel(a)ucw.cz> wrote: > > Hi! > > > This patchset adds three secure heaps: > > 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). > > The buffer is reserved for the secure world after bootup and it is used > > for vcodec's ES/working buffer; > > 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is > > dynamically reserved for the secure world and will be got when we start > > playing secure videos, Once the security video playing is complete, the > > CMA will be released. This heap is used for the vcodec's frame buffer. > > 3) secure_cma: Use the kerne CMA ops as the allocation ops. > > currently it is a draft version for Vijay and Jaskaran. > > Is there high-level description of what the security goals here are, > somewhere? > > BR, > Pavel > -- > People of Russia, stop Putin before his war on Ukraine escalates.

2 years, 2 months

1
0
0 0

Re: [RFC PATCH v2] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi, On Tue, Nov 14, 2023 at 05:18:08PM +0100, Marco Pagani wrote: > On 2023-11-10 15:41, Maxime Ripard wrote: > > On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote: > >> This patch introduces an initial KUnit test suite for GEM objects > >> backed by shmem buffers. > >> > >> Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> > >> Signed-off-by: Marco Pagani <marpagan(a)redhat.com> > >> > >> v2: > >> - Improved description of test cases > >> - Cleaner error handling using KUnit actions > >> - Alphabetical order in Kconfig and Makefile > >> --- > >> drivers/gpu/drm/Kconfig | 9 +- > >> drivers/gpu/drm/tests/Makefile | 5 +- > >> drivers/gpu/drm/tests/drm_gem_shmem_test.c | 381 +++++++++++++++++++++ > >> 3 files changed, 389 insertions(+), 6 deletions(-) > >> create mode 100644 drivers/gpu/drm/tests/drm_gem_shmem_test.c > >> > >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > >> index 3eee8636f847..a2551c8c393a 100644 > >> --- a/drivers/gpu/drm/Kconfig > >> +++ b/drivers/gpu/drm/Kconfig > >> @@ -76,14 +76,15 @@ config DRM_KUNIT_TEST > >> tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS > >> depends on DRM && KUNIT > >> select PRIME_NUMBERS > >> + select DRM_BUDDY > >> select DRM_DISPLAY_DP_HELPER > >> select DRM_DISPLAY_HELPER > >> - select DRM_LIB_RANDOM > >> - select DRM_KMS_HELPER > >> - select DRM_BUDDY > >> + select DRM_EXEC > >> select DRM_EXPORT_FOR_TESTS if m > >> + select DRM_GEM_SHMEM_HELPER > >> + select DRM_KMS_HELPER > >> select DRM_KUNIT_TEST_HELPERS > >> - select DRM_EXEC > >> + select DRM_LIB_RANDOM > >> default KUNIT_ALL_TESTS > >> help > >> This builds unit tests for DRM. This option is not useful for > >> diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile > >> index ba7baa622675..d6183b3d7688 100644 > >> --- a/drivers/gpu/drm/tests/Makefile > >> +++ b/drivers/gpu/drm/tests/Makefile > >> @@ -9,15 +9,16 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \ > >> drm_connector_test.o \ > >> drm_damage_helper_test.o \ > >> drm_dp_mst_helper_test.o \ > >> + drm_exec_test.o \ > >> drm_format_helper_test.o \ > >> drm_format_test.o \ > >> drm_framebuffer_test.o \ > >> + drm_gem_shmem_test.o \ > >> drm_managed_test.o \ > >> drm_mm_test.o \ > >> drm_modes_test.o \ > >> drm_plane_helper_test.o \ > >> drm_probe_helper_test.o \ > >> - drm_rect_test.o \ > >> - drm_exec_test.o > >> + drm_rect_test.o > > > > Thanks for reordering the tests and symbols, but they should part of a > > preliminary patch. > > > > Okay, I'll send it as a separate patch before v3. Thanks for taking care of this. [...] > >> +/* > >> + * Wrappers to avoid an explicit type casting when passing action > >> + * functions to kunit_add_action(). > >> + */ > >> +static void kfree_wrapper(void *p) > >> +{ > >> + kfree(p); > >> +} > >> + > >> +static void sg_free_table_wrapper(void *sgt) > >> +{ > >> + sg_free_table(sgt); > >> +} > >> + > >> +static void drm_gem_shmem_free_wrapper(void *shmem) > >> +{ > >> + drm_gem_shmem_free(shmem); > >> +} > > > > I think you need to explicitly cast the pointer (or do a temporary > > assignment to the proper type) to avoid a compiler warning. > > > > Do you mean like: > > static void drm_gem_shmem_free_wrapper(void *shmem) > { > drm_gem_shmem_free((struct drm_gem_shmem_object *)shmem); > } yeah, or static void drm_gem_shmem_free_wrapper(void *ptr) { struct drm_gem_shmem_object *shmem = ptr; drm_gem_shmem_free(shmem); } > I built the current version with clang 16.0.6 and gcc 13.2.1 but got > no cast warnings. Clang spotted an uninitialized variable, though. The same thing happened to me, gcc didn't spot those issues but Intel's build bot did. They might run with extra warnings. Maxime

2 years, 2 months

1
0
0 0

Re: [PATCH] drm/nouveau: Prevents NULL pointer dereference in nouveau_uvmm_sm_prepare

by Danilo Krummrich

Hi Yuran, On 10/26/23 19:03, Yuran Pereira wrote: > There are instances where the "args" argument passed to > nouveau_uvmm_sm_prepare() is NULL. > > I.e. when nouveau_uvmm_sm_prepare() is called from > nouveau_uvmm_sm_unmap_prepare() > > ``` > static int > nouveau_uvmm_sm_unmap_prepare(struct nouveau_uvmm *uvmm, > ... > { > return nouveau_uvmm_sm_prepare(uvmm, new, ops, NULL); > } > ``` > > The problem is that op_map_prepare() which nouveau_uvmm_sm_prepare > calls, dereferences this value, which can lead to a NULL pointer > dereference. op_map_prepare() can't be called with `args` being NULL, since when called through nouveau_uvmm_sm_unmap_prepare() we can't hit the DRM_GPUVA_OP_MAP case at all. Unmapping something never leads to a new mapping being created, it can lead to remaps though. > > ``` > static int > op_map_prepare(struct nouveau_uvmm *uvmm, > ... > { > ... > uvma->region = args->region; <-- Dereferencing of possibly NULL pointer > uvma->kind = args->kind; <-- > ... > } > ``` > > ``` > static int > nouveau_uvmm_sm_prepare(struct nouveau_uvmm *uvmm, > ... > struct uvmm_map_args *args) > { > struct drm_gpuva_op *op; > u64 vmm_get_start = args ? args->addr : 0; > u64 vmm_get_end = args ? args->addr + args->range : 0; > int ret; > > drm_gpuva_for_each_op(op, ops) { > switch (op->op) { > case DRM_GPUVA_OP_MAP: { > u64 vmm_get_range = vmm_get_end - vmm_get_start; > > ret = op_map_prepare(uvmm, &new->map, &op->map, args); <--- > if (ret) > goto unwind; > > if (args && vmm_get_range) { > ret = nouveau_uvmm_vmm_get(uvmm, vmm_get_start, > vmm_get_range); > if (ret) { > op_map_prepare_unwind(new->map); > goto unwind; > } > } > ... > ``` > > Since the switch "case DRM_GPUVA_OP_MAP", also NULL checks "args" This check is not required for the reason given above. If you like, you can change this patch up to remove the args check and add a comment like: /* args can't be NULL when called for a map operation. */ > after the call to op_map_prepare(), my guess is that we should > probably relocate this check to a point before op_map_prepare() > is called. Yeah, I see how this unnecessary check made you think so. - Danilo > > This patch ensures that the value of args is checked before > calling op_map_prepare() > > Addresses-Coverity-ID: 1544574 ("Dereference after null check") > Signed-off-by: Yuran Pereira <yuran.pereira(a)hotmail.com> > --- > drivers/gpu/drm/nouveau/nouveau_uvmm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c b/drivers/gpu/drm/nouveau/nouveau_uvmm.c > index aae780e4a4aa..6baa481eb2c8 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c > @@ -620,11 +620,14 @@ nouveau_uvmm_sm_prepare(struct nouveau_uvmm *uvmm, > case DRM_GPUVA_OP_MAP: { > u64 vmm_get_range = vmm_get_end - vmm_get_start; > > + if (!args) > + goto unwind; > + > ret = op_map_prepare(uvmm, &new->map, &op->map, args); > if (ret) > goto unwind; > > - if (args && vmm_get_range) { > + if (vmm_get_range) { > ret = nouveau_uvmm_vmm_get(uvmm, vmm_get_start, > vmm_get_range); > if (ret) {

2 years, 2 months

1
0
0 0

Re: [RFC PATCH v3 12/12] selftests: add ncdevmem, netcat for devmem TCP

by Jakub Kicinski

On Sun, 12 Nov 2023 20:08:10 -0800 Mina Almasry wrote: > 1. For (b), would it be OK to implement a very minimal version of > queue_[stop|start]/queue_mem_[alloc|free], which I use for the sole > purpose of reposting buffers to an individual queue, and then later > whoever picks up your queue API effort (maybe me) extends the > implementation to do the rest of the things you described in your > email? If not, what is the minimal queue API I can implement and use > for devmem TCP? Any form of queue API is better than a temporary ndo. IIUC it will not bubble up into uAPI in any way so we can extend/change it later as needed. > 2. Since this is adding ndo, do I need to implement the ndo for 2 > drivers or is GVE sufficient? One driver is fine, especially if we're doing this instead of the reset hack.

2 years, 2 months

1
0
0 0

Re: [RFC PATCH v3 08/12] net: support non paged skb frags

by Jakub Kicinski

On Sun, 12 Nov 2023 22:05:30 -0800 Mina Almasry wrote: > My issue here is that all these skb helpers call each other so I end > up having to move a lot of the unrelated skb helpers to this new > header (maybe that is acceptable but it feels weird). Splitting pp headers again is not an option, we already split it into types and helpers. The series doesn't apply and it's a bit hard for me to, in between LPC talks, figure out how to extract your patches from the GH UI to take a proper look :( We can defer this for now, and hopefully v4 will apply to net-next. But it will need to get solved.

2 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig