lha@stacken.kth.se complained that we sometimes printed garbage, so i took
the opportunity to both fix it and update ours to support the options
the arla vos listaddrs does
given that we don't bother to do anything to return value, we can ack
the fssync op earlier and not tie up the volserver unnecessarily
found due to comments from brent.johnson@jpl.nasa.gov
based on comments and suggestion from Srikanth Vishwanathan <vsrikanth@in.ibm.com>
avoid deadlock. send back variable length list. allocate what we need to, and
be care to clean up after ourselves if there's an error. whether this
should be variable length is arguable but it's pretty clear no one was using
this before.
based on report from lha@stacken.kth.se
"identP = (struct Identity *)malloc(1);
This can't be right, there should not be an assumption how the
c-compiler will lay out code. I find it acceptable to do something like this
/* sizeof valid + offset of valid. */
i.. = malloc(sizeof(identP->valid) + (int)&(((struct Identity *)0)->valid));
But then, why not just allocate a whole identP and be happy. A afsUUID
is not that bloted (16 bytes) so I can't see why way this is
chosen. 20 bytes will probably be allocated on 32 bit platforms for
the whole struct Identity.
"
recalc_sigpending(), otherwise recent kernels don't appear to deliver
new instances of any signals already received.
Revert back to using SIGKILL at shutdown time, but use SIGKILL instead of
explicitly using signal 9, because abstraction is your friend.
liberal debugging code and hammering produced a failure where newslot was
actually walking on another call to newslot because the bufferlock was
being dropped before newslot incremented lockers on the buffer it
was allocating, allowing someone else to come along and also think they
could allocate it.
by holding the bufferlock just a little longer we avoid this
doesn't fix any problem that i can find, but results in ihandles not
having thousands of bogus references (and may fix problems if refcnt were to wrap)
double inclusion of afs_osidnlc.h.
An equivalent patch was already present in the mainline as part of
linux-dcache-inconsistency-fix-20020115, but its pullup to the stable
branch, STABLE12-linux-dcache-inconsistency-fix-20020120, was oddly
missing this particular part of the diff.
this does fix some potential problems, even if none of them are the
CopyOnWrite problem. basically, ih_reallyclose() could reinsert a now-unref'd
fd handle into the wrong list when cleaning up, and this cleans up the code
considerably.
