[OpenAFS-devel] kernel BUG at /scratch/openafs/src/libafs/MODLOAD-2.6.13-MP/rx_kcommon.c:131!

[chas williams - CONTRACTOR]

In message <DFC9582579DBA29B34C84527@endicott>,Chaskiel M Grundman writes:
>> +			atomic_set(&dp->d_count, 1);
>Is that really appropriate? You didn't make this dentry up yourself. It is
>presumably the same dentry as afs_globalVfs->s_root, and may be the current
>directory of any number of processes, etc.

yes.  the only time this code does anything is when you switch over
from the RW afs.root to the RO afs.root.  can you get a reference to a
RO path when the root of the search is a RW path?  ergo the new root
inode should not have any existing lookups/references so d_count for
/afs should become 1.

yes, this seems wrong but linux doesnt seem to expect a filesystem to
want to change the root mount point on the fly.  i hestitate to d_drop,
d_alloc_root() and the change sb->s_root.  i have children dentries
pointing to the current root dentry.

this is also a fairly unique situation.  only happens when you are
setting up a new cell.

>The list_del_init also seems somewhat heavy-handed, but given that we fixed
>the multiple-directory-aliases problem, should not break anything.

i figured that.