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

From: Bjoern A. Zeeb <bz_at_freebsd.org>
Date: Tue, 03 Jun 2025 21:25:56 UTC
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)?

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.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7