Re: NULL pointer dereference at v4l2_ctrl_request_complete

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans,

On Wed, 31 Mar 2021 at 13:14, Ezequiel Garcia
<ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Hans,
>
> We have found this crash in mainline:
>
> [  258.174662] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000000
> [  258.182967] Mem abort info:
> [  258.187746]   ESR = 0x96000004
> [  258.192100]   EC = 0x25: DABT (current EL), IL = 32 bits
> [  258.199108]   SET = 0, FnV = 0
> [  258.203732]   EA = 0, S1PTW = 0
> [  258.208389] Data abort info:
> [  258.212743]   ISV = 0, ISS = 0x00000004
> [  258.218322]   CM = 0, WnR = 0
> [  258.222760] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000444b0000
> [  258.230822] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
> [  258.239097] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [  258.246162] Modules linked in: hantro_vpu(C) videobuf2_vmalloc
> v4l2_h264 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem
> videobuf2_v4l2 videobuf2_common videodev mc etnaviv fsl_imx8_ddr_perf
> gpu_sched fuse
> [  258.263431] CPU: 0 PID: 34 Comm: kworker/0:1 Tainted: G         C
>      5.12.0-rc2+ #106
> [  258.270312] Hardware name: NXP i.MX8MQ EVK (DT)
> [  258.273542] Workqueue: events v4l2_m2m_device_run_work [v4l2_mem2mem]
> [  258.278716] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
> [  258.283426] pc : __memcpy+0x7c/0x180
> [  258.285709] lr : v4l2_ctrl_request_complete+0x7c/0x200 [videodev]
> [  258.290585] sp : ffff8000116fbc60
> [  258.292598] x29: ffff8000116fbc60 x28: ffff80001142b780
> [  258.296617] x27: ffff80001127bc80 x26: 00000000e9b00000
> [  258.300637] x25: 00000000e9a00000 x24: ffff0000067e2500
> [  258.304653] x23: ffff0000067e2538 x22: ffff00000387d238
> [  258.308671] x21: ffff0000067e2598 x20: ffff000004644e00
> [  258.312688] x19: ffff000006812a00 x18: 0000000000000000
> [  258.316708] x17: 0000000000000000 x16: 0000000000000000
> [  258.320724] x15: 0000000000000000 x14: 0000000000000000
> [  258.324744] x13: 0000000000000000 x12: 0000000000000000
> [  258.328761] x11: 0000000000000000 x10: 0000000000000000
> [  258.332776] x9 : 0000000000000000 x8 : 0000000000000000
> [  258.336793] x7 : 0000000000000000 x6 : ffff000006812a40
> [  258.340811] x5 : 0000000000000006 x4 : 0000000000000000
> [  258.344826] x3 : 0000000000000010 x2 : 0000000000000010
> [  258.348845] x1 : 0000000000000000 x0 : ffff000006812a40
> [  258.352864] Call trace:
> [  258.354010]  __memcpy+0x7c/0x180
> [  258.355941]  hantro_end_prepare_run+0x2c/0x60 [hantro_vpu]
> [  258.360150]  hantro_g1_mpeg2_dec_run+0x3b0/0x7f0 [hantro_vpu]
> [  258.364615]  device_run+0xa8/0xbc [hantro_vpu]
> [  258.367777]  v4l2_m2m_try_run+0x84/0x134 [v4l2_mem2mem]
> [  258.371723]  v4l2_m2m_device_run_work+0x14/0x20 [v4l2_mem2mem]
> [  258.376279]  process_one_work+0x1c0/0x484
> [  258.378995]  worker_thread+0x70/0x434
> [  258.381364]  kthread+0x158/0x160
> [  258.383296]  ret_from_fork+0x10/0x34
> [  258.385582] Code: a8c12027 a88120c7 a8c12027 a88120c7 (a8c12027)
> [  258.390377] ---[ end trace fea6ecb96dad642d ]---
>
> This needs several concurrent streams to run at the same time,
> it doesn't happen with just one; it was reproduced in rkvdec
> and hantro drivers. The above stacktrace is on MPEG-2,
> but we have found it on H.264 as well.
>
> I've traced this to:
>
>                 v4l2_ctrl_lock(ctrl);
>                 if (ref->req) {
>                         ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
>
> And:
>
> static void ptr_to_ptr(struct v4l2_ctrl *ctrl,
>                        union v4l2_ctrl_ptr from, union v4l2_ctrl_ptr to)
> {
>         if (ctrl == NULL)
>                 return;
>         memcpy(to.p, from.p_const, ctrl->elems * ctrl->elem_size);
>                                ^^^^^^^^^^^^
>                                This is NULL
>
> I've been staring at this file and trying to understand how this can happen
> but haven't been able to make any progress so far...
>
> Any ideas ?
>

This issue may be somehow linked to controls that haven't been set,
and thus have their initialization value.

My traces indicate that the controls with NULL values are those
that GStreamer is not setting. I can confirm that by re-testing
with GStreamer setting all the controls always.

Thanks,
Ezequiel



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux