Date: Tue, 17 Sep 2024 08:06:00 +0100 From: Graham Perrin <grahamperrin@gmail.com> To: FreeBSD-CURRENT <freebsd-current@freebsd.org> Cc: Mark Millard <marklmi@yahoo.com> Subject: Kernel panics with Widevine and htop: VNPASS in sys/kern/vfs_cache.c Message-ID: <381c3f52-7e38-49e3-aa20-bacbf23117bc@gmail.com> In-Reply-To: <63DE0143-2113-419A-9DBC-516940859206@yahoo.com> References: <63DE0143-2113-419A-9DBC-516940859206.ref@yahoo.com> <63DE0143-2113-419A-9DBC-516940859206@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/09/2024 04:48, Mark Millard wrote: > Graham Perrin <grahamperrin_at_gmail.com> wrote on > Date: Wed, 22 May 2024 20:32:42 UTC : > >> Reproducible at <https://bitmovin.com/demos/drm>. >> >> <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. > * > * 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. > * > * 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 = vp; > #endif > struct vnode *vp1; > size_t buflen; > int error; > bool slash_prefixed; > > VNPASS(vp->v_type == 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) != 0) > > … Big thanks to Mark for investigating. When I first wrote here, in May, I had no idea that htop could trigger the panics. I knew little more than, a panic occurring with every (-CURRENT GENERIC) attempt to use Widevine in www/chromium. > … 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. > > === > Mark Millard > marklmi at yahoo.com Built as shown at <https://github.com/htop-dev/htop/issues/1537#issuecomment-2354268992>, it's now possible for Chromium to detect (and play) Widevine content, with GENERIC, whilst htop runs. For myself, I have set aside a copy of FreeBSD Project-packaged htop-3.3.0_4.pkg Regards Graham
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?381c3f52-7e38-49e3-aa20-bacbf23117bc>