On Tue, Jun 03, 2025 at 09:25:56PM +0000, Bjoern A. Zeeb wrote: > On Tue, 3 Jun 2025, Konstantin Belousov wrote: > > > On Tue, Jun 03, 2025 at 11:25:17AM +0000, Bjoern A. Zeeb wrote: > > > The branch main has been updated by bz: > > > > > > URL: > > > https://cgit.FreeBSD.org/src/commit/?id=9a139facd06e4a1159a9c2cb992d04bcf1079e7e > > > > > > commit 9a139facd06e4a1159a9c2cb992d04bcf1079e7e > > > Author: Bjoern A. Zeeb <b...@freebsd.org> > > > AuthorDate: 2025-06-03 11:20:56 +0000 > > > Commit: Bjoern A. Zeeb <b...@freebsd.org> > > > CommitDate: 2025-06-03 11:25:00 +0000 > > > > > > pseudofs: enhance KASSERT with more information > > > > > > Add the name and type information to a KASSERT for 'homonymous > > > siblings'. > > > Without this (or a core file) we do not even know which entry to look > > > for. This should make reporting and debugging a tad more simple. > > > > > > Prompted by: PR 287165 > > > --- > > > sys/fs/pseudofs/pseudofs.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/sys/fs/pseudofs/pseudofs.c b/sys/fs/pseudofs/pseudofs.c > > > index eb4ca8a82456..d8dbf7117d13 100644 > > > --- a/sys/fs/pseudofs/pseudofs.c > > > +++ b/sys/fs/pseudofs/pseudofs.c > > > @@ -124,7 +124,8 @@ pfs_add_node(struct pfs_node *parent, struct pfs_node > > > *pn) > > > ("%s(): nested process directories", __func__)); > > > for (iter = parent->pn_nodes; iter != NULL; iter = iter->pn_next) { > > > KASSERT(strcmp(pn->pn_name, iter->pn_name) != 0, > > > - ("%s(): homonymous siblings", __func__)); > > > + ("%s(): homonymous siblings: '%s' type %d", __func__, > > > + pn->pn_name, pn->pn_type)); > > > if (pn->pn_type == pfstype_procdir) > > > KASSERT(iter->pn_type != pfstype_procdir, > > > ("%s(): sibling process directories", __func__)); > > > > May be it is time to finally make this check a runtime one. > > D50669 > > Can the callers deal with that? lindebugfs etc.? or will we just see > different panics (less clear)? Yes, the error is propagated to the callers, and callers must deal with it.
Note that the current state is quite bad: the panic for INVARIANTS build is replaced by silent creation of the second node with the same name for non-INVARIANTS kernel. > > The problem that kargl is running into seems that drm-kmod/radeon is > double-initialising and radeon has no cleanup routine hooked up most > likely (or none which I could identify on quick look). No idea how this > works on Linux but I know I had to fix wifi drivers as once I had two > cards directories on FreeBSD were identical otherwise. Eventually callers should grow the proper reaction to the issue. But it cannot be started done until the pfs code acts reasonably.
