NetBSD Problem Report #58898
From www@netbsd.org Thu Dec 12 15:51:28 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id B6EE11A923C
for <gnats-bugs@gnats.NetBSD.org>; Thu, 12 Dec 2024 15:51:27 +0000 (UTC)
Message-Id: <20241212155125.F2F011A923D@mollari.NetBSD.org>
Date: Thu, 12 Dec 2024 15:51:25 +0000 (UTC)
From: kikadf.01@gmail.com
Reply-To: kikadf.01@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Crash when testing camera in chromium
X-Send-Pr-Version: www-1.0
>Number: 58898
>Category: kern
>Synopsis: Crash when testing camera in chromium
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: needs-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 12 15:55:00 +0000 2024
>Closed-Date:
>Last-Modified: Wed Feb 19 00:52:56 +0000 2025
>Originator: Robert Bagdan
>Release: 10.0_STABLE (GENERIC)
>Organization:
-
>Environment:
NetBSD test 10.0_STABLE NetBSD 10.0_STABLE (GENERIC) #0: Fri Dec 6 20:38:43 UTC 2024 mkrepro@mkrepro.NetBSD.org :/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
I’m porting chromium to NetBSD, but I got a random system crash when testing camera support.
I try to found the problem:
1) cd /var/crash && sudo gunzip -d *gz
2) sudo dmesg -M netbsd.4.core -N netbsd.4
[ 429.761546] video_enum_framesizes: type mismatch 56595559 47504a4d
… (919 messages from video_enum_framesizes)
[ 512.917593] fatal protection fault in supervisor mode
[ 512.917593] trap type 4 code 0 rip 0xffffffff80db14f4 cs 0x8 rflags 0x10206 cr2 0x7dbd48c2e600 ilevel 0 rsp 0xffffc18242975d40
[ 512.917593] curlwp 0xffffe53d60a3ca00 pid 3297.3302 lowest kstack 0xffffc182429712c0
[ 512.917593] panic: trap
[ 512.917593] cpu2: Begin traceback...
[ 512.918047] vpanic() at netbsd:vpanic+0x183
[ 512.919505] panic() at netbsd:panic+0x3c
[ 512.920481] trap() at netbsd:trap+0xbaf
[ 512.920481] --- trap (number 4) ---
[ 512.920969] videoclose() at netbsd:videoclose+0xbb
[ 512.921941] cdev_close() at netbsd:cdev_close+0x92
[ 512.922414] spec_close() at netbsd:spec_close+0x188
[ 512.923403] VOP_CLOSE() at netbsd:VOP_CLOSE+0x44
[ 512.924378] vn_close() at netbsd:vn_close+0x51
[ 512.924873] closef() at netbsd:closef+0x58
[ 512.925838] fd_close() at netbsd:fd_close+0x140
[ 512.926349] sys_close() at netbsd:sys_close+0x22
[ 512.927307] syscall() at netbsd:syscall+0x1fc
[ 512.927770] --- syscall (number 6) ---
[ 512.927770] netbsd:syscall+0x1fc:
[ 512.927770] cpu2: End traceback...
[ 512.928265] dumping to dev 168,1 (offset=8, size=2097039):
[ 512.928265] dump
3) sudo gdb /netbsd --eval-command="target kvm netbsd.4.core"
GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /netbsd...
Reading symbols from /usr/libdata/debug//netbsd-GENERIC.debug...
0xffffffff80239985 in cpu_reboot (howto=260, bootstr=<optimized out>) at /usr/src/sys/arch/amd64/amd64/machdep.c:717
warning: Source file is more recent than executable.
717 dumpsys();
(gdb) bt
#0 0xffffffff80239985 in cpu_reboot (howto=260, bootstr=<optimized out>)
at /usr/src/sys/arch/amd64/amd64/machdep.c:717
#1 0xffffffff80ce5a9b in debugged_child_exists (parent=0x104, si=0xffffd2fccac4d400, options=260, id=0, idtype=1112612864) at /usr/src/sys/kern/kern_exit.c:986
#2 find_stopped_child (si=0xffffd2fccac4d400, wru=0x0, child_p=<synthetic pointer>, options=260, id=0,
idtype=1112612864, parent=0x104) at /usr/src/sys/kern/kern_exit.c:1124
#3 do_sys_waitid (idtype=<optimized out>, id=<optimized out>, pid=<optimized out>, status=<optimized out>,
options=260, wru=0x0, si=<optimized out>) at /usr/src/sys/kern/kern_exit.c:673
#4 0xffffffff80d1be6f in device_pmf_driver_deregister (dev=<unavailable>) at /usr/src/sys/kern/subr_autoconf.c:3182
#5 0xffffffff80d1bf44 in device_pmf_lock1 (dev=0xffffd2fceb993b00) at ./machine/cpu.h:72
#6 device_pmf_lock (dev=0xffffd2fceb993b00) at /usr/src/sys/kern/subr_autoconf.c:3269
#7 0xffffffff8023c155 in trap (frame=0x0) at /usr/src/sys/arch/amd64/amd64/trap.c:326
#8 0xffffffff80234a7b in alltraps ()
#9 0xffffd2fca47ec3c8 in ?? ()
#10 0xffffd2fca455c080 in ?? ()
#11 0xffffd2fca47ec3a0 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb) list *0xffffffff80db14f4
0xffffffff80db14f4 is in videoclose (/usr/src/sys/dev/video.c:2481).
warning: Source file is more recent than executable.
2476 "tearing down bufs while streaming\n"));
2477 }
2478
2479 /* dequeue all buffers */
2480 while (SIMPLEQ_FIRST(&vs->vs_ingress) != NULL)
2481 SIMPLEQ_REMOVE_HEAD(&vs->vs_ingress, entries);
2482 while (SIMPLEQ_FIRST(&vs->vs_egress) != NULL)
2483 SIMPLEQ_REMOVE_HEAD(&vs->vs_egress, entries);
2484
2485 err = video_stream_free_bufs(vs);
(gdb)
I got this system crash only on chromium, firefox with the same steps did not cause system crash. I checked the differences in the codebases, I found chromium uses VIDIOC_ENUM_FRAMEINTERVALS and VIDIOC_ENUM_FRAMESIZES, while firefox does not. I don’t know is it relevant, but my dmesg output has many “video_enum_framesizes: type mismatch 47504a4d 56595559” lines, what is come from video_enum_framesizes():https://github.com/NetBSD/src/blob/52fe981959bae952bc9fc0d6e7829963ece5abbc/sys/dev/video.c#L830.
>How-To-Repeat:
1) Build chromium from pkgsrc-wip/chromium (many hours as it is a kaiju..)
2) Open in chromium the https://webcamtests.com/ page, and run the testing
3) Not always but often I got a system crash while the test is running
>Fix:
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Robert Bagdan <kikadf.01@gmail.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/58898: Crash when testing camera in chromium
Date: Thu, 12 Dec 2024 16:01:15 +0000
Can you please share the output of dmesg and the following gdb
commands on the crash dump?
(gdb) disas *(videoclose+0xbb)
(gdb) print *(struct video_softc *)video_cd.cd_devs[0]->dv_private
Can you share the disassembly of videoclose in your netbsd.4 kernel
with `objdump -dr netbsd.4' (and selecting the relevant part)?
Can you share what changes you have in your tree? And can you make
sure you have a clean build? It looks like there might be mismatches
between your netbsd.gdb, your netbsd.4.core, and the source code,
which risks send everyone on wild goose chases if not resolved.
From: Robert Bagdan <kikadf.01@gmail.com>
To: Taylor R Campbell <riastradh@netbsd.org>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58898: Crash when testing camera in chromium
Date: Thu, 12 Dec 2024 18:46:43 +0100
On Thu, Dec 12, 2024 at 5:01=E2=80=AFPM Taylor R Campbell <riastradh@netbsd=
.org> wrote:
>
> Can you please share the output of dmesg and the following gdb
> commands on the crash dump?
>
> (gdb) disas *(videoclose+0xbb)
> (gdb) print *(struct video_softc *)video_cd.cd_devs[0]->dv_private
>
> Can you share the disassembly of videoclose in your netbsd.4 kernel
> with `objdump -dr netbsd.4' (and selecting the relevant part)?
>
> Can you share what changes you have in your tree? And can you make
> sure you have a clean build? It looks like there might be mismatches
> between your netbsd.gdb, your netbsd.4.core, and the source code,
> which risks send everyone on wild goose chases if not resolved.
I don't have changes in NetBSD tree, I=E2=80=99m on the 10.0 branch, upgrad=
ed
with sysupgrade auto. Here is my /etc/release relevant part:
Build information:
Build date Fri Dec 6 20:38:43 UTC 2024
Built by builder@localhost.NetBSD.org
Build ID 202412081740Z
Because of the gdb output, I=E2=80=99m just clone the NetBSD src from githu=
b,
this is the git log output:
commit 313a9eb5b1b8b899e5611e78063c2949affc811d (HEAD -> netbsd-10,
origin/netbsd-10)
Author: snj <snj@NetBSD.org>
Date: Fri Dec 6 20:38:43 2024 +0000
tickets 1024-1026
=E2=80=A6
Some dates and sizes:
/var/crash $ ls -l netbsd.4*
-rw------- 1 root wheel 2428478 Dec 9 13:02 netbsd.4
-rw------- 1 root wheel 583708184 Dec 9 13:02 netbsd.4.core
ls -l /netbsd
-rw-r--r-- 1 root wheel 29528376 Dec 9 12:48 /netbsd
I share =E2=80=98dmesg -M netbsd.4.core -N netbsd.4 > dmesg.txt=E2=80=99 in
https://pastebin.com/raw/jWLjzQbw . This is all that I got.
I run =E2=80=98gdb /netbsd --eval-command=3D"target kvm netbsd.4.core"=E2=
=80=99, then
your suggested gdb commands, I share the output in
https://pastebin.com/raw/wQL0uN0z .
The =E2=80=98objdump -dr netbsd.4=E2=80=99 all output:
netbsd.4: file format elf64-x86-64
>From =E2=80=98objdump -dr /netbsd=E2=80=99 I share the videoclose part in
https://pastebin.com/raw/aXzSvGC1 .
From: Robert Bagdan <kikadf.01@gmail.com>
To: Taylor R Campbell <riastradh@netbsd.org>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58898: Crash when testing camera in chromium
Date: Thu, 12 Dec 2024 19:43:46 +0100
--000000000000d7fa08062917180f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 12, 2024 at 5:01=E2=80=AFPM Taylor R Campbell <riastradh@netbsd=
.org>
wrote:
>
> Can you please share the output of dmesg and the following gdb
> commands on the crash dump?
>
> (gdb) disas *(videoclose+0xbb)
> (gdb) print *(struct video_softc *)video_cd.cd_devs[0]->dv_private
>
> Can you share the disassembly of videoclose in your netbsd.4 kernel
> with `objdump -dr netbsd.4' (and selecting the relevant part)?
>
> Can you share what changes you have in your tree? And can you make
> sure you have a clean build? It looks like there might be mismatches
> between your netbsd.gdb, your netbsd.4.core, and the source code,
> which risks send everyone on wild goose chases if not resolved.
(I resend my last message because it was unreadable, sorry)
I don't have changes in NetBSD tree, I=E2=80=99m on the 10.0 branch, upgrad=
ed
with sysupgrade auto. Here is my /etc/release relevant part:
Build information:
Build date Fri Dec 6 20:38:43 UTC 2024
Built by builder@localhost.NetBSD.org
Build ID 202412081740Z
Because of the gdb output, I=E2=80=99m just clone the NetBSD src from githu=
b,
this is the git log output:
commit 313a9eb5b1b8b899e5611e78063c2949affc811d (HEAD -> netbsd-10,
origin/netbsd-10)
Author: snj <snj@NetBSD.org>
Date: Fri Dec 6 20:38:43 2024 +0000
tickets 1024-1026
=E2=80=A6
Some date and sizes:
/var/crash $ ls -l netbsd.4*
-rw------- 1 root wheel 2428478 Dec 9 13:02 netbsd.4
-rw------- 1 root wheel 583708184 Dec 9 13:02 netbsd.4.core
ls -l /netbsd
-rw-r--r-- 1 root wheel 29528376 Dec 9 12:48 /netbsd
I share =E2=80=98dmesg -M netbsd.4.core -N netbsd.4 > dmesg.txt=E2=80=99
in https://pastebin.com/raw/jWLjzQbw . This is all that I got.
I run =E2=80=98gdb /netbsd --eval-command=3D"target kvm netbsd.4.core"=E2=
=80=99,
then your suggested gdb commands,
I share the output in https://pastebin.com/raw/wQL0uN0z .
The =E2=80=98objdump -dr netbsd.4=E2=80=99 all output:
netbsd.4: file format elf64-x86-64
>From =E2=80=98objdump -dr /netbsd=E2=80=99 I share the videoclose part
in https://pastebin.com/raw/aXzSvGC1 .
--000000000000d7fa08062917180f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thu, Dec 12, 2024 at 5:01=E2=80=AFPM Taylor R C=
ampbell <<a href=3D"mailto:riastradh@netbsd.org">riastradh@netbsd.org</a=
>> wrote:<br>><br>> Can you please share the output of dmesg and t=
he following gdb<br>> commands on the crash dump?<br>><br>> (gdb) =
disas *(videoclose+0xbb)<br>> (gdb) print *(struct video_softc *)video_c=
d.cd_devs[0]->dv_private<br>><br>> Can you share the disassembly o=
f videoclose in your netbsd.4 kernel<br>> with `objdump -dr netbsd.4'=
; (and selecting the relevant part)?<br>><br>> Can you share what cha=
nges you have in your tree?=C2=A0 And can you make<br>> sure you have a =
clean build?=C2=A0 It looks like there might be mismatches<br>> between =
your netbsd.gdb, your netbsd.4.core, and the source code,<br>> which ris=
ks send everyone on wild goose chases if not resolved.<br><br>(I resend my =
last message because it was unreadable, sorry)<br><br>I don't have chan=
ges in NetBSD tree, I=E2=80=99m on the 10.0 branch, upgraded=C2=A0<div>with=
sysupgrade auto. Here is my /etc/release relevant part:<br>Build informati=
on:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Build date =C2=A0 Fri Dec =C2=A06 =
20:38:43 UTC 2024<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Built by =C2=
=A0 <a href=3D"mailto:builder@localhost.NetBSD.org">builder@localhost.NetBS=
D.org</a><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Build ID =C2=A0 20241=
2081740Z<br><br>Because of the gdb output, I=E2=80=99m just clone the NetBS=
D src from github,</div><div>this is the git log output:<br>commit 313a9eb5=
b1b8b899e5611e78063c2949affc811d (HEAD -> netbsd-10, origin/netbsd-10)<b=
r>Author: snj <snj@NetBSD.org><br>Date: =C2=A0 Fri Dec 6 20:38:43 202=
4 +0000<br><br>=C2=A0 =C2=A0tickets 1024-1026<br>=E2=80=A6<br><br>Some date=
and sizes:<br>/var/crash $ ls -l netbsd.4* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 <br>-rw------- =C2=A01 root =C2=A0wheel =C2=A0 =C2=
=A02428478 Dec =C2=A09 13:02 netbsd.4<br>-rw------- =C2=A01 root =C2=A0whee=
l =C2=A0583708184 Dec =C2=A09 13:02 netbsd.4.core<br>ls -l /netbsd<br>-rw-r=
--r-- =C2=A01 root =C2=A0wheel =C2=A029528376 Dec =C2=A09 12:48 /netbsd<br>=
<br>I share =E2=80=98dmesg -M netbsd.4.core -N netbsd.4 > dmesg.txt=E2=
=80=99=C2=A0</div><div>in <a href=3D"https://pastebin.com/raw/jWLjzQbw">htt=
ps://pastebin.com/raw/jWLjzQbw</a> . This is all that I got.<br><br>I run =
=E2=80=98gdb /netbsd --eval-command=3D"target kvm netbsd.4.core"=
=E2=80=99,</div><div>then your suggested gdb commands,</div><div>=C2=A0I sh=
are the output in <a href=3D"https://pastebin.com/raw/wQL0uN0z">https://pas=
tebin.com/raw/wQL0uN0z</a> .<br><br>The =E2=80=98objdump -dr netbsd.4=E2=80=
=99 all output:<br>netbsd.4: =C2=A0 =C2=A0 file format elf64-x86-64<br><br>=
>From =E2=80=98objdump -dr /netbsd=E2=80=99 I share the videoclose part</div=
><div> in <a href=3D"https://pastebin.com/raw/aXzSvGC1">https://pastebin.co=
m/raw/aXzSvGC1</a> .<br><br><br></div></div>
--000000000000d7fa08062917180f--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Robert Bagdan <kikadf.01@gmail.com>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58898: Crash when testing camera in chromium
Date: Thu, 12 Dec 2024 19:21:55 +0000
> Date: Thu, 12 Dec 2024 18:46:43 +0100
> From: Robert Bagdan <kikadf.01@gmail.com>
>=20
> I don't have changes in NetBSD tree, I'm on the 10.0 branch, upgraded
> with sysupgrade auto. Here is my /etc/release relevant part:
> Build information:
> Build date Fri Dec 6 20:38:43 UTC 2024
> Built by builder@localhost.NetBSD.org
> Build ID 202412081740Z
>=20
> Because of the gdb output, I'm just clone the NetBSD src from github,
> this is the git log output:
> commit 313a9eb5b1b8b899e5611e78063c2949affc811d (HEAD -> netbsd-10,
> origin/netbsd-10)
> Author: snj <snj@NetBSD.org>
> Date: Fri Dec 6 20:38:43 2024 +0000
>=20
> tickets 1024-1026
Thanks, glad to confirm that! It was suspicious because the stack
trace in gdb doesn't make sense and gdb warned about source newer than
object file.
> Some dates and sizes:
> /var/crash $ ls -l netbsd.4*
> -rw------- 1 root wheel 2428478 Dec 9 13:02 netbsd.4
> -rw------- 1 root wheel 583708184 Dec 9 13:02 netbsd.4.core
> ls -l /netbsd
> -rw-r--r-- 1 root wheel 29528376 Dec 9 12:48 /netbsd
>=20
> I share `dmesg -M netbsd.4.core -N netbsd.4 > dmesg.txt' in
> https://pastebin.com/raw/jWLjzQbw . This is all that I got.
>=20
> I run `gdb /netbsd --eval-command=3D"target kvm netbsd.4.core"', then
> your suggested gdb commands, I share the output in
> https://pastebin.com/raw/wQL0uN0z .
Thanks!
So it looks like it is here:
2479 /* dequeue all buffers */
2480 while (SIMPLEQ_FIRST(&vs->vs_ingress) !=3D NULL)
=3D> 2481 SIMPLEQ_REMOVE_HEAD(&vs->vs_ingress, entries);
2482 while (SIMPLEQ_FIRST(&vs->vs_egress) !=3D NULL)
2483 SIMPLEQ_REMOVE_HEAD(&vs->vs_egress, entries);
https://nxr.netbsd.org/xref/src/sys/dev/video.c?r=3D1.45#2481
Here's the disassembly:
0xffffffff80db14df <+166>: call 0xffffffff8023fac0 <mutex_enter>
0xffffffff80db14e4 <+171>: mov 0xa0(%rbx),%rax
0xffffffff80db14eb <+178>: lea 0xa0(%rbx),%rdx
0xffffffff80db14f2 <+185>: jmp 0xffffffff80db1504 <videoclose+203>
=3D> 0xffffffff80db14f4 <+187>: mov 0x8(%rax),%rax
0xffffffff80db14f8 <+191>: mov %rax,0xa0(%rbx)
0xffffffff80db14ff <+198>: test %rax,%rax
0xffffffff80db1502 <+201>: je 0xffffffff80db1578 <videoclose+319>
0xffffffff80db1504 <+203>: test %rax,%rax
0xffffffff80db1507 <+206>: jne 0xffffffff80db14f4 <videoclose+187>
...
0xffffffff80db1578 <+319>: mov %rdx,0xa8(%rbx)
0xffffffff80db157f <+326>: jmp 0xffffffff80db1509 <videoclose+208>
(The DPRINTF has presumably been compiled away, so there's no `if
(vs->vs_streaming)' branch in the code.)
We have:
(gdb) print &((struct video_softc *)0)->sc_stream_in.vs_ingress
$2 =3D (struct sample_queue *) 0xa0
(gdb) print &((struct video_buffer *)0)->entries->sqe_next
$3 =3D (struct video_buffer **) 0x8
And the crash is:
[ 512.917593] trap type 4 code 0 rip 0xffffffff80db14f4 cs 0x8 rflags 0x1=
0206 cr2 0x7dbd48c2e600 ilevel 0 rsp 0xffffc18242975d40
[ 512.917593] curlwp 0xffffe53d60a3ca00 pid 3297.3302 lowest kstack 0xfff=
fc182429712c0
So one of the vs_ingress buffers has been corrupted: rax hold the
pointer to a struct video_buffer, and the CPU faulted at
mov 0x8(%rax),%rax
with cr2=3D0x7dbd48c2e600 as the fault address. That's not a kernel
virtual address so the kernel has no business dereferencing it (except
via copyout/copyin or similar).
Now this cr2 value is interesting, because according to gdb:
(gdb) print *(struct video_softc *)video_cd.cd_devs[0]->dv_private
$1 =3D {... sc_stream_in =3D {...
... vs_ingress =3D {sqh_first =3D 0x5fffffe53d0009, ...}, ...}, ...}
That is _also_ not a kva, but it's not the one in cr2!
Now I checked the ioctls VIDIOC_ENUM_FRAMESIZES and
VIDIOC_ENUM_FRAMEINTERVALS, and they don't look like they do anything
interesting. But videoread looks racy:
1826 mutex_enter(&vs->vs_lock);
...
1845 vb =3D SIMPLEQ_FIRST(&vs->vs_egress);
1846 } else {
1847 vb =3D SIMPLEQ_FIRST(&vs->vs_egress);
1848 }
...
1858 mutex_exit(&vs->vs_lock);
1859=20
1860 len =3D uimin(uio->uio_resid, vb->vb_buf->bytesused - vs->vs_bytes=
read);
1861 offset =3D vb->vb_buf->m.offset + vs->vs_bytesread;
1862=20
1863 if (scatter_io_init(&vs->vs_data, offset, len, &sio)) {
1864 err =3D scatter_io_uiomove(&sio, uio);
1865 if (err =3D=3D EFAULT)
1866 return EFAULT;
1867 vs->vs_bytesread +=3D (len - sio.sio_resid);
...
1874 if (vs->vs_bytesread >=3D vb->vb_buf->bytesused) {
1875 mutex_enter(&vs->vs_lock);
1876 vb =3D video_stream_dequeue(vs);
1877 video_stream_enqueue(vs, vb);
1878 mutex_exit(&vs->vs_lock);
https://nxr.netbsd.org/xref/src/sys/dev/video.c?r=3D1.45#1826
As far as I can tell, there is nothing preventing two threads from
entering videoread concurrently and then handling the _same_ vb from
the egress queue. I don't see an obvious limit to how much damage
could be caused by that, since it controls uiomove pointers and
lengths.
It is important to drop the lock across uiomove if that can trigger
swapping, e.g. in copyin/copyout in case the user's pages are swapped
out, which requires blocking on I/O which can be indefinite. But it
is also critical for access to each vb here to be serialized. Maybe
there should be a vs_iobusy `lock' taken and released by videoread,
handled under vs_lock and signalled by vs_read_cv or something, so
only one videoread can be running at a time.
This doesn't necessarily explain your crash -- I don't know whether
Chromium tries to read from the same /dev/video instance in more than
one thread -- but it's definitely a bug that we need to fix.
From: Robert Bagdan <kikadf.01@gmail.com>
To: Taylor R Campbell <riastradh@netbsd.org>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58898: Crash when testing camera in chromium
Date: Sun, 22 Dec 2024 16:10:26 +0100
I upgraded to NetBSD 10.1, the packages to the actual pkgsrc -trunk,
and made a clean chromium build.
Now I can't reproduce the system crash with testing camera in chromium.
Maybe my chromium tree was broken or something, but now it works fine.
Seems, I found this bug because of a "lucky" accidental.
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 19 Feb 2025 00:52:56 +0000
State-Changed-Why:
I wanted to do a little more analysis and testing of this change, but
ran out of round tuits, so mlelstv@ just committed his version of it
(at my request):
Module Name: src
Committed By: mlelstv
Date: Sun Feb 16 21:09:00 UTC 2025
Modified Files:
src/sys/dev: video.c
Log Message:
When dropping lock around scatter_io_uiomove(), use busy flag
to serialize operations.
Hold lock while accessing video_stream and video_buffer.
To generate a diff of this commit:
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/video.c
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home