Re: NULL pointer dereference at v4l2_ctrl_request_complete

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

 



On Thu, Apr 1, 2021 at 9:23 AM Alexandre Courbot <acourbot@xxxxxxxxxxxx> wrote:
>
> Hi Ezequiel,
>
> On Thu, Apr 1, 2021 at 7:35 AM Ezequiel Garcia
> <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > 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.
>
> If I am not mixing up issues then the following patch should fix this:
>
> https://patchwork.linuxtv.org/project/linux-media/patch/ce92a438-4708-74a0-8fb4-c8fb6495e6b8@xxxxxxxxx/

... or maybe not. I just ran into the same crash after applying it
locally, so guess I was just lucky for a short while. :/



[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