DAFS: Remove AFS_DEMAND_ATTACH_UTIL

Currently we have two DAFS-related preprocessor defines in the
codebase: AFS_DEMAND_ATTACH_FS and AFS_DEMAND_ATTACH_UTIL. DAFS_FS is
the symbol for enabling DAFS code, and turns on demand attachment and
all of the related complicated volume handling; it requires pthreads.
DAFS_UTIL is supposed to be used for utilities interacting with DAFS,
but do not have pthreads and so cannot build the relevant threads for
e.g. the VLRU, so they don't support demand attachment and a lot of
more advanced volume handling techniques.

Having both of these exist is confusing. For example, currently in
partition.c we only initialize dp->volLockFile for DAFS_FS, even
though the structure exists if _either_ DAFS_FS or DAFS_UTIL is
defined. This means when only DAFS_UTIL is defined, volLockFile will
exist in the partition structure, but will be uninitialized!

Amongst other possible issues, this means right now that DAFS_UTIL
users (dasalvager is the only one right now) will try to use an
uninitialized volLockFile whenever they try to use a volume that needs
locking. Since the partition struct is usually initialized to all
zeroes, this means we'll try to issue a lock request for FD 0,
whatever FD 0 is. If FD 0 is not open, we'll fail with EBADF and bail
out. But if FD 0 is open to some random file, the lock will probably
succeed, and we'll proceed without actually locking the volume lock
file. While the fssync volume checkout mechanism still works, the
on-disk locking mechanism protects against race conditions the fssync
volume checkout mechanism cannot protect against, and so handling
volumes in this way is not safe.

This is just one example; there are other issues with the partition
headerLockFile and probably may other things; most instances of
DAFS_FS really should be enabled for DAFS_UTIL as well.

So, instead of trying to account for and fix all of these problems
individually, get rid of AFS_DEMAND_ATTACH_UTIL, and just use
AFS_DEMAND_ATTACH_FS. This means that all relevant code must be
pthreaded, but since the only relevant code is for the dasalvager, we
can just make dasalvager pthreaded. Salvaging does not make use of any
threads or LWPs, so this should not have any side-effects.

Thanks to Ralf Brunckhorst for reporting the issue where we encounter
EBADF when FD 0 is not open, leading to the discovery of this.

Change-Id: I3848eb877f26b9d65833d5ce0e03f5cf7ba28de4
Reviewed-on: http://gerrit.openafs.org/10123
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
enable Perl's strict and warnings in make-release

Declare the undeclared variables $help, $man, and @toCompress, delete
the duplicate declaration for $last, and remove the unused $tag
variable.

Change-Id: I33de42722b84207dc1bbad50539dc5bf92da2f5e
Reviewed-on: http://gerrit.openafs.org/10117
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
budb: Do not use garbage cellinfo

If the -servers option is given, we never initialize cellinfo or the
clones array. So, don't give the cellinfo structure or the clones
array to ubik in that case, or we may crash or do other weird things.

This issue appears to have been introduced in commit fc4ab52e.

FIXES 131706

Change-Id: I87681c697fec7bbfd6c73a8a9a865e4309c95963
Reviewed-on: http://gerrit.openafs.org/10115
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Do not use a non-literal format string

Now that UKERNEL's panic() is a proper varargs function (gerrit 9877),
we can use a literal format string "%s" to print the panic message.
clang warngs about a non-literal format string, and in some build
environments the warning becomes fatal via -Werror.

Change-Id: I7d8c9390e3edad7efa6ae1217f938b635423d23a
Reviewed-on: http://gerrit.openafs.org/10114
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
doc: clarify setcrypt defaults

Change-Id: I0145ecc9935786204d215a11459d170f6220657b
Reviewed-on: http://gerrit.openafs.org/10111
Reviewed-by: Jason Edgecombe <jason@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: Derrick Brashear <shadow@your-file-system.com>
Verify, not Assert, for the (util) global mutex

We don't want turning off debugging to force open this lock.

Change-Id: Ia8dd689c506e42a4bf87c83af23d7457df12f8b9
Reviewed-on: http://gerrit.openafs.org/10092
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Check for over/underflow while allocating PTS ids

The behavior of signed integer over/underflow is implementation-defined,
but even if the compiler is nice and just wraps around, we could get
ourselves into trouble later on.

Change-Id: I20ea9c790037a36b8527889b3f7adcfd60e74fd4
Reviewed-on: http://gerrit.openafs.org/10091
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Reset the child's sigmask before exec

Othewise the child inherits the signal mask of the calling thread,
which is usually not what is desired, and is additionally inconsistent
depending on which thread spawns the new process.

Check for sigprocmask (the recommended API) at configure time.

Change-Id: I41c3e1a9f0cce4bdf9ba24fff02b63aa00af8d06
Remove dead code

This stuff has been #if 0'd for ages; put it out of its misery.

While here, remove the global bnode_waiting which is not used for anything.

Change-Id: Ib70b639db4273604318e224ccc86f2f6352990a2
bozo: Use libtool

Convert bos into a libtool library and build a pthreaded version of
it.  Do the easy conversion of bos, bos_util, and smail-notifier to
pthreaded binaries, but leave bosserver to a later commit.
Still build an LWP libbos.a for compatibility.

Consolidate some dependency relations while here.

bos doesn't actually use any threading features directly, so all we have
to do is replace an IOMGR_sleep() with regular sleep().

bos_util and smail-notifier are easy, too, just make sure to add
the appropriate dependency on AFS_component_version_number.

Change-Id: Ia1aca88616bb252891bd1ec1bdf39e6352885027
Reorder bosserver startup prior to pthreads

The rx calls will take locks when built in pthreaded mode, and must go
after rx_Init().  Some other setup would benefit from using time-domain
locking and should run before we go multithreaded.

In particular, initialize bozo_confdir while single-threaded, as it is
otherwise protected by the afsconf internal locking.  While here, pass
NULL to afsconf_SetCellInfo -- bozo_confdir would always be NULL there,
anyway.

Change a couple globals into local variables in main; they are just
used to defer setup after argument parsing.

Also move up ReadBozoFile so that it can benefit from time-domain
locking as well.  All that it needs is the bnode types to have been
registered and the bnode lock to have been initialized, and for any
daemonization to have already occurred.

Change-Id: Ib0cae83f3a4423330ae6f23d3a4112499d695618
Convert bosserver to pthreads

Well, mostly.  We're cheating because there isn't a libtoolized
procmgmt library yet, but it should be safe for now.

Don't bother retaining a LWP version; this stuff is not super
complicated and is subject to only light concurrency.

Add a global bnode mutex to protect the global state -- the various
bnode queues (though not the bnodes themselves), some compound time
structures that should get a consistent snapshot, and global flags.
Add a condition variable to each bnode for signalling.

The bnode reference counting scheme is not touched; it's current
state is fairly bogus and probably broken even with LWP semantics.

No locking is done on the contents of an individual bnode; simultaneous
callers could introduce inconsistent state (but this was already the
case).

Do not use the softsig implementation, which is known to be buggy
with pthreads.  Instead, use a self-pipe to the bproc thread, whose
sole purpose is to wait for signals and timeouts.

Move creation of the bproc thread to nearly as late as possible
(with the creation of the BozoDaemon thread), to take advantage
of time-domain locking for initialization which is done while
single-threaded.  This allows several globals to be unlocked,
as they are read-only while threaded.

Change-Id: I2865e1fb011d611dd664261ae7a8f21f7ce8d7b0