From nobody Mon Sep 16 03:48:28 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X6W9R1CTZz5WTPK for ; Mon, 16 Sep 2024 03:48:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X6W9Q02vFz4vLr for ; Mon, 16 Sep 2024 03:48:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LP4ySHCA; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726458520; bh=qQ4/WS5ESfBjUxELObb8x0S3ct1rTKgoP5p+kSwVlU8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LP4ySHCAM9dlG9JtDWyrTUax3dppiVA0E0t/8Ywp+R0zeCvP5Y943cMnlfIz6TQ92LO92/8LUH6AHCYSLVbElzny9HS1AqLYv5NYsNDNgZbz9fl9uoGI3xVFUGcWyU5YLAeUraWrq/m6baEb7giAzKep0HsHf+sJpGmBJX8n1x+N48Y3lrkZ4Tm0XMOx3V3Ysm1W9urCc1yPz/fxQmolWzZlpxr/xc18D+2UKWZWNo2fa4tdB8vUbQtLASpY/Bj4viWqmF8aTXYprqgubNtt8VFz6Ta5ruG0zhcGI630UkxnlTyrmI5WrnKtXvBMuu8wjfCIdbK60l0J5rxyai949Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726458520; bh=fS4eiTuIMh65vyVLmRDCbp6b/eywZ+a1eCq3KQdOyy+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=U7g3JoXNN/u8DZqDxbvskn8yy6jl7V8O315uIq2jCFRPvvkrSTq2l4bBuRnLhBIbKgK3zaBh+vEXlORbnC4igJk0GmewHxzmoBWh7LlHne//yFnWQs51eOGQmM6F/qBV8umN8z3V1+dMIF2PS12keTu4zn+3B2jXfHPT3Pl9qhu22kLB/7OD71/519a4va9oj83K2bh+lBtN/iiqo/Cm58hwCyRNI+Tijc5mvjdpNXMR1IfvHdGlct5T37T4syvQXYBMWKktOuFq0qESruQnwww1EFIbygvoQ0AjNIiEFvMxtx34r46sI2A5Xq5Cp3DAVJsro37JlaS8h+cCPJyJug== X-YMail-OSG: S6sqwlcVM1kgVZtDfDo92nIbFSWZDD0OeOxNicro7EbE_abaS6I5KmMoFICUJRU 3zr5WLFpK9DKMiE6_gC4gwAk.wtyZSi4IvjTomn8KYgINx8Pvk4S2jRUNwTm4zmKMggpUZqNbM94 TlAGWeONZEkUuohVAQspJF5ZrqLvhNTzox1aYSGp7JOQlAVIa8bEEZ6FE2n6LvXC2Fxgx0Uzi9wR izP7MxVtBrVUrROIgOto1lifjT5PtvJ_hZazVVb0jNiiz5odjmzZGq53zmT3lQUVmy7JBBr7e0yG 2W0CmAhuwvtQb2SZHMC4fJY_tko9XDGtbhHhQ4t3qCs1YVC433VIRSV30T.gpzTyLEY.KcwZkrvF DR.xu0swfZ_2ya2Je2D5C4FrsPe_v8WhTmFtcgy79.BZBRyTNpIamKFnjHdPD6IO8P1OA5VBoWgv 5GOsU_LRYSbHoNUnA4hLctzoR4Hl1IUNC39kPxYAS5P0MtGd0vzZUHqk6VsP3vzn3byNMuZ5IPr_ bJNI__s1sCELelz5UTQfZkGeajoyqkymSBvk9livGGMetgBWxtskW1UUsIKik6HNSyiyqT6l_aFZ TMlfUjCbPiG0hTGVshBiJ.tY1_eS1u7mChrBUyyfzkY7_ATTGoFIrFn_orxu6y_Wf2JPjAc_3QFK ZfJaTkc03oRdjldu4ofwhTVpBjYq_SeEk1cwCvkBVitpP23BGVijrcRh0oUGKLZS4M6yv_BrteAf asEAVWZ4Fk33kQou8cD_2SFyDTBZUW1gdcXCTah9FBYK3QsIS.8GIc.DUv5cYhUrTrXoXyZ7X4iu JnZrJORTWrSA6OL.5aFUUwiCnqLXUdIbIMGUXdZaOvmXzDdNsNVPmVKAXj0jUjuhAyoWIYE_6Asu F49p8yDcctYHGQfDMeKIymEIHENsTpCEjZUCHY91b..6_.7HnmCP1y8iENDMgUc_T07TmBoZjl7O ZBWpEffksQHHfVAeJG1_z8y8_H5thJs60OBERKy1EZS_ojbKbGnMl32RN6u37jKDJlXQFVQ8vGkb jqOFMqjfGYeR6EW5LUNxsiqc4RynNu8phtFMEM39oC9C0odZS_y63bIbqox.k7UmNyGOls6nl3mE O6crqE.Qff3aRgoWsv1lxpoI2RCnuMpbZTlp1L0Dv2SWHQgCJWvRWyJYYyJ4odxf2ZlHMYtLH6PI TrJdeillnbgb9AOCkCvE0z5iX1zGPprSnM5U32JydhYaao0e7uKBiO.tVJaUXNkHhIAWgTILPa8O InYZagIpwa6UUf7Deahwp6aQUHzzDGRQjok71wpyLN.2uFZfwq2IyR6BAbmhymLZoZodfPRPgfpo PJJboue6.Hy9id8TE7tjurBzDVbp8nZLrUq8ZxoCLu.lh9Zeg2o0gdIXkmUV1.1oLQwucHdHfL9c 1KUsaHDkLh5Dih1RmfxPkhVGXre7pscpj3Rl6T.lObDMvxEOdZILq4Fww_8bcZTvKwunZMhXBIG3 _7NzusT17eSZ9i_1bqBmfVlZQT8.Zx5AJXtt4VWCTi7GaefCihJwIA89q4SbpkiStL6Z92n4pDr5 qKBU.DonOpcKwy2GjVBq1VX6uHpVHVzdRnkDs7jDYpJOXUV2LT7uiqp6lVM0aFDi97_nxTTbTVJa cT7wqj3j6hmv7j0nD_.EsFsE4FTYGDvLDxxlLWGpSolx3j2VXZvpq_JKsOG7saM2jsDwJBAZYqWz sTxXuaIFt1MxLBnJV3hQg0p4SkVFxVGn5jyjiH1aEKN6LZwfBmu.MVYQ8YI2GVfoYwMTjS8TXQPL R_2ZPdlkqOQRwf20PrTOwPCN84wAgvfUxmUux4kKV80Wch3pvygqRcNPVh6F3HT5OroBx6Tv6Oem OvAxRSF5q1_IfH61i2Qhlox9ys_O75bPjCF.jnhaVTHnoAdpr68e47byeONAMG1TpjVUEUajs9bV Kkuzk.mdOwIdwHHoaABcwzff1RkDk1rXnMY8g1lPJtOH484xcMs1A1f7n2i3WzMvTKvF4.XzIiEN npp96lEcC8eUiGWyr.u.eSKc3f1_I3Glo0ZXYAKCDI4pWeFGvRsAhxacgoSDOMgP.UEEP_.qoHu6 TUWURokI2tWIXsp0IZTTfskz2plLd6WHJoMO5i4aQmDWVQWNYPzt2PuBPlbN.lGeGjbMWOSmPwR8 ofFEYQEStZAb094nY7cWZNROltwGvYzgA7F1DI3v939nCFiEpXduENbJdy3eV_h9QP6kmcVNZLfL u62Kiy7cmscWJ7IRoCpD982XMk22mlSc9WqjkFF3lu7YFpXPHxaaM.eIjF1GQVXGiZRbmUIlJWLa 3eNv62kplNF0lUlE- X-Sonic-MF: X-Sonic-ID: fef70bcb-04f1-47d1-b8a7-ffa26e16a757 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 16 Sep 2024 03:48:40 +0000 Received: by hermes--production-gq1-5d95dc458-dxlpk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7b221e8d30da2930347e9c65de68cb53; Mon, 16 Sep 2024 03:48:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) 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> Date: Sun, 15 Sep 2024 20:48:28 -0700 To: Graham Perrin , Current FreeBSD X-Mailer: Apple Mail (2.3776.700.51) References: <63DE0143-2113-419A-9DBC-516940859206.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from] X-Rspamd-Queue-Id: 4X6W9Q02vFz4vLr Graham Perrin wrote on Date: Wed, 22 May 2024 20:32:42 UTC : > Reproducible at . >=20 > 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 = web page that are interesting. Note the hrdl_name and binname being: "worker" Tracing command "htop", '\000' 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' 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 #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