[OpenAFS] openafs panic after chroot
Chaskiel M Grundman
cg2v@andrew.cmu.edu
Mon, 10 Feb 2003 11:35:24 -0500
--On Monday, February 10, 2003 00:31:16 -0800 emoy@apple.com wrote:
> The backtrace shows afs_FlushActiveVcaches (called from afs_Daemon,
> itself called from afs_syscall_call) calling panic:
>
># ifdef AFS_DARWIN_ENV
> if (VREFCOUNT(tvc) == 1 && UBCINFOEXISTS(&tvc->v)) {
> if (tvc->opens) panic("flushactive open, hasubc, but
> refcnt 1"); osi_VM_TryReclaim(tvc,0);
> }
># endif
This code is testing for what _should_ be an impossible condition.
There should be one reference for each open, and one reference for the VM
system. Because the vnode is inconsistent, afs doesn't know what to do with
it, and rather than let the kernel panic with some inscrutable message
later, I decided to report the inconsistency as soon as it was discovered.
I'm not sure what this could have to do with a chroot. Only VREG nodes
(normal files) can have UBCINFOEXISTS be true, directories cannot. I
suspect that the chroot is a red herring, and there's still a generic
problem with executables in afs.