| raw e-mail | index | archive | help
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 <bz@FreeBSD.org> > > > AuthorDate: 2025-06-03 11:20:56 +0000 > > > Commit: Bjoern A. Zeeb <bz@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>