Build system: MT_LIBS includes XLIBS

The MT_LIBS library list already includes XLIBS, so there's no need
to specify both on a link line.

Change-Id: I8594b1b6e1a16af741b40822cbce49e846b26f49
Reviewed-on: http://gerrit.openafs.org/8904
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Add asserts to VLock* functions

Make sure we don't continue on if we have unbalanced locks and
unlocks. Having a negative refcount is a serious internal error, and
they are difficult to fix unless we assert right away.

Change-Id: Ib9b5b3f209635e0365df96c79ea8bf49c765008b
Reviewed-on: http://gerrit.openafs.org/2594
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

DAFS: Free header on partially-attached vol salv

When we VRequestSalvage_r a volume, normally the header is freed when
the volume goes offline. This happens when we VOfflineForSalvage_r,
either via VCheckSalvage when nUsers drops to 0, or in
VRequestSalvage_r itself if nUsers is already 0. We cannot free the
header under normal circumstances, since someone else may have a ref
on vp, which implies that the vol header object is okay to use.

However, for VOL_SALVAGE_NO_OFFLINE, we skip all of that. For
VOL_SALVAGE_NO_OFFLINE, the volume has only been partially attached,
so it does not go through the full offlining process, so we don't ever
hit the normal VPutVolume_r handlers etc. So, in the current code, we
don't free the header. But our nUsers drops to 0 anyway, and when
nUsers is 0, our header is supposed to be on the LRU (if we have one).
"oops"

Rectify this by freeing the volume header when VOL_SALVAGE_NO_OFFLINE
is set. Add some comments to try to be very clear about what's going
on.

Note that similar behavior was removed in commit
4552dc552687267fce3c7a6a9c7f4a1e9395c8e5 via a similar flag called
VOL_SALVAGE_INVALIDATE_HEADER. I believe now that this is the same
scenario that VOL_SALVAGE_INVALIDATE_HEADER was trying to solve.
However, VOL_SALVAGE_INVALIDATE_HEADER was not always used correctly,
and its purpose was not really adequately explained, which contributed
to the idea that its very existence was buggy.

Previously, when VOL_SALVAGE_INVALIDATE_HEADER existed, it was used
incorrectly in the VRequestSalvage_r calls in GetVolume,
VForceOffline_r, and VAllocBitmapEntry_r. All of these call sites
could have a vp with other references held on it, and so invalidating
the header there can cause segfaults when the header is freed. So
ideally, commit 4552dc552687267fce3c7a6a9c7f4a1e9395c8e5 would have
just removed the flag from those call sites.

This change effectively restores the behavior that
VOL_SALVAGE_INVALIDATE_HEADER provided. But no new flags are gained,
since this behavior is what we want for the VOL_SALVAGE_NO_OFFLINE
flag. This is not a coincidence; for the 'normal' case, we will free
the header whenever we offline the volume. But for the 'do not
offline' case, obviously that will never happen, so we need to do it
separately. So, these two flags are really the same thing.

Change-Id: Ia369850a33c0e781a3ab2f22017b8559410ff8bf
Reviewed-on: http://gerrit.openafs.org/8204
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

ihandle: Add a comment on IH_OPEN/IH_REALLYCLOSE

Currently, it's not really 'safe' in ihandle to issue an IH_OPEN
against an IHandle_t when an IH_REALLYCLOSE is running at the same
time. The reasons for this are explained a bit in ticket 131530 and
related commits, but briefly:

Say IH_OPEN runs, and drops IH_LOCK to open a new fd on disk. Then
IH_REALLYCLOSE runs and closes all fds, or marks them as needing
close. The running IH_OPEN then acquires IH_LOCK again and puts the
newly-opened fd onto the per-IH list of fds. We now have an fd that
effectively "survives" across the IH_REALLYCLOSE; effectively
IH_REALLYCLOSE did not close all fds for the ih.

This is possibly fixable by maintaining some extra information in
IHandle_t's, but this is only a problem if we allow IH_OPEN calls to
happen simultaneously with IH_REALLYCLOSE calls. Ever since
ih_sync_thread was removed (or changed to not call IH_OPEN), there
should be no cases where this is possible. All instances of
IH_REALLYCLOSE happen during error recovery for a newly-created file,
or happen under a per-vnode write lock, or for volume metadata files
only happens when the ref count for a volume drops to zero when we're
offlining the volume.

So, do not bother trying to fix this, since doing so is currently a
waste of time and the resulting complexity could introduce bugs. But
in case someone ever tries to do something resulting in IH_OPEN calls
executing outside the normal threads of execution, add a comment
around the IH_REALLYCLOSE explanations to try and briefly explain that
this cannot currently be done.

Change-Id: I989806635f3b048b0c084480a4b02dc1902ba031
Reviewed-on: http://gerrit.openafs.org/9709
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

opr: implement the BSD ffs() functions

Provide opr implementations of ffs(), fls(), ffsll(), and flsll().
There is no need to provide the 'long' form, since int is 32 bits
and long long is 64 bits.

These functions return the index of the first (or last) bit set
in a given (long long) word, or zero if no bits are set.

Change-Id: I126000f8b650f41d67567a9af659e0805478af2d
Reviewed-on: http://gerrit.openafs.org/11671
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

afs: Remove unused constant DCSIZE

The size of the dcache hash table is automatically determined
from the size of the vcache hash table size, since even before
the initial OpenAFS 1.0 release.  AFS 3.3 had constants
DCHASHSIZE and DVHASHSIZE which were used to size the respective
hash tables, but DCSIZE was unused even there.

Change-Id: I1f4e278eacb881b60a457fa9871225de7ce0f9f8
Reviewed-on: http://gerrit.openafs.org/11672
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

cacheout: Use authenticated secClass for VLDB

Currently 'cacheout' will always utilize an unauthenticated connection
when talking to the VDLB, even if it uses an authenticated connection
when talking to fileservers. This is regardless of any tokens
retrieved or command-line parameters, etc.

Using an authenticated connection to the VLDB can be useful, since a
user may want to encrypt the VLDB communication, or require stronger
guarantees of data consistency. So, just use the same security class
information for our VLDB communication as for our fileserver
communication.

'scnull' is now not used anywhere after this commit, so get rid of it.

Change-Id: I1e8a440ea7427399a3b219246e4c3623a603c35e
Reviewed-on: http://gerrit.openafs.org/11637
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

fix byte ordering in check_sysid

Several uuid fields as well as the ip addreses in the sysid file are in
network byte order.  Fix the check_sysid utility to decode these fields
properly.  In addition, print the server uuid in the common string
format used to display uuids, instead of by individual uuid fields.

Change-Id: I9688e9117490d0ef0eb6dd5af417222482322e0c
Reviewed-on: http://gerrit.openafs.org/11603
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

rx: rxi_SendPacketList remove duplicate conditional

Presumably these checks were different at some point in the past.

Change-Id: I0fb8737404a3c4fa786ab7965b60d35328d0bf32
Reviewed-on: http://gerrit.openafs.org/11632
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

rx: Remove dead AFS_ADAPT_PMTU SUN5 code

AFS_ADAPT_PMTU is only defined on linux26, so anything which is
conditional on both AFS_ADAPT_PMTU and AFS_SUN5_ENV being set is
dead code.

This seems to have been dead code since its introduction in
commit 1206e7538be86f073b21cd289266286b60a95d0a.

Change-Id: I9bb6ff40de87a7f2d8d953ef7583c6c2b090ab48
Reviewed-on: http://gerrit.openafs.org/11631
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

rx: Normalize use of some MTU-discovery fields

When we store MTUs (peer->ifMTU, peer->natMTU, etc.), we store the
maximum transport unit usable by RX, i.e., excluding the IP and UDP
headers, but including the RX header.  Contrariwise, when we track the
size of packets we've sent (conn->lastPacketSize, peer->maxPacketSize),
we track logical packet lengths which exclude the RX header (and the IP
and UDP headers).  However, the consumers of lastPacketSize and
maxPacketSize were not always interpreting their values correctly as
excluding the RX (and other) headers.

Add comments to these fields in their respective structure definitions
to help make clear what they contain (and the difference between them).
Correct several checks which were using the wrong constant for
correcting between these two worldviews (and the wrong sign).  Modernize
the style of lines that are touched.

The lastPacketSize and maxPacketSize variables are only accessed from
five places: while sending packets, while processing acks, while sending
acks, while handling growMTU events, and in rxi_CheckCall().  They are
used to track the size of packets that have been successfully sent (and
thus, indirectly, to control the size of packets we send).  The
maxPacketSize is only set once we have received an ack from the peer for
a packet of that size, and lastPacketSize tracks the size of a
speculative packet larger than that size, until it is acked.

When sending packets, we check if the size of the packet we are sending
exceeds the recorded maxPacketSize, and if so, record that speculative
size in the lastPacketSize variable, along with the sequence number of
that packet in lastPacketSizeSeq.

Correspondingly, when processing acks, if the packet tracked in
lastPacketSizeSeq is being acked, we know that our speculative large
packet was successfully received, and can attempt to update the recorded
maxPacketSize for the peer.  This is done through an intermediate
variable, 'pktsize', which holds either the value of lastPacketSize or
lastPingSize, without adjustment for the size of any headers.

The ack processing has a bit of code to handle the case where
maxPacketSize has been reset to zero, initializing it to a small value
which should be expected to always work.  The intention seems to have
been to initialize maxPacketSize to the smallest permitted value (since
RX_MIN_PACKET_SIZE is amount of data available to RX in the smallest
permitted IP packet), but the old code was actually initializing
maxPacketSize from zero to something a bit larger than the minimum, by
RX_IPUDP_SIZE + RX_HEADER_SIZE.  This over-large initialization was
mostly harmless, see below.  After this potential initialization,
'pktsize' was incorrectly used to set a new ifMTU and natMTU for the
peer.  It correctly determined that a packet larger than the previous
maxPacketSize had been acked, but then set the peer's ifMTU and natMTU
to smaller values than the acked packet actually indicates.  (It is
careful to only increase the ifMTU, though.)  The actual peer->MTU is
*not* updated here, but will presumably trickle through eventually via
rxi_Resend() or similar.  It is possible that this code should be using
rxi_SetPeerMtu() or similar logic, but that might involve locking issues
which are outside the scope of this analysis.

The over-large initialization of maxPacketSize (from zero) was
fortuitously mostly harmless on systems using minimum-sized IP packets,
since a correspondingly wrong check was used to detect if a new MTU
invalidates this maxPacketSize, with the constants offsetting.
Likewise, the checks in rxi_SendAck() had the wrong constants, but they
offset to produce the correct boundary between small and large packets
while trying to grow the MTU.  Unfortunately, the old behavior in the
"small" case is not correct, and the grow MTU event would try to send a
packet with more padding than was intended.  In networks allowing
packets slightly larger than the minimum (but not much larger than the
minimum), the old code may have been unable to discover the true MTU.

In the main (MTU-related) logic of rxi_SendAck, a variable 'padbytes' is
set to a small increment of maxPacketSize in the "small" case, and a
larger increment of maxMTU in the "large" case.  There is a floor for
padbytes based on RX_MIN_PACKET_SIZE, which ended up being larger than
intended in the old code by approximately the size of the rx header.
(Some of the adjustments performed are rather opaque, so the motivations
are unclear.)

The more interesting places where accesses to lastPacketSize and
maxPacketSize happen are during the MTU grow events and in
rxi_CheckCall().

In rxi_CheckCall(), the packet size variables are only accessed if
the connection has the msgsizeRetryErr flag set, the call is not timed
out (whether for idleness or during active waiting), and the call has
actually received data.  In this case, we conclude that sending packets
failed and decrease the MTU.  The old code was quite broken in this
regard, with a reversed sense of conditional for whether a speculative
large packet was outstanding, and a rather large decrease in MTU size
of effectively 128 + RX_HEADER_SIZE + RX_IPUDP_SIZE = 212, when only
a decrease of 128 was intended.  The new code corrects the sense of
the conditional and sets the decrease in MTU to the intended value of 128.

With respect to MTU grow events, this change only touches
rxi_SetPeerMtu(), to correct the conditional on whether the MTU update
invalidates/overrides the cached maxPacketSize.  There is a window of
values which could cause the old code to incorrectly fail to invalidate
the cached maxPacketSize.  Values in this window could result in the old
code being stuck on a bad MTU guess, but should not cause an actual
failure to communicate.  That conditional zeroing of maxPacketSize is
the only access to the PacketSize variables in rxi_SetPeerMtu().
maxPacketSize is also checked in rxi_GrowMTUEvent(), but only against
zero to avoid sending RX_ACK_MTU packets needlessly, so it is unaffected
by the issue at hand.

In summary, in certain network conditions, the old code could fail
to find an optimum MTU size, but would always continue to operate.
The new code is more likely to find a better MTU size, and the old
and the new code should interoperate fine with both each other and
themselves.

[kaduk@mit.edu add a few missed cases; expound on analysis in commit message]

Change-Id: I7494892738d38ffe35bdf1dfd483dbf671cc799a
Reviewed-on: http://gerrit.openafs.org/8111
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

afs: Warn about afs_conn overcounts

Currently we panic if we detect an undercount on an afs_conn
structure, as this is a serious bug and can cause corruption and other
issues. But an overcount is never noticed, until the refCount
overflows and looks negative. Log a warning if the refCount gets
really high, so an administrator has a chance at noticing and
notifying a developer before the machine actually panics.

[kaduk@mit.edu use the %p format specifier, mandated by C89]

Change-Id: Ifc291fc10959e4e1c60115813d82a09e5a65ef75
Reviewed-on: http://gerrit.openafs.org/11465
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

afs: Refactor GetDSlot parameters

The 'indexvalid' and 'datavalid' parameters were really representing 3
different scenarios, not 2 different values with 2 possibilities each.
Change these to a single parameter, 'type', with 3 different values:
DSLOT_NEW, DSLOT_UNUSED, and DSLOT_VALID. Hopefully this will make the
relevant code paths easier to understand.

This should incur no functional change; it is just code
reorganization.

Change-Id: Iac921e74532de89121b461fa0f53ddb778735e0c
Reviewed-on: http://gerrit.openafs.org/9834
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

LINUX: Remove fix_bad_parent

For Linux, fix_bad_parent (and in 1.6 and earlier, check_bad_parent)
served the purpose of fixing mvid if it was "wrong", for volume-root
vcaches (mvstat == 2).

However, in modern Linux, we never really use mvid for root vcaches.
This would normally be used for looking up ".." entries in the root
dir, but Linux handles that for us.

Specifically, the only times an "mvstat == 2" mvid is used are:

 - afs_lookup(), where we specifically check for a ".." lookup. Linux
   cannot give us a lookup for "..", since Linux itself services ".."
   lookups through the dcache.

 - afs_readdir_move(), where we look for ".." entries. Linux does not
   use this function, since Linux reimplements afs_readdir() in
   afs_linux_readdir(), and so this function is never called.

Of course, mvid is used in many other locations, mostly for "mvstat ==
1" vcaches (mountpoints) and a few other special cases. But these are
the instances where mvid is relevant for root dirs.

So, since mvid is never really used for "mvstat == 2" vcaches on
Linux, don't bother trying to keep it up-to-date. Doing so is just
needless waste, and causes problems when there are bugs in
fix_bad_parent. The mvid field is still updated in cross-platform code
from time to time; removing that would be more complex and possibly
not worth the effort.

Change-Id: I5011ba069e5c8ed947ab6ff8d8dd393241d9c4bf
Reviewed-on: http://gerrit.openafs.org/11615
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

Add AFSCONF_NOCELLNAME error code

Contrast with AFSCONF_NOCELL, which is for when no cell configuration
information is available at all (i.e., a struct afsconf_dir* was NULL) --
this code is used when there is some cell configuration available, but
that configuration does not include the cell name.

Replace the only existing use of AFSCONF_UNKNOWN with this more-informative
error code, leaving AFSCONF_UNKNOWN free for use in other situations.

Change-Id: I989756a960e5377545af43f8e9414d1f2d6476b4
Reviewed-on: http://gerrit.openafs.org/11628
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Linux 3.19: struct nameidata becomes opaque

With kernel 3.19 struct nameidata becomes opaque.  As a result
we cannot rely on STRUCT_NAMEIDATA_HAS_PATH being true for
new kernels.

Rework the conditions here so that STRUCT_NAMEIDATA_HAS_PATH
is only tested when we're using a nameidata structure and
the result matters.

Also modify a configure test to use a nameidata pointer
instead of an actual structure.

Change-Id: I0d71fca44a67570ac3b86151c70f2969dc463f4f
Reviewed-on: http://gerrit.openafs.org/11648
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Linux 3.19: Use mgs_iter in struct msghdr

struct msghdr gets msg_iov replaced by msg_iter.  Add a configure
test and adjust the affected code.

Change-Id: I9b9e3987e55a10e48087b318d98a5a7bb17a4612
Reviewed-on: http://gerrit.openafs.org/11647
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Linux 3.19: No more f_dentry

Back in kernel 2.6 .20 struct file lost its f_dentry field
which was replaced by f_path.To ease transition f_dentry
was defined as f_dpath.dentry in the same header.This
define finally gets removed with kernel 3.19.

Keep using f_dentry in the code, but add a configure test
for the presence of f_path and the absence of the f_dentry
macro so we can add it if its missing.

Change - Id:I8e8a7e4d3ddd861018de50af1eb7315e730ad529

Change-Id: I4b05aa3d37f01e0e675c420cbf941d682c49c69c
Reviewed-on: http://gerrit.openafs.org/11646
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Linux: d_alias becomes d_u.d_alias

The fields in struct dentry are re-arranged so that d_alias
shares space wth d_rcu inside the d_u union.  Some references
need to change from d_alias to d_u.d_alias.

The kernel change was introduced for 3.19 but was also backported
to the 3.18 stable series in 3.18.1, so this commit is required
for 3.19 and current 3.18 kernels.

Change-Id: I711a5a3a89af6e0055381dfd4474ddca2868bb9c
Reviewed-on: http://gerrit.openafs.org/11642
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

ptserver: Limit length on namelist, idlist

namelist and idlist are used as IN parameters to ptserver RPCs that
can be issued by unauthenticated clients. Not having a length limit on
them means anyone can use up a ton of ptserver memory by just issuing
those RPCs with a very large length.

So, put a limit on them. PR_MAXLIST is a constant that already exists,
but is small enough to potentially limit real use, so define a new
OpenAFS-internal value for this purpose.

prlist and prentries are returned from the ptserver to clients, so
also limit them in the same way.

Change-Id: Iaf45639bbae401093354adbfb4daa172fe97ede1
Reviewed-on: http://gerrit.openafs.org/9588
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

uss: always build uss

Revert change Ibab1dd189e7fbc41ca01e7ef7479421c056999f5 since uss
should always be safe to build now that its parser symbols are private.

Change-Id: I65fd2008b037dd36a2c7d3ef8817d4d7dda689d7
Reviewed-on: http://gerrit.openafs.org/11653
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

uss: Avoid -i (inplace) with sed

Not all sed versions support inplace editing, so do things ourselves.
Also use the sed version found by configure for consistency.

Change-Id: I6194b8dd6b7abf88d0b0fa36ba871e0ba092ce1e
Reviewed-on: http://gerrit.openafs.org/11655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

Linux: Move code to reset the root to afs/LINUX

Move the Linux specific bit of code to reset the root to
afs/LINUX platform specific files.  Things that play with
the Linux vfs internals should not be exposed here.

No functional change, but this helps cleanup some ifdef
mess.

Change-Id: Ia27fca3d8052ead45783cb2332c04fe6e99e5d9f
Reviewed-on: http://gerrit.openafs.org/11641
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

Fix unchecked return values

This change fixes numerous places where the return values of various
system calls and standard library routines are not checked.  In
particular, this fixes occurrances called out when building on Ubuntu
12.10, with gcc 4.7.2 and eglibc 2.15-0ubuntu20.1, when the possible
failure is one we actually do (or should) care about.  This change
does not consider calls where the failure is one we deliberately
choose to ignore.

Change-Id: Id526f5dd7ee48be2604b77a3f00ea1e51b08c21d
Reviewed-on: http://gerrit.openafs.org/9979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

vol: rename volUpdateCounter macro

Change the volUpdateCounter volume macro name to be
consistent with the volume header name.

Change-Id: I55f55f2c084135e9598c194ed9081fce800ddfe9
Reviewed-on: http://gerrit.openafs.org/11318
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Remove traces of Debian packaging

In e34e0d1 the Debian packaging was removed. Some traces are still left, so
remove those as well.

Change-Id: I1d5c22181f59b2bee42dd34c9f3a043297d294a2
Reviewed-on: http://gerrit.openafs.org/11630
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

dafs: avoid asserting on dafs VSALVAGING error code

DAFS introduced the VSALVAGING error code which is returned when a vnode
cannot be put and a volume has been scheduled to be salvaged.

Update the afsfileprocs to not assert on VSALVAGING, as well as the
VSALVAGE error code.

For example, VPutVnode() and VVnodeWriteToRead() may call
VRequestSalvage_r() which will set the error code to VSALVAGING when a
salvage is requested.

This was noticed during a code inspection.

Change-Id: I6cacfe92347bc5af57defef17b8a2f98c5302f93
Reviewed-on: http://gerrit.openafs.org/10611
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

bozo: Constify bozo_Log 'format' argument

We clearly do not need to modify the format string; declare it const.
This makes the signature of bozo_Log identical to FSLog, which can
make it easier to use these functions interchangeably.

Change-Id: I89ae9babec2c4e8714019f58fe29dacc7283ae15
Reviewed-on: http://gerrit.openafs.org/10830
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

fssync-debug: close test connection

A valid fssync-debug query <volid> command issued against
a DAFS fileserver will produce the following error messages in FileLog:

SYNC_getCom:  error receiving command
FSYNC_com:  read failed; dropping connection (cnt=1)

Routine dafs_prolog() issues a tentative FSYNC_VOL_LISTVOLUMES operation
to test for the presence of a DAFS fileserver.  If DAFS is detected,
we then call dafssync-debug for the original requested operation.
However, the FSYNC connection for the tentative LISTVOLUMES operation
is never closed. This results in the errors when the command completes.

Close the test connection.

Change-Id: I3c987289408407ba38cd184b7518e72ee1ae9cfc
Reviewed-on: http://gerrit.openafs.org/10476
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Attempt to clean up tvolser dependencies

The volserver only needs vl_errors.c to be locally generated, not
vlserver.h; in fact, the only consumers of vlserver.h in src/volser/
consume it via afs/vlserver.h.

Instead of reaching over to ../volser for the generated volerr.c,
generate our own local copy, as well as the volser.h generated from
the same error table -- volser.h is included with double-quotes from
the volser sources.

Add the appropriate dependencies on volser.h, and remove the unneeded
dependencies on vlserver.h

Change-Id: Ic6e728fa455419cc8e95dc25c41ed6d6b7d20934
Reviewed-on: http://gerrit.openafs.org/11380
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rx: Ignore responses to nonexistent challenges

Consider the following situation:

 - A client sends a data packet to a server, using a security class
   that requires a challenge
 - The server responds with a challenge
 - The server is restarted
 - The client responds to the challenge with a response

In that situation, the server will process the response, but since the
server was restarted, it has no knowledge of the challenge that was
sent. This generally means that we error the connection, since the
given response is not valid. For rxkad with modern endpoints, this
results in an RXKADPACKETSHORT error, since we interpret the response
as an 'old' response, but it's actually a 'v2' response, so we
interpret the fields in the response as garbage.

This means that the client gets a connection error when the client did
nothing wrong, and there's no way for the client to distinguish this
from a real connection error.

One way to solve this would be to send a Challenge packet to the
client immediately when we detect that this situation has occurred.
However, if we do that, then we never see a data packet with a
checksum, so we fall back to using "old" challenges and responses. And
in general, that would cause the server side to never see a data
packet during the connection negotiation, which is unusual and I am
concerned there may be other niggles of odd behavior that may occur in
that scenario.

So instead, to fix this, make the server ignore responses in this
situation (that is, if we haven't sent out any challenges yet).
Clients will eventually resend the data packet, and we will go through
negotiating the connection security like normal. This should never
cause any new problems, since dropping a challenge packet must be
handled anyway (sometimes packets just get dropped). And a client will
never hang on sending the same response over and over again; clients
only ever send a Response in response to a Challenge packet.

Change-Id: Id3fae425addb2ac8ab60965213b3ebca2e64ba5d
Reviewed-on: http://gerrit.openafs.org/10315
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

vldb_check: rebuild free list with -fix

Rebuild the vldb free chain in addition to the hash chains when
vldb_check is run with the -fix option.  Print a FIX: message for
entries added to the free chain.

Example vldb with a broken free chain.

    $ vldb_check vldb.broken
    address 199364 (offset 0x30b04): Free vlentry not on free chain
    address 223192 (offset 0x36818): Free vlentry not on free chain
    address 235180 (offset 0x396ec): Free vlentry not on free chain
    Scanning 1707 entries for possible repairs

    $ vldb_check -fix vldb.broken
    Rebuilding 1707 entries
    FIX: Putting free entry on the free chain: addr=199364 (offset 0x30b04)
    FIX: Putting free entry on the free chain: addr=223192 (offset 0x36818)
    FIX: Putting free entry on the free chain: addr=235180 (offset 0x396ec)

Thanks to Kostas Liakakis for reporting this bug.

Change-Id: I57d6b17263ffe5f8818f70f8260a0dce8d85ab1f
Reviewed-on: http://gerrit.openafs.org/11598
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

RedHat: Update configure options, again

Commit 83f85c9ad6c439eb9676436a3e09c40c2813f1c1 updated the arguments
we give to configure, since --enable-disconnected and --with-krb5-conf
no longer exist. But, it only updated the configure options for the
userspace configure, and did not update the configure invocation for
building kmod kernel modules.

Update the other configure invocation, so they match and both of them
avoid using outdated configure options.

Change-Id: Ia7fe16a373b5feabd4060bd85fbf9220407082f5
Reviewed-on: http://gerrit.openafs.org/10623
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

uss: Make the uss parser private

Attempt to make the parser in uss private so that it doesn't
conflict with other libraries that might leak their parser symbols.

Change-Id: I15b52f55b419b3bbc788ced9660bc41163e2be36
Reviewed-on: http://gerrit.openafs.org/11533
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Linux: get sysname even if kernel module disabled

Fall back to `uname -r` if we aren't probing for kernel sources,
as we still need to know for the rest of the build.  While this
could be worked around by explicitly passing the sysname as an
argument, this seems friendlier.

Change-Id: I0db75ba5fc7d1f5ec08d27dfce6858b968b6ce28
Reviewed-on: http://gerrit.openafs.org/11552
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Unix CM: Avoid using stale DV in afs_StoreAllSegments

It was reported in RT 131976 that on Linux some file
corruption was observed when doing mmap writes to
a file substantially larger than the cache size.

osi_VM_StoreAllSegments drops locks and asks the OS to flush
any dirty pages in the file 's mapping.  This will trigger
calls into our writepage op, and if the number of dirty
cache chunks is too high (as will happen for a file larger
than the cache size), afs_DoPartialWrite will recursively
call afs_StoreAllSegments and some chunks will be written
back to the server.  After potentially doing this several
times, control will return to the original afs_StoreAllSegments.

At that point the data version that was stored before
osi_VM_StoreAllSegments is no longer correct, leading to
possible data corruption.

Triggering this bug requires writing a file larger than the
cache so that partial stores are done, and writing enough
data to exceed the system's maximum dirty ratio and cause
it to initiate writeback.

To fix, just wait until after osi_VM_StoreAllSegments to
look at and store the data version.

FIXES 131976

Change-Id: I959f06b5a7a51171e7ed70189620e9d11d52efa2
Reviewed-on: http://gerrit.openafs.org/11644
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

doc: document the vldb free list

Document vldb free list in the vldb format (vldb.txt). The nextIdHash[0]
is on the free chain when the vl entry is free.

Also fix two typos in vldb.txt.

Change-Id: I5d79f55214295e029e7174ef46838afd7dc44bf1
Reviewed-on: http://gerrit.openafs.org/11597
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

afs: Fix some afs_conn overcounts

The usual pattern of using afs_Conn looks like this:

  do {
      tc = afs_Conn(...);
      if (tc) {
          code = /* ... */
      } else {
          code = -1;
      }
  } while (afs_Analyze(...));

The afs_Analyze call, amongst other things, puts back the reference to
the connection obtained from afs_Conn. If anything inside the do/while
block exits that block without calling afs_Analyze or afs_PutConn, we
will leak a reference to the conn.

A few places currently do this, by jumping out of the loop with
'goto's. Specifically, in afs_dcache.c and afs_bypasscache.c. These
locations currently leak references to our connection object (and to
the underlying Rx connection object), which can cause problems over
time. Specifically, this can cause a panic when the refcount overflows
and becomes negative, causing a panic message that looks like:

  afs_PutConn: refcount imbalance 0xd34db33f -32768

To avoid this, make sure we afs_PutConn in these cases where we 'goto'
out of the afs_Conn/afs_Analyze loop. Perhaps ideally we should cause
afs_Analyze itself to be called in these situations, but for now just
fix the problem with the least amount of impact possible.

FIXES 131885

Change-Id: I3a52f8ccef24f01d04c02db0a4b711405360e323
Reviewed-on: http://gerrit.openafs.org/11464
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

doc: fix unbalanced <listitem> in AdminGuide/auagd018.xml

This was introduced by c04c57c6c57d2e0b09ba60b68de738b636c9450b

Change-Id: I2dbc558bf97673074c774b457b53b4a4436b43c1
Reviewed-on: http://gerrit.openafs.org/11624
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

doc: fix duplicate tag usage in QuickStartUnix

The duplicate LIWQ54 tag appears to break newer versions of fop.  Since it
isn't referenced by anything, just remove in both instances.

Change-Id: Ie996f0110a9114399a1873ebda1eba4c7696f716
Reviewed-on: http://gerrit.openafs.org/11623
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rxgen: Only cast array/pointer/vector types

Assuming the correct values are passed to the xdr functions, no casts
are required. Don't cast simple/struct/union/typedef values. Do cast
array/pointer/vectors, since the relevant xdr wrapper functions expect
char *.

Change-Id: I375c03899576735668c1a0df0af47377223ae97a
Reviewed-on: http://gerrit.openafs.org/10260
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

rxgen: Always pass aliases (typedefs) as pointers

Since prototypes were introduced, xdr functions for typedef foo
expect a foo *, never a foo, even if the underlying type is an array.
print_param (for stubs) got this right, but print_stat (for inter-xdr
calls) did not.

Change-Id: I2b12aaf919fd39e6195d85072fdfd915a1c509f0
Reviewed-on: http://gerrit.openafs.org/10259
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Remove sunrpc compatibility

Remove sunrpc compatibility from rxgen. It's not tested, and
rpcgen is available from other sources. This will allow changes to be
made to rxgen without worrying about their impact on rpcgen compatibility.

Removals consist of the -l, -m, and -s switches, the source files
rpc_clntout.c and rpc_svcout.c, and the scan tokens 'program' and
'version'. The -R switch ('R compatibility') is also removed, as it's
a noop.

Change-Id: I960fac14faf072d221b8cb166e9388ab4accfa26
Reviewed-on: http://gerrit.openafs.org/10258
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

vlserver: Refactor auditing

Refactor auduting to be more like other uses in the code base.
Auditing is now done in a wrapper.

Change-Id: I491aeda31c223e594e3870573871ae10a541d010
Reviewed-on: http://gerrit.openafs.org/11315
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

redhat: do not overwite the server CellServDB

The bosserver creates a pair of symlinks in the client's configuration
directory (/usr/vice/etc) during startup, if the configuration files are
not present:

  /usr/vice/etc/CellServDB -> /usr/afs/etc/CellServDB
  /usr/vice/etc/ThisCell -> /usr/afs/etc/ThisCell

Due to a bug in the bosserver (which is not fixed on 1.6.x), the
symlinks are only created when the /usr/vice/etc directory already
exists when the bosserver is started.

If the bosserver is started before the client is installed (and the
/usr/vice/etc directory is present), then the packaging script will
write to the symlink CellServDB, overwriting the server's CellServDB with
the contents of the client's CellServDB.local and CellServDB.dist files.
Also, if the client is started after the bosserver creates the symlinks,
the client init script will overwrite the server's CellServDB with the
contents of the client's CellServDB.local and CellServDB.dist files.

Update the packaging and the client init script to delete this symlink
if present, since it is only intended to provide stub configuration
for the client utilities while setting up an initial server.  Then,
the updating of the CellServDB will create a local file, instead of
following the symlink and overwriting the server CellServDB.

While here, adjust the indentation whitespace to match the tabs below.

Change-Id: I802fd8d85f73946ca8d8d57e115abb8ae6958196
Reviewed-on: http://gerrit.openafs.org/11601
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

afs: Add xvcache-related afs_FlushVCache comments

Add a couple of comments to help make it explicit when it is okay to
drop afs_xvcache here.

Change-Id: I451ffe80755ea471322e32017f71c0619e6a8e63
Reviewed-on: http://gerrit.openafs.org/7436
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Remove 'slept' from osi_VM_FlushVCache

No implementation of osi_VM_FlushVCache drops and reacquires
afs_xvcache. Doing so would cause problems when afs_FlushVCache calls
osi_VM_FlushVCache, since someone could grab a reference to the vcache
while xvcache is dropped. So, prohibit dropping and reacquiring
afs_xvcache in osi_VM_FlushVCache, and remove the 'slept' argument to
it.

Change-Id: I50b4ee35f54a5277749f44e93b1094e4fb5c93e9
Reviewed-on: http://gerrit.openafs.org/7435
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Correct routine name on error message

While studying some code I noticed one of the error messages in
afs_UFSGetVolSlot was prefixed with a different routine name.
More shocking was that git blame fingered me as the last person
to update that line!  Indeed I had but I hadn't noticed, nor had
my reviewers, the mis-matched routine name.

Update afs/afs_volume.c to correct routine name.

Change-Id: Id7ee275c9f8991bb71082b9dfcd52c14ead83955
Reviewed-on: http://gerrit.openafs.org/11625
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

afs: Remove AFS_BOZONLOCK_ENV

The only user of AFS_BOZONLOCK_ENV is ppc_darwin_80.  This was added
to the param file by commit:

    commit 379e3be3196aeb3fefaa1e9296e52a9f8018550a
    Author: Derrick Brashear <shadow@dementia.org>
    Date:   Sun Jun 19 00:20:01 2005 +0000

        ppc-darwin80-20050618

        this is actually a throwaway

It isn't clear to me what the intent was.  Darwin clearly isn't
using the Bozon lock around every osi_FlushPages() despite comments
in DARWIN/osi_vnodeops.c about said lock.   The possibility of the
Bozon lock being required only ppc_darwin_80 and not ppc_darwin_70 and
ppc_darwin_90 is unlikely.

The comments about the Bozon lock in FBSD/osi_vnodeops.c appears to be
a copy/paste from DARWIN's.  Curiously, FBSD doesn't drop the GLOCK()
when osi_FlushPages() calls osi_VM_FlushPages() despite a comment to
the contrary in osi_VM_FlushPages().

Also, instead of editing the alpha_dux param files, just remove them.
Nothing is using them.

Change-Id: Ic1f6aabd82b9bd3686c95fd501a9d72163595421
Reviewed-on: http://gerrit.openafs.org/11108
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

budb:  Avoid use of anonymous structures to determine size

Change-Id: Ife337e4e020a0450020f9ae641b1711435b936c4
Reviewed-on: http://gerrit.openafs.org/8153
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

volser: Break callbacks to the target of VolClone

With the "-stayup" release mechanism, clients may have callbacks
to the target of VolClone rather than the target of VolRestore,
so also break callbacks there.

This could cause clients to not be notified of a volume release
done with -stayup and have stale contents.

Change-Id: I94009f4b9382471a3615d2a729e4ee3955a14d44
Reviewed-on: http://gerrit.openafs.org/11619
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Remove FreeBSD packaging

The packaging used by official FreeBSD package builds is taken from
the FreeBSD Ports Collection's version control, which is currently
available at https://svnweb.freebsd.org/ports/head/net/openafs/ .

The version of the FreeBSD packaging in the openafs repository
will almost always be out-of-date and is not needed by FreeBSD
(although a small portion of it is currently used by the upstream
FreeBSD packaging), and the actual packaging used by FreeBSD is
easily available, so there is no purpose in maintaining FreeBSD
packaging in the OpenAFS source code repository.

Change-Id: I969cd6933ecd56d6940b8d48da67f50260101571
Reviewed-on: http://gerrit.openafs.org/11622
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Remove Debian packaging

The packaging used for uploads to Debian is maintained on Debian
infrastructure, presently at
http://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git .

The packaging repository for any given Debian openafs source
package will be listed in the Vcs-* fields in the package's
control file.

The version of the Debian packaging in the openafs repository
will almost always be out-of-date and is not used by Debian,
and the actual packaging used by Debian is easily available, so
there is no purpose in maintaining Debian packaging in the OpenAFS
source code repository.

Change-Id: I23011315ece011e32cdddd992c4f8a176e348c67
Reviewed-on: http://gerrit.openafs.org/11621
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

build-sys: make docbook path find easier to read

Additional gain, when horizontal lists are converted to vertical, is that
each item will be individually version controlled.

Change-Id: I4f12efac9c3d828fafdc7ab8a15740cfb0276538
Reviewed-on: http://gerrit.openafs.org/10014
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Make all VLDB interactions use VLF/VLSF names

src/volser/volser.p.h defined the values used in VLDB entries.  These values
appear (by exhaustive walk of source and by inspection of the volser's rxrpc
api) to be unused by any aspect of the volser and were solely used in
communication with the VLDB.

This patch deletes the misplaced definitions and moves the entire tree to
use the VLF_{RW,RO,BACK}EXISTS and VLSF_* macros from vlserver/vldbint.xg .
No include wrangling was needed; these definitions have always been in scope
but relatively unused.

It also serves to head off a potential problem, which actually motivated the
whole thing: ITSRWREPL was 0x10, which was claimed as VLSF_UUID;
VLSF_RWREPLICA is 0x40, which did not have an ITS equivalent.  As ITSRWREPL
was not used, this had never shown itself in operation.  There was no ITS
semantic equivalent of VLSF_UUID.

Change-Id: I60426c2635976b9ac34bf820a8aec7a0c8575e20
Reviewed-on: http://gerrit.openafs.org/11331
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

DeleteVolume should check ITSROVOL as a bit

Other bits may be asserted even if this is a RO vol.

Change-Id: Iff5256db25502b61b161ec068bd9d2a389f796c7
Reviewed-on: http://gerrit.openafs.org/11617
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Revert "vos-sync-flag-voltype-properly-20080521"

The convention appears to be that ITSRWVOL is the correct flag for
the backup volume.

This reverts commit dcafea769a1cb70c7b1f8763ae4f7b7744b2a436.

Change-Id: I0f88107d56817515f41a68062053b263683afc94
Reviewed-on: http://gerrit.openafs.org/11341
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

build-sys: reindent AC_ARG_WITH section in acinclude.m4

Change-Id: I80b68eeecf9f72ac7f2ce133d9a5642a67dde22c
Reviewed-on: http://gerrit.openafs.org/10013
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

namei: Remove icreate tfd hack

Currently, the namei icreate routine creates a fake FdHandle_t for a
SetLinkCount call if we're creating a linktable. In the past this was
probably done because we did not want to open a "real" fdP ,since that
would mean opening another file descriptor, when we already had a file
descriptor (from the creating afs_open call).

This is a problem in the salvager, since it means that we can reach
ihandle code before the ihandle package has been initialized.
Specifically, we can reach icreate -> namei_SetLinkCount -> ih_fdsync.
If we reach ih_fdsync without the ihandle package being initialized,
we assert and dump core.

The ihandle package assumes that we've already initialized it if we
reach any ihandle code, since creating any IHandle_t causes the
package to initialize. But since namei_icreate fakes its own IHandle_t
and FdHandle_t structures, that doesn't happen.

So, to avoid this, stop faking our FdHandle_t and create a real one.
Since we have ih_attachfd, we can create a real FdHandle_t with our
existing file descriptor.

Change-Id: I7a8c1e0ed1ee8e5c8ce2e165b9493811d5d2435d
Reviewed-on: http://gerrit.openafs.org/10213
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

kauth: fix klog principal name parsing

If a principal name is specified to the klog command, it is not
correctly passed in the pw structure.  This in turn causes
uninitialized storage to be passed to ka_UserAuthenticateGeneral.
This may either lead to a segmentation fault in klog, or cause
garbage to be passed to the kaserver, leading to garbage in some
log and audit messages.  In all cases it is impossible to authenticate
to kaserver with a specified principal name.  However, klog
still works correctly when no principal name is specified.

This was introduced by commit 68ce3aa814a7e3085242e705f013f05ed5da2d5c
which removed lclpw to eliminate a clang warning.  However, the clang
warning was misleading in this case, as lclpw was actually used
(confusingly) to indirectly update the pw structure.

Instead of reverting this commit, just update pw->pwname directly.

Change-Id: I565360c6e2f970637422e8b01998d3fc29874ec4
Reviewed-on: http://gerrit.openafs.org/11145
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

auth: Clean up and document functions in netrestrict.c

Clean up and document parseNetRestrictFile_int and ParseNetInfoFile_int
in preparation for some future changes.

Change-Id: I3c8f1823ba1e042fb6ae68c6f0aba58128ef5b81
Reviewed-on: http://gerrit.openafs.org/11312
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Export xdr_nbulkentries in liboafs_vldb

Change-Id: Id6ba0e4fdb802cc10aa98b32d7e7c9b605c90606
Reviewed-on: http://gerrit.openafs.org/11334
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

liboafs_util: export symbols for tabular_output

Otherwise compilation fails on AIX.

Change-Id: Id22b7726d9aa56f9a2e0665257b3099baf774896
Reviewed-on: http://gerrit.openafs.org/10326
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

doc: Document fs listquota 2TB partition limit

We have previously documented that volumes over 2TB can result in
inaccuracies, but this documentation does not say how the 'partition'
field in "fs listquota" can be inaccurate. It is confusing to see a
usage of 0% for a partition that you know is being used, so try to
briefly explain in what way this field is inaccurate.

The reason we _under_-report the partition usage is that the
fileserver actually gives back PartBlocksAvail and PartMaxBlocks (not
"blocks used" and "blocks total"). So 1TB used and 4TB total is
truncated to 2TB and given back as 2TB free and 2TB total. One we hit
3TB used we'll report it as 1TB free 2TB total (50%) when the actual
usage is 75%.

Change-Id: I0b3de04ef2bd6cd32fdcb1a82cbac58d5d621e5b
Reviewed-on: http://gerrit.openafs.org/11245
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

vol: Make FindLinkHandle static and namei-only

FindLinkHandle is only referenced inside vol-salvage.c. Also, the
concept of a link table only exists on namei, so the function is only
used for the namei server (and it's only called by other namei-only
code).

So, make the function static, and put it inside the AFS_NAMEI_ENV
ifdef, to be a little more clear about where it can be used. Moving it
inside the AFS_NAMEI_ENV ifdef also avoids a warning if FindLinkHandle
is made static, since otherwise the function would be defined but
unused on non-namei.

This change should incur no difference in behavior; it is just code
reorganization.

Change-Id: Ia8cdadafaf15c724462f600514aa59910619a090
Reviewed-on: http://gerrit.openafs.org/10848
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

ubik: Unlock version lock before udisk_end

Currently, BeginTrans calls udisk_end with UBIK_VERSION_LOCK held when
it gets an error from DISK_Begin. However, udisk_end itself acquires
UBIK_VERSION_LOCK to update the database flags, so this causes a
deadlock.

So, unlock UBIK_VERSION_LOCK before calling udisk_end. Also unlock it
before calling DISK_Abort, udisk_abort, and DISK_Begin, as well, since
none of those modify fields protected by UBIK_VERSION_LOCK. (Any read
access is allowed because we DBHOLD the database.) This commit unlocks
the lock immediately after we are done modifying versioning
information, which is right after we change writeTidCounter for write
transactions.

Change-Id: I31343d67c82734ff88b76bec740ef16767bb9667
Reviewed-on: http://gerrit.openafs.org/11541
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

ubik: Convert DoProbe 'i' to 'nconns'

DoProbe was using the variable 'i' to keep track of how many
connections we have in the conns array. Keep track of this separately
using a variable called 'nconns' instead, to make this function a bit
less confusing.

Change-Id: Ica2b4901c083b315e901366820042fad64030b3c
Reviewed-on: http://gerrit.openafs.org/11540
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

libafs: remove "Please install afsd with check server daemon" warning

Apparently, ancient versions of afsd did not start the check server
daemon (AFSOP_START_CS). The afs_Daemon tries to detect when the check
server daemon is not running and issues a warning to upgrade afsd.  The
afs_Daemon waits for the cache initialization to complete (AFSOP_GO)
before detecting if the cache server daemon is started.

Unfortunately, when running with memcache, the cache initialization is
fast enough to race with the start of the check server daemon, and the
"Please install afsd with check server daemon" message is sometimes
printed to the syslog.

Since all modern versions of afsd do start the check server daemon, this
error message is no longer needed, so just remove the message and the
flag used to print it on only once.

Change-Id: If6a57ca0e6fb7e20a1e104c46416139cf5fe785a
Reviewed-on: http://gerrit.openafs.org/11602
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Free security objects used in VolForward

VolForward and VolForwardMulti create rx security objects, but
never free them. The RXS_Close's are positioned where they are
to limit the need for conditionals

Change-Id: Iec6879270ad54c30c1fea571cea583afaca9364b
Reviewed-on: http://gerrit.openafs.org/9527
Reviewed-by: D Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

build-sys: fix indentation in test code

Change-Id: If2c0c2a0b0b01bb425f8c1658cef9df232844b1c
Reviewed-on: http://gerrit.openafs.org/10012
Reviewed-by: D Brashear <shadow@your-file-system.com>
Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

build-sys: fix m4 quotation to make upstream autotools to work

Macro arguments for AC_ARG_WITH, such as AC_CHECK_PROGS, need to be
quoted.  Unless they are the latest version of autoconf will expand
macros slightly wrong way making the configure to fail at line where
there are only two ticks.

$ ./regen.sh
[...]
$ automake -a -f
[...]
automake: error: no 'Makefile.am' found for any configure output
$ ./configure
[...]
checking pkg-config is at least version 0.9.0... yes
./configure: line 13348: syntax error near unexpected token `newline'
./configure: line 13348: `    '''

Notice that the 'automake' run is needed in order to avoid later
configure error, which would look something like.

configure: error: cannot find install-sh, install.sh, or shtool in build-tools "."/build-tools

Change-Id: I39476270f351d2f5b332c5c945d6ac67fe16dd82
Reviewed-on: http://gerrit.openafs.org/9995
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Remove UKERNEL code from files that don't need it

Remove #ifdef UKERNEL sections from auth, kauth, ptserver, and ubik sources
that are no longer part of libuafs

Change-Id: I515f65c7e634d9562680c60666a15758261aaae0
Reviewed-on: http://gerrit.openafs.org/9955
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Remove kauth headers from afs_usrops.c

Since ka_* functions are no longer called from here, we don't need
the headers

Change-Id: I538c27cf4fe2f16811d1d3056b25054c80ba5b2a
Reviewed-on: http://gerrit.openafs.org/9956
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

rxgen: skip ubik for KERNEL

Declare ubik rxgen stubs only for !KERNEL, UKERNEL doesn't need them anymore.
Don't declare ubik_client or #include ubik.h on KERNEL or UKERNEL.

Change-Id: I0b1587eb46e9efbf627f04c74e0d76f9858bffd0
Reviewed-on: http://gerrit.openafs.org/9954
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

FBSD: Drop afs_xvcache for vgone()

For FreeBSD, osi_TryEvictVCache was calling vgone() without dropping
afs_xvcache. Prior to aad83a30a82407bfa6ac15b49fd31d69b563e898, this
is what osi_TryEvictVCache did, and since the 'slept' pointer
represents whether we dropped xvcache (not whether we dropped glock),
it seems like this is the intention of the code.

Change-Id: Icb8cc86d972d7ca717bd91e250771d90931e1ba7
Reviewed-on: http://gerrit.openafs.org/7434
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

FBSD: Do not vgone() in osi_VM_FlushVCache

osi_VM_FlushVCache just needs to remove VM references to the given
vcache; calling vgone() entirely should be unnecessary. Remove the
call to vgone() and other osi_TryEvictVCache-ish stuff, and just try
to cache_purge the vnode, like the other BSD implementations do.

Change-Id: I71d71f137c04d9ef3625f6a8ae22f0ffb90b9637
Reviewed-on: http://gerrit.openafs.org/7433
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Rewrap some long lines in the toplevel Makefile

Only rewrap long lines in make scope; long lines in shell scope
are untouched.

We are inconsistent about whether continuation lines for listing
the dependencies of a target are indented by one or two tabs,
which this commit does not fix.

Change-Id: I2e438a0f42faa2ef7922d2c3b143e14bc82de826
Reviewed-on: http://gerrit.openafs.org/11178
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Remove FOREIGN

It has been unused since the original import of IBM's code.

Change-Id: Ieec597c76e53453d012f1cd86f6860ae60dade5c
Reviewed-on: http://gerrit.openafs.org/9918
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

salvager: Don't lie about locked-ness to namei_SLC

We have not locked the linktable with a prior call to
namei_GetLinkCount. So don't claim that we did.

Change-Id: I43adf92b60a0e46b90ae624e4713747585d12c67
Reviewed-on: http://gerrit.openafs.org/10198
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: D Brashear <shadow@your-file-system.com>

namei: Remove namei_SetNonZLC

This function is unused. Remove it.

Change-Id: Ie48d5370187c851afdd7cd359115d9e74d001aae
Reviewed-on: http://gerrit.openafs.org/10197
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

namei: IH_REALLYCLOSE special inode on delete

When we delete a special inode, we should IH_REALLYCLOSE it, to ensure
no other cached file handles are open for that special inode. However,
currently PurgeHeader_r does this, and then IH_DECs the special
inodes. On namei, calling IH_DEC on a special inode causes the inode
to be opened, so we create a cached file handle right after we closed
all cached file handles for that inode with IH_REALLYCLOSE.

Making namei IH_DEC not open an FdHandle_t for the given file is
non-trivial, at least when dec'ing the linktable. So instead, just
make namei IH_DEC itself issue the IH_REALLYCLOSE right before the
actual unlink() call.

With this, we can keep the cached file handle open for special inodes
until right before they are actually deleted, so we don't issue extra
unnecessary open()s and close()s.

Change-Id: I35b234ab429bc7cd0f29654cc8f854c82c961071
Reviewed-on: http://gerrit.openafs.org/10196
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

namei: Remove redundant linktable SetLinkCount

If we're setting the linktable linkcount to 0, we're about to delete
the whole linktable. So, don't bother setting the link count. Still
make sure we unlock the linktable, as we still have it locked at this
point, from the previous GetLinkCount call.

Change-Id: Ia00c1e14de6b8fcd69d594f0dbdbafa32b066dc5
Reviewed-on: http://gerrit.openafs.org/10195
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: D Brashear <shadow@your-file-system.com>

Fix unchecked calls to asprintf

The return value of asprintf() is the number of bytes printed, or -1 if there
was an error allocating a large enough buffer.  In the latter case, the value
of the result string is undefined, and so it cannot be counted on to be NULL.

This change fixes numerous places where the result of asprintf is checked
incorrectly (by examining the output pointer and not the return value) or not
at all.

Change-Id: I9fef14d60c096795d59c42798f3906041fb18c86
Reviewed-on: http://gerrit.openafs.org/9978
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

volser: make splitvol use VolumeId

convert split volume rpc to also use volumeid type

Change-Id: I6b1ed670a0abdc1487daa65b7e136a1370afd5fd
Reviewed-on: http://gerrit.openafs.org/8888
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Clean up our cleaning

'make clean' and 'make maintainer-clean' still leave around a fair
number of droppings, prior to this commit.

We were not descending into the 'tests' top-level directory while
cleaning.  Furthermore, tests/opr/Makefile needed $(LT_CLEAN), and
tests/rx/Makefile needed to spell it correctly.

The libtoolization places a lot of files to be removed in the
'pristine' target.

The processing used to implement the =include directive in the pod
sources for the man pages leaves around the non-.in versions of
files; we should clean that up in the 'pristine' target as well.

The 'pristine' target should likewise remove the man pages which
are generated from the pod files.

Additionally, the documentation build uses a Doxyfile which is
output by configure; that should be removed (if present) by the
'distclean' target.

When hcrypto was converted to libtool, the use of ${OBJECTS} in
the clean target was missed, so we were leaving around most of the
actual object files -- $(LT_CLEAN) does not handle this for us.
Change the rule to remove *.o as is done elsewhere.

The conversion of libafsrpc to libtool added a convenience library
libafsrpc_sys.la, and changed how syscall.o was generated on
most architectures, to be the result of compiling an empty .c file
(instead of just an empty .o file).  This introduced a new
intermediate file, syscall.c, which must be cleaned up.

tvolser was only listing volserver and not vos in its list of
executables to remove while cleaning.

The conversion of venus/test to libtool was not done quite right.
Makefile.libtool and the .lo suffix are only needed when libtool
is being used to link *libraries*; just Makefile.pthread suffices
when libtool is being used to link executables.  As such, remove
the inclusion of Makefile.libtool, and change the .lo targets back
to regular .o ones, and add back *.o to the list of files to remove
in the 'clean' target (it was needed there even without the
other changes to that Makefile).

Change-Id: Ifbc3eee4ad2dce54df991301bc5edd11eb29a24a
Reviewed-on: http://gerrit.openafs.org/11532
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

afs: Consolidate fheader initialization

We were initializing an afs_fheader structure in two different places,
with the same values. Consolidate these into a single function, so
updating the structure is easier. Also zero the whole structure, just
to make sure everything is initialized, even if the structure changes.

This commit should have no behavior impact; it is just code
reorganization.

Change-Id: If90757166d8490eaa053aa086c7b95349a62332e
Reviewed-on: http://gerrit.openafs.org/11510
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

vos: fix crash when getting a non-loopback host address

Fix a crash in vos when trying to find a non loopback server address.

The struct hostent h_addr_list field is a null terminated array of
pointers to addresses, in network byte order.  The struct hostent length
field is not the length of the h_addr_list array (as one would expect),
but rather the length of an address in bytes, which is always 4 for IP
version 4 addresses.

Verify the returned addresses are IPv4 and take care to not iterate
beyond the end of the address pointer array.

The non-loopback address check was introduced
commit dc2a4fe4e949c250ca25708aa5a6dd575878fd7e.

Change-Id: I75dff5ed2a7dd3c4bd6605b375a7a2ffa91eff01
Reviewed-on: http://gerrit.openafs.org/11609
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

libafs: fix some nits around the symlink VOP

Commit 3f4c1099b7b (gerrit 10474) introduced a few issues, addressed here.

vpp is idiomatically of type 'struct vnode *', not 'struct vcache *';
use pvc as the name of the parent vcache pointer instead.

Fix whitespace.

Change-Id: Ic5d98a43446861bb571fe5a260e7ae1eea1051fd
Reviewed-on: http://gerrit.openafs.org/10531
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Windows: Fix cm_AppendServerList

Should use || and not | as the operator when testing for
NULL pointers.

Change-Id: I00afe64aec4f965d6a831028b546ed01d8e9672a
Reviewed-on: http://gerrit.openafs.org/11523
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

cmd: avoid piggy-backing flags in the help string

Remove the hack to piggy-back the hidden command option
in the help string argument.

Change-Id: Iedcb6b96e98b766e3ef2c87cd6e5d41874f2c0b7
Reviewed-on: http://gerrit.openafs.org/10982
Reviewed-by: D Brashear <shadow@your-file-system.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

cmd: add flags argument to create syntax function

Add the flags argument to cmd_CreateSyntax() and update all callers.
The flags argument will be used to set command options, such as
CMD_HIDDEN.

Change-Id: Ia51be9635f262516cb084d236a9e0756f608bf16
Reviewed-on: http://gerrit.openafs.org/11430
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

FBSD: osi_vcache: remove support for unsupported FreeBSD releases

Support for FreeBSD 7.x terminated in early 2013, and it's highly
unlikely that anyone was successfully using OpenAFS in that
environment.  OpenAFS has not been tested on 7.x since at least that
time, probably longer.  This removes the #ifdefs that support pre-8.0
releases.

Change-Id: I01cbce2d98f02755b170df34d948a94525df3853
Reviewed-on: http://gerrit.openafs.org/11382
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

Export xdr_nbulkentries from liboafs_vldb

Change-Id: I117b875189f4f9de971a99ff68eca470515a11ad
Reviewed-on: http://gerrit.openafs.org/11449
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Move vos COMMONPARMS to a larger offset

Currently, vos.c leaves a gap of 12 in the argument handling array
before its common operations (-verbose, -noauth, etc.); 'vos each'
will take more, so move that to 25.

While here, switch to named constants for these arguments, which
should make it easier to do this again, if ever necessary.

Change-Id: Idc4424e5fe4efd78389ea8421db000a361b461ec
Reviewed-on: http://gerrit.openafs.org/11332
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rx: Named values for securityObjectStats types

Stop using hardcoded constants and use defined symbols for these
values.

Change-Id: I3edcf809572cb8c8360af19dcab7a12c4d1be4a9
Reviewed-on: http://gerrit.openafs.org/10528
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

Disallow creating users with ANONYMOUSID

It can result only in sadness.

Document this restriction alongside UID 0 as a reserved number.

Change-Id: Ibea2d98bc15a730bc85e84477791ca45a40f2d92
Reviewed-on: http://gerrit.openafs.org/10950
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

systemd: RemainAfterExit in openafs-client.service

Currently, if the client is started without any options that require
an extra thread (like -afsdb), all processes spawned by afsd will
exit. There may be some kernel threads still active, but those are
spawned by the kernel module, and are not child processes of the
parent afsd process, or anything like that.

Since we are a Type=forking service in systemd, systemd interprets
this situation to mean that the service has stopped successfully, and
then runs the ExecStop commands. So, for example, if our AFSD_ARGS in
our sysconfig is "-fakestat -afsdb", the service starts as normal. But
if it is changed to "-fakestat", then when openafs-client.service is
started, it immediately stops again.

To avoid this, turn on the systemd option RemainAfterExit, which tells
systemd that the service has not stopped if all of our processes have
exited. The client service will thus remain running until it is
stopped.

Issue reported by Rich Sudlow.

Change-Id: If760d3617d4afbcfac923df726eb58b03ce25771
Reviewed-on: http://gerrit.openafs.org/11440
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

NetBSD osi_crypto: use cprng(9) for random source on NetBSD 6.99/7.x

Change-Id: Id8ee7f149cdc921989a5de7dda35739147de0014
Reviewed-on: http://gerrit.openafs.org/11086
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

Update CellServDB to 20141117 snapshot

This should be all the locations we keep it in-tree.

Change-Id: I6819bf0658766aaad21ad38417295616418d41c5
Reviewed-on: http://gerrit.openafs.org/11607
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>

NetBSD: catch up to <sys/simplelock.h> removal in NetBSD 6.99.x

Change-Id: I2c663fc426914e978e98c6003419503b57a020d3
Reviewed-on: http://gerrit.openafs.org/11087
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>