Date: Sun, 15 Sep 2024 20:48:28 -0700 From: Mark Millard <marklmi@yahoo.com> To: Graham Perrin <grahamperrin@gmail.com>, Current FreeBSD <freebsd-current@freebsd.org> Subject: =?utf-8?Q?RE=3A_Chromium_with_Widevine=3A_kernel_panic=3A_conditi?= =?utf-8?Q?on_vp-=3E_v=5Ftype_=3D=3D_VDIR_=7C=7C_VN=5FIS=5FDOOMED=28vp=29_?= =?utf-8?Q?not_met_=E2=8B=AFvfs=5Fcache=2Ec=3A34_52_=28vn=5Ffullpath=5Fdir?= =?utf-8?Q?=29?= Message-ID: <63DE0143-2113-419A-9DBC-516940859206@yahoo.com> References: <63DE0143-2113-419A-9DBC-516940859206.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Graham Perrin <grahamperrin_at_gmail.com> wrote on Date: Wed, 22 May 2024 20:32:42 UTC : > Reproducible at <https://bitmovin.com/demos/drm>. >=20 > <https://codeberg.org/grahamperrin/freebsd-src/issues/10>; This is a list message that is directly explicit about various things in the report instead of being indirect. The GENERIC panics are at the VNPASS indicated below in sys/kern/vfs_cache.c : /* * Resolve a directory to a pathname. *=20 * The name of the directory can always be found in the namecache or = fetched * from the filesystem. There is also guaranteed to be only one parent, = meaning * we can just follow vnodes up until we find the root. *=20 * The vnode must be referenced. */ static int vn_fullpath_dir(struct vnode *vp, struct vnode *rdir, char *buf, char = **retbuf, size_t *len, size_t addend) { #ifdef KDTRACE_HOOKS struct vnode *startvp =3D vp; #endif struct vnode *vp1; size_t buflen; int error; bool slash_prefixed; VNPASS(vp->v_type =3D=3D VDIR || VN_IS_DOOMED(vp), vp); . . . For reference: /usr/main-src/sys/sys/vnode.h:#define VN_IS_DOOMED(vp) = __predict_false((vn_irflag_read(vp) & VIRF_DOOMED) !=3D 0) I'll note for the below that vn_fullpath_hardlink frames show the likes of: #15 0xffffffff80c1b27a in vn_fullpath_hardlink (vp=3D0xfffff80004fd4380,=20= vp@entry=3D0xfffff804fc0c5c40, dvp=3Ddvp@entry=3D0xfffff80004fd4380,=20 hrdl_name=3Dhrdl_name@entry=3D0xfffff806f69b0800 "worker", . . . so it had vp different than vp@entry .=20 An interesting property is there is a: type =3D atomic_load_8(&vp->v_type); but mostly just references to vp->v_type . It leaves me wondering if it is all correct. There are gdb based kernel backtraces at that codeberg.org = <http://codeberg.org/>; web page that are interesting. Note the hrdl_name and binname being: "worker" Tracing command "htop", '\000' <repeats 15 times> pid 31057 tid 101242 = (CPU 4) . . . #15 0xffffffff80c1b27a in vn_fullpath_hardlink (. . .,=20 hrdl_name=3Dhrdl_name@entry=3D0xfffff806f69b0800 "worker",=20 . . .) at /home/pkgbuild/worktrees/main/sys/kern/vfs_cache.c:3795 . . . #16 0xffffffff80b25975 in proc_get_binpath (. . .,=20 binname=3Dbinname@entry=3D0xfffff806f69b0800 "worker", . . .) at /home/pkgbuild/worktrees/main/sys/kern/kern_proc.c:2299 . . . #17 0xffffffff80b27e6f in sysctl_kern_proc_pathname (. . .) at /home/pkgbuild/worktrees/main/sys/kern/kern_proc.c:2353 . . . binname =3D 0xfffff806f69b0800 "worker" . . . "worker" seems to be uniformly in the failures reported with this kind of backtrace. For reference from that web page there was an example showing: Tracing command "worker", '\000' <repeats 13 times> pid 56422 tid 150635 = (CPU 6) #0 cpustop_handler () at /home/pkgbuild/worktrees/main/sys/x86/x86/mp_x86.c:1527 #1 0xffffffff81025f18 in ipi_nmi_handler () at /home/pkgbuild/worktrees/main/sys/x86/x86/mp_x86.c:1484 #2 0xffffffff8105dfb6 in trap (frame=3D0xfffffe003cd1ff30) at /home/pkgbuild/worktrees/main/sys/amd64/amd64/trap.c:235 #3 <signal handler called> #4 0x0000000103257cf6 in ?? () Backtrace stopped: Cannot access memory at address 0x100a359f0 a non-gdb backtrace provided looks like, for example: . . . fpcurthread =3D 0xfffff801083aa000: pid 5562 "htop" idlethread =3D 0xfffff80001c7c740: tid 100007 "idle: cpu4" . . . Tracing pid 5562 tid 100937 td 0xfffff801083aa000 kdb_enter() at kdb_enter+0x33/frame 0xfffffe014d885970 panic() at panic+0x43/frame 0xfffffe014d8859d0 vn_fullpath_dir() at vn_fullpath_dir+0x3bc/frame 0xfffffe014d885a30 vn_fullpath_hardlink() at vn_fullpath_hardlink+0x1ba/frame = 0xfffffe014d885a80 proc_get_binpath() at proc_get_binpath+0xf5/frame 0xfffffe014d885ba0 sysctl_kern_proc_pathname() at sysctl_kern_proc_pathname+0x9f/frame = 0xfffffe014d885be0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame = 0xfffffe014d885c30 sysctl_root() at sysctl_root+0x21e/frame 0xfffffe014d885cb0 userland_sysctl() at userland_sysctl+0x17a/frame 0xfffffe014d885d50 sys___sysctl() at sys___sysctl+0x60/frame 0xfffffe014d885e00 amd64_syscall() at amd64_syscall+0x158/frame 0xfffffe014d885f30 fast_syscall_common() at fast_syscall_common+0xf8/frame = 0xfffffe014d885f30 --- syscall (202, FreeBSD ELF64, __sysctl), rip =3D 0x82889e19a, rsp =3D = 0x82142b978, rbp =3D 0x82142b9c0 --- May FreeBSD system access are not nearly configured to replicate the type of context (headless or simple console, for example). As far as I can see, htop touches the problem area but itself is not the problem. The handling of the "worker" related context for the type of kernel call seems to be what is at issue, likely no matter what process happens to make the same basic kernel call that ends up with "worker" in the context. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63DE0143-2113-419A-9DBC-516940859206>