Re: git: 9a139facd06e - main - pseudofs: enhance KASSERT with more information

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.