[OpenAFS-port-darwin] Status?

[Derrick J Brashear]

On Mon, 14 Jun 2004, Derrick J Brashear wrote:

> The problems seem to be as follows (and maybe more, but these are the ones
> I know of)
> -vnreclaim can race with TryReclaim. Chaskiel worked up something and I
> made some more changes as dictated by testing, only the parts which are
> "done" went into CVS earlier today. I'm still testing to make sure the
> rest has no side effects, and I need to let the test run for a while
> (which it hasn't due to the fact that I'm still working on the item 2
> below this one)
>
> -rename can panic in vget due to no ubc. the lookup vnop has
> to be prepared to instantiate a new ubc. I also put that into CVS today.
>
> -leaked references in our lookup vnode op (can cause the vlru cycle panic
> which linux had for some time..) which I'm hoping to have the answer to
> shortly.

Answer: put back VPARENT refs before recycling vnodes.

And I think there may be one more issue with a race between when
TryReclaim completes and FlushVCache removes a vcache from the vlruq,
where FindVCache will find it and we don't want it to. But I'm going to
sleep on that instead of beating on it, and let my tests keep running.

If you want to play with a module, which may eat your machine but more
likely will have debugging printfs you don't want and will probably crash
less than 1.2.11,
/afs/andrew.cmu.edu/usr/shadow/macos-afs-kext-20040614

Replace /var/db/openafs/etc/afs.kext/Contents/MacOS/afs in a normal
install with this. Make sure it's owned root wheel and mode 644 so it will
be "authentic" at load time. Hopefully I caught all the calls into
functions in my special debug kernel and pulled them.

I'll abstract out the source changes from the debugging tomorrow and
figure out what else needs to end up in CVS.

If you tell me you crashed it, a backtrace would be very helpful.

In the meantime, I'm going to sleep, and let my tests run.