afs: Free 'addrs' array

Currently, 3 places in libafs allocate an 'addrs' array in a very
similar way to loop through our list of servers:
ForceAllNewConnections(), afs_LoopServers(), and PCallBackAddr(). Of
these, only afs_LoopServers actually frees the array.
ForceAllNewConnections and PCallBackAddr leak the memory, but these
are only hit from infrequent pioctls that can only be run by root, so
the impact is small.

Fix ForceAllNewConnections and PCallBackAddr to free the array.

Reviewed-on: https://gerrit.openafs.org/13355
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0548ee436d0f0f92a980d22e03149faedf38dc70)

Change-Id: I5d64899c7be40ba3e1b0985c4829933eebbd8323
Reviewed-on: https://gerrit.openafs.org/13899
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

rx: Fix test for end of call queue for LWP

Commit 6ad3d646 (rx: Correctly test for end of call queue) fixed a
broken end-of-queue check in rx_GetCall, but it only fixed the
RX_ENABLE_LOCKS version of rx_GetCall. The non-locks version (i.e. the
LWP version) still had this bug. Fix it for the LWP case, to avoid
some rare cases where an Rx call can get stuck in the incoming queue.

Also remove the comment added by commit 170dbb3c (rx: Use opr queues),
since we're fixing the mentioned problem.

Reviewed-on: https://gerrit.openafs.org/13880
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d9fc4890f01a41fa5a63f97f2446b3afc35b473f)

Change-Id: I2e0106b63a8bf09634500944490dfae2e86c18b9
Reviewed-on: https://gerrit.openafs.org/13892
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

The interminable rework of afs_random()

Commit f0a3d477d6109697645cfdcc17617b502349d91b restructured the
operation on tv_usec to avoid using undefined behavior, but in
the process introduced a behavior change.  Historically (at least as
far back as AFS-3.3), we masked off the low nybble (four bits) of
tv_usec before adding the low byte (eight bits) of the rxi_getaddr()
output.  Why there was a desire to combine two sources of input for
the overlapping four bits remains unclear, but restore the historical
behavior for now, as the intent of commit
f0a3d477d6109697645cfdcc17617b502349d91b was to not introduce any
behavior changes.

Reviewed-on: https://gerrit.openafs.org/13759
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 1c4e94da2a8fce9d79006ad6d6673d3d7de117d3)

Change-Id: Iec10673e5ec73c1e0edcc231690cb6133fce8691
Reviewed-on: https://gerrit.openafs.org/13879
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

rework afs_random() yet again

clang 7 notes that ~0 is signed and that left-shifting into the sign
bit is undefined behvaior.  Use a new construction to clear the low
byte of tv_usec with only bitwise operations that are independent of
the width of tv_usec and stay within the realm of C's defined behavior.

Reviewed-on: https://gerrit.openafs.org/13474
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f0a3d477d6109697645cfdcc17617b502349d91b)

Change-Id: I4f0438c2fc8237968f41409ca23ac098839508fe
Reviewed-on: https://gerrit.openafs.org/13743
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Avoid incomplete function type in casts

clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void).  Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.

Reviewed-on: https://gerrit.openafs.org/13473
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 96c0b88947c7aab605170bdca633d3716051a58e)

Change-Id: I950ff8de925a1ca03e50ad7ec394123445b5ce4a
Reviewed-on: https://gerrit.openafs.org/13742
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Avoid calling krb5_free_context(NULL)

Several places in the code currently call krb5_free_context(ctx) in a
cleanup code path, where 'ctx' may or may not be NULL. This is not
guaranteed to be okay, so check for NULL to make sure we don't cause
issues in these code paths.

While we are here cleaning up krb5_free_context() calls, also fix a
few call sites in afscp_util.c that were not calling krb5_free_context
in all error paths.

Reviewed-on: https://gerrit.openafs.org/13461
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 26b1dc036719a588a5cadecb14053bd4079c1f48)

Change-Id: I3b0d22f51f4fe85897116b7f96d096570258eed2
Reviewed-on: https://gerrit.openafs.org/13902
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

vlserver: initialize nvlentry elements after read

Commit 7620bd33487207b348ed7aeba45f8d743132ba84 (vlserver: fix
vlentryread() for old vldb formats) leaves the tail end of the
serverNumber, serverParition and serverFlags arrays uninitialized since
it only copies OMAXNSERVERS elements into arrays that have NMAXNSERVERS
elements.

Initialize the elements in the nvlentry server arrays that were not
copied with BADSERVERID.

Reviewed-on: https://gerrit.openafs.org/13755
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ddf7d2a7f4bfdcab238e791cb8c49bb803e76b09)

Change-Id: I4e1065bedda0f50b85cf472d015f2c86e4af82c8
Reviewed-on: https://gerrit.openafs.org/13846
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

vlserver: fix vlentryread() for old vldb formats

When we're using old format compatibility, use OMAXNSERVERS for the
array lengths instead of MAXNSERVERS.  Otherwise we'll try to copy more
data than we've read.

Detected by gcc8 as:

vlutils.c:183:2: error: ‘memcpy’ forming offset [149, 151] is out of the bounds [0, 148] of object ‘tentry’ with type ‘struct vlentry’ [-Werror=array-bounds]
  memcpy(nbufp->serverFlags, oep->serverFlags, NMAXNSERVERS);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vlutils.c:141:26: note: ‘tentry’ declared here
     struct vlentry *oep, tentry;
                          ^~~~~~

Reviewed-on: https://gerrit.openafs.org/13465
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7620bd33487207b348ed7aeba45f8d743132ba84)

Change-Id: I7dc4ad48805c6a82dd021d156fe187dd97e5b456
Reviewed-on: https://gerrit.openafs.org/13734
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

uss: Allocate buffer space for trailing NUL

Appease gcc8's -Wformat-truncation engine.

Reviewed-on: https://gerrit.openafs.org/13467
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9a5ba85d1853327d8184287e58a6e03fabaaf23d)

Change-Id: I9900452b951d600e6358b216015fe4fcdf8f633e
Reviewed-on: https://gerrit.openafs.org/13736
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

uss: uss_procs.c format-overflow warning

GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning.  With --checking-enabled, this error is causing
uss_procs.c to fail during compile.

A file name with the full path is being composed and the size of the
buffer was triggering a possible format-overflow warning/error.

Use asprintf to allocate the buffer dynamically instead of using a
buffer sitting on the stack (reducing the stack requirements by 2K).

Produces new error message if asprintf returns an error.

Reviewed-on: https://gerrit.openafs.org/13664
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 41ee558329560bce037ad2860282d8b49aa11b2d)

Change-Id: I5c5866142ae17c92017201fb567f847b5c2907a0
Reviewed-on: https://gerrit.openafs.org/13729
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: testpt.c format-overflow warning

GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning.  With --checking-enabled, this error is causing
testpt.c to fail during compile.

Change the buffer size from 16 bytes to PR_MAXNAMELEN+1 and use snprintf
instead of sprintf. Generate an error message and exit if snprintf
truncates the string.

Reviewed-on: https://gerrit.openafs.org/13663
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a57cc54dfb6789a86ee735360ee44209c1a901a)

Change-Id: I2f8012e7fb4384f3ad877d2c9beb5f00b03716b8
Reviewed-on: https://gerrit.openafs.org/13730
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: Incorrect variable used to print error msg

In testpt.c the variable cdir is used to print the name of the temporary
dir.  However at this point in the code cdir is NULL and the variable
tmp_conf_dir contains the actual name that should be used in the error
message.

Flagged as an error when --enable-checking is on and using GCC 9.

Reviewed-on: https://gerrit.openafs.org/13662
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f938f5f248a3cb3f7ac871f5ef45a0e2d043706b)

Change-Id: I1b993ddc2545f90736811e2eb85ba4b3bae6e657
Reviewed-on: https://gerrit.openafs.org/13728
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

aklog: require opt-in to enable single-DES in libkrb5

Since the introduction of rxkad-k5 in response to OPENAFS-SA-2013-003,
it is not strictly necessary to configure libkrb5 to allow weak crypto
in order to obtain an AFS token.  A sufficient amount of time has passed
since then that it is safe to assume that the default behavior is the
more-secure one, and require opt-in for the insecure behavior.

To indicate that the use of single-DES is quite risky, add the
"-insecure_des" argument to both klog and aklog, to gate the
preexisting calls that enable weak crypto/single-DES.
These calls, and the -insecure_des option, may be removed entirely
in a future commit.

Reviewed-on: https://gerrit.openafs.org/13689
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit eaae6eba8ca10ba7a5a20ee0d1b5f91bc2bac6c6)

Change-Id: I197042e12567fa0fed1b6584e85c3f0a520efa4c
Reviewed-on: https://gerrit.openafs.org/13791
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

rxkad: ticket5.c fix typo in #if statement

commit 98ca332c4a5ac9e5687fb4fe21b350134bc74d1b (rxkad: v5der.c format
truncation warnings) contains a typo in the test for clang (_clang
instead of __clang__)

Correct the typo in the #if statement to test for __clang__

Reviewed-on: https://gerrit.openafs.org/13754
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e3dbd8a5886734f6390126e155cc259b0de5af51)

Change-Id: I6c2a9851e668947c61d97e013c84808f738c4e52
Reviewed-on: https://gerrit.openafs.org/13756
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

rxkad: v5der.c format truncation warnings

GCC 7 is producing new warnings due to better compile time analysis.
With --enable-checking v5der.c is failing with 2 errors due to possible
format-truncation in some snprintf calls.  The format strings are being
used to format a date and time values from a tm structure.

The actual warnings/errors are being triggered from arithmetic being
performed on the year and month members of the structure. The resulting
values should not exceed the format lengths, but the compilers are still
flagging the statements.

v5der.c is part of the heimdal package that is pulled into the openafs
source tree.  v5der.c is not compiled directly but is #included in
ticket5.c

Update ticket5.c to change the severity of the format-truncation
diagnostic to a warning if using GCC 7 (or higher).

Note: since v5der.c is pulled from an external source (heimdal), any
changes to update v5der.c directly would need to be performed upstream.

Reviewed-on: https://gerrit.openafs.org/13661
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 98ca332c4a5ac9e5687fb4fe21b350134bc74d1b)

Change-Id: I1a808060b302549887e529e74bc3805d9431c499
Reviewed-on: https://gerrit.openafs.org/13727
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: Increase length limit of namelist, idlist, prlist, prentries

An implementation limit of those lists was introduced in commit
a0ffea098d8c5c5b46c6bf86a12d28d6e7096685 to prevent using unlimited
amounts of memory in ptserver and the client.  Subsequent reports
indicate that the chosen limits are small enough to restrict
functionality currently in use at some sites where membership lists
exceed the current limit.  Since this is just an implementation-
defined limit and can freely change from release to release, increase
the threshold by an order of magnitude to preserve functionality for
existing deployments while still retaining some protection against
attacker-controlled excessive memory allocation.

Reviewed-on: https://gerrit.openafs.org/13838
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d1e90b82ebb2685cbac3ecb3fd99136328b35357)

Change-Id: Ifa229179ad6d2962a8d49df6abd1add94fad7259
Reviewed-on: https://gerrit.openafs.org/13844
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

WINNT: Link tbutc against mtafsutil.lib

tbutc uses pthreads, not LWP, so link it against mtafsutil.lib (a
pthread library), and not afsutil.lib (an LWP library).

Reviewed-on: https://gerrit.openafs.org/13822
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7a76f4dc00984d42b0535a8edbedee034ada896f)

Change-Id: I133fff53d1974658ed1fe95e48abd9779a346a4f
Reviewed-on: https://gerrit.openafs.org/13852
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

rx: Export rx_GetCallStatus

Commit 59d3a8b8 (vos: restore status information to 'vos status')
added the function rx_GetCallStatus to Rx, and used it in the
volserver, but didn't add the function to our .sym and .exp files,
causing a linker error on at least WINNT.

Add the function to the relevant .sym/.exp files, so we can link on
all platforms.

Change-Id: I859ac6d04d8a21eb6f8b4ba3f3720ca318e91334
Reviewed-on: https://gerrit.openafs.org/13820
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c3716b3d7e32f47b084657e163b029e9f1756fa4)
Reviewed-on: https://gerrit.openafs.org/13851
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

WINNT: Link butc against audit

Since commit c43169fd (OPENAFS-SA-2018-001 Add auditing to butc server
RPC implementations), butc references symbols from audit. So add audit
to our libraries to link against, so we can link butc on WINNT.

Reviewed-on: https://gerrit.openafs.org/13818
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e4b689e8c7cb39b72854dd38b6a92134591c8bca)

Change-Id: Ib27755730178afbbd85e3aad265c1f956b3785ef
Reviewed-on: https://gerrit.openafs.org/13850
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Avoid giving wrong 'tf' to afs_InitVolSlot

Commit 75e3a589 (libafs: afs_InitVolSlot function) split out a bit of
our code that initializes a struct volume into the afs_InitVolSlot
function. However, it caused us to almost always pass a non-NULL 'tf'
to afs_InitVolSlot, even if the target volume was not found.

That is, before that commit, our code roughly did this:

    for (...; j != 0; j = tf->next) {
        ...;
        tf = &staticVolume;
        if (tf->volume == volid)
            break;
    }
    if (tf && j != 0) {
        use_tf_data();
    } else {
        use_blank_data();
    }

The reason for the extra 'j != 0' check after the loop is to see if we
hit the end of the volume hash chain, or if we actually found a
matching 'tf' in the loop.

And after that commit, the code did this:

    for (...; j != 0; j = tf->next) {
        ...;
        if (j != 0) {
            tf = &staticVolume;
            if (tf->volume == volid)
                break;
        }
    }
    if (tf) {
        use_tf_data();
    } else {
        use_blank_data();
    }

The check for 'j != 0' was moved to inside the for loop, but 'j' is
always nonzero in the loop (otherwise, the for() would exit the loop).
This means that if we didn't find a matching 'tf' in the loop, our
'tf' would be non-NULL anyway, and so we'd initialize our volume slot
from just the last entry in the hash chain.

This means that for volumes that are not found in the VolumeItems
file, our struct volume will probably be initialized with arbitrary
data from another volume, instead of being initialized to the normal
defaults (the 'else' clause in afs_InitVolSlot).

This means that the 'dotdot' entry for the volume may be wrong, and so
we may report the wrong parent dir for the root of a volume. However,
the 'dotdot' entry should be fixed when the volume root is accessed
via a mountpoint, so any such issue should be temporary. And of
course, on some platforms (LINUX) we don't ever use the 'dotdot'
information for a volume, and even on other platforms, often resolving
the '..' entry is handled by other means (e.g. shells often calculate
it themselves). But some 'pwd' calculations and other '..' corner
cases may be affected.

To fix this, change the relevant loop so that we only set 'tf' to
non-NULL when we actually find a matching entry.

Reviewed-on: https://gerrit.openafs.org/13933
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a9078c6bbf51720a5eacf7e6ba21443e5103eee)

Change-Id: Ib1e7519db8f844872c4b88b54978f358ff7b299e
Reviewed-on: https://gerrit.openafs.org/13937
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

viced: consistently enforce host thread quota for ICBS(3)

From time to time, the fileserver may issue potentially long-running
RXAFSCB_* RPCs back to a host (client).  If these are holding h_Lock_r
(host->lock) while running, they may cause other service threads for the
same host (client) to block.

In order to prevent a given host from tying up too many service threads
in this way, the fileserver enforces a quota limiting how many threads
can be waiting for h_Lock_r on a particular host while waiting for one
of the following RPCs to complete:
- RXAFSCB_TellMeABoutYourself (TMAY)
- RXAFSCB_WhoAreYou
- RXAFSCB_ProbeUuid
- RXAFSCB_InitCallBackState (ICBS)
- RXAFSCB_InitCallBackState3 (ICBS3)

Note: Although some of these RPCs are relatively lightweight, they may
still experience network delays.

This quota is enforced by calling h_threadquota() in h_Lookup_r and
h_GetHost_r.  The quota check is enabled for a given host by turning on
host->hostFlags HWHO_INPROGRESS for the duration of the RXAFSCB_* RPC.
The quota check is only needed, and should only be enabled, when the RPC
is issued while h_Lock_r is held.

However, there are a few paths to ICBS(3) where h_Lock_r is held but
HWHO_INPROGRESS is not set.  A delay in those paths may allow a host to
consume an unlimited number of fileserver threads.  One such path
observed in a field report was SRXAFS_FetchStatus -> CallPreamble ->
BreakDelayedCallBacks_r -> RXAFSCB_ICBS3.

Instead, enable host thread quotas for all remaining unregulated ICBS(3)
RPCs.

Reviewed-on: https://gerrit.openafs.org/13873
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit aefc4c4f46e13f59b4cbe043e1a2a6f4ed99e076)

Change-Id: If3883a152078bba9995e0c8a13ab31788db6347f
Reviewed-on: https://gerrit.openafs.org/13893
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

kauth: Move COUNT_REQ to beginning of block

Commit b604ee7a (OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry
information leak) added a memset in kamListEntry before COUNT_REQ, but
COUNT_REQ declares a local variable. This breaks the WINNT build,
because we must declare variables at the beginning of a block.

To fix this, just swap the two lines.

Reviewed-on: https://gerrit.openafs.org/13815
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b9b5385e6a04dcacd180f33e39495c7909fe4df3)

Change-Id: Id9c1fd67e4614f8f433415486e107ecb4bd0d708
Reviewed-on: https://gerrit.openafs.org/13849
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

WINNT: Build bubasics before audit

Commit 9ebff4c6 (OPENAFS-SA-2018-001 audit: support butc types) made
src/audit require the butc.h header, and updated Makefile.in to
reflect this. However, this dir is also built on WINNT, and the
NTMakefile was not updated to reflect this dependency. As a result, we
might fail to build src/audit on WINNT, since butc.h may not exist
yet, and we get an error like:

            cl [...] /c audit.c
    audit.c
    cl : Command line warning D9025 : overriding '/W4' with '/W3'
    audit.c(27) : fatal error C1083: Cannot open include file: 'afs/butc.h': No such file or directory
    NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.EXE' : return code '0x2'

To fix this, move 'bubasics' to be made before 'audit' in NTMakefile,
so butc.h is available when we build 'audit'.

Reviewed-on: https://gerrit.openafs.org/13813
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9eeb3ec09f5421ceab2be415a193bb3a3c44925f)

Change-Id: If36de5664ea0eb7208810c224d30092f0a4d1745
Reviewed-on: https://gerrit.openafs.org/13848
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Avoid panics in afs_InvalidateAllSegments

Currently, afs_InvalidateAllSegments panics when afs_GetValidDSlot
fails. We panic in these cases because afs_InvalidateAllSegments
cannot simply return an error to its callers; we must invalidate all
segments for the given vcache, or we risk serving incorrect data to
userspace as explained in the comments.

Instead of panicing, though, we could simply sleep and retry the
operation until it succeeds. Implement this, retrying every 10
seconds, and logging a message every hour that we're stuck (in case
we're stuck for a long time).

When we retry the operation, do so in a background request, to avoid a
somewhat common situation on Linux where we always get I/O errors from
the cache when the calling process has a SIGKILL pending. Create a new
background op for this, BOP_INVALIDATE_SEGMENTS.

With this, the relevant vcache will be effectively unusable for the
entire time we're stuck in this situation (avc->lock will be
write-locked), but this is at least better than panicing the whole
machine.

Reviewed-on: https://gerrit.openafs.org/13677
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 3be5880d1d2a0aef6600047ed43d602949cd5f4d)

Change-Id: Iba1cde70a4d5e919fedfe27d0540878113a369e4
Reviewed-on: https://gerrit.openafs.org/13847
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

gtx: Avoid incomplete function type in casts

clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void).  Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.

Reviewed-on: https://gerrit.openafs.org/13726
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d6262c3f391e4176bec207fd0e8d4d6091a7f4e2)

Change-Id: I4544c37591bb68ff6bbe345192490bb79c843fc5
Reviewed-on: https://gerrit.openafs.org/13749
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

libadmin: appease clang -Wsometimes-uninitialized

clang thinks that 'time' can be used uninitialized:

bos.c:1472:9: error: variable 'time' is used uninitialized whenever 'if' condition is
      false [-Werror,-Wsometimes-uninitialized]
    if (as->parms[TIME].items) {
        ^~~~~~~~~~~~~~~~~~~~~
bos.c:1478:57: note: uninitialized use occurs here
    if (!bos_ExecutableRestartTimeSet(bos_server, type, time, &st)) {
                                                        ^~~~
bos.c:1472:5: note: remove the 'if' if its condition is always true
    if (as->parms[TIME].items) {
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
bos.c:1445:5: note: variable 'time' is declared here
    bos_RestartTime_t time;
    ^

but in this command description, the TIME argument is required.
Add a never-triggered error exit to appease the compiler when
--enable-checking is activated.

Reviewed-on: https://gerrit.openafs.org/13476
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 453060c27a5d33d3c27128d169298f9d66d06f1a)

Change-Id: Iac80d4ec7c2a33dcb470de2daedf693c20b96b00
Reviewed-on: https://gerrit.openafs.org/13745
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

uss: signed/unsigned char fallout

When char is signed, assigning 255 to a variable of type char changes
the value, which causes clang to emit a warning and fail the
--enable-checking build.

Reviewed-on: https://gerrit.openafs.org/13475
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7c15e6efe62fb3fe1970c56331df09b257abf6d9)

Change-Id: I3dd374582b57e46460ea80ead75913948c2d2262
Reviewed-on: https://gerrit.openafs.org/13744
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

dumpscan: appease gcc8 -Wformat-overflow

gcc does not benefit from our external knowledge that tm_year is
tightly bounded, and thinks it could still be in the range
[-2147481748, 2147483647], which would overflow our string buffer.
The function in question does not have error handling in place, so
rather than adding some or trying to assert the proper bounds, just
use a slightly larger buffer for safety.

Reviewed-on: https://gerrit.openafs.org/13472
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8f03ff3bdd8eb9f4557cdb7054aee9b8ea432160)

Change-Id: I05c8d998c6d40118a1bde923e346cddbdfa4192b
Reviewed-on: https://gerrit.openafs.org/13741
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

scout: band-aid -Wformat-truncation

gcc8 gets pretty confused about the bounds on these things (presumably
due to our alignment options) and thinks this could potentially be a huge
string.  Check for truncation to appease the compiler, instead of trying
to ensure that the buffer is big enough.

Reviewed-on: https://gerrit.openafs.org/13470
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit df8534909fdc1fa8417aa788c0fa71c5dbe7eb30)

Change-Id: Idf3a2f32ba4630a7d11b2c0664c6dd9b694eb7db
Reviewed-on: https://gerrit.openafs.org/13739
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

butc: -Wformat-truncation fallout

Increase some buffer sizes to appease gcc8.  While here, use snprintf
instead of plain sprintf(!).

Reviewed-on: https://gerrit.openafs.org/13468
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a89297a066d8689f8fc29a7428cfe3ed6235d010)

Change-Id: If26312359d62649077e1f8adf2c9e0b39d28496f
Reviewed-on: https://gerrit.openafs.org/13737
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

vlserver: use large enough buffer for rxinfo string

The "[dotted-quad] rxkad:name.inst@cell" construct can be as large as
(3*4+3)+7+3*64+2+1 == 217 characters (including trailing NUL); size
our buffer accordingly to avoid the risk of truncation.

Reviewed-on: https://gerrit.openafs.org/13466
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 584b0f2b6b4391c0c879352bb1786c0f267666c9)

Change-Id: Ia11e685ec17f34a9a8fdc42d392b8a2677f63696
Reviewed-on: https://gerrit.openafs.org/13735
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

vol: avoid -Wformat-truncation issues in vol-salvage.c

Make some formerly-64-character buffers VMAXPATHLEN (plus a smidgeon)
to give them space to hold the composed paths.

Reviewed-on: https://gerrit.openafs.org/13464
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d6b88e3bd5219a8dffebc07df23e30f1d16f095f)

Change-Id: Idd388cd23ffeff1307b9eb6d31976383b6125260
Reviewed-on: https://gerrit.openafs.org/13733
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Make OpenAFS 1.8.5

Update version strings for the 1.8.5 release.

Change-Id: I6e4e4b02b2ad7686027e983d63919cd3045fd2d4
Reviewed-on: https://gerrit.openafs.org/13920
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

Update NEWS for 1.8.5

Release notes for the OpenAFS 1.8.5 security release.

Change-Id: Idd44efa17c41a9fa4d2d3beddb294a1c24bdec9e
Reviewed-on: https://gerrit.openafs.org/13919
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

OPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref

Currently, SVOTE_Debug/SVOTE_DebugOld examine some ubik internal state
without any locks, because the speed of these functions is more
important than accuracy.

However, one of the pieces of data we examine is ubik_currentTrans,
which we dereference to get ubik_currentTrans->type. ubik_currentTrans
could be set to NULL while this code is running, so there is a small
chance of this code causing a segfault, if SVOTE_Debug() is running
when the current transaction ends.

We only ever initialize ubik_currentTrans as a write transation (via
SDISK_Begin), so this check is pointless anyway. Accordingly, skip the
type check, and always assume that any active transaction is a write
transaction.  This means we only ever access ubik_currentTrans once,
avoiding any risk of the value changing between accesses (and we no
longer need to dereference it, anyway).

Note that, since ubik_currentTrans is not marked as 'volatile', some C
compilers, with certain options, can and do assume that its value will
not change between accesses, and thus only fetch the pointer value once.
This avoids the risk of NULL dereference (and thus, crash, if pointer
stores/loads are atomic), but the value pointed to by ubik_currentTrans->type
would be incorrect when the transaction ends during the execution of
SVOTE_Debug().

Reviewed-on: https://gerrit.openafs.org/13915
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6ec46ba7773089e1549d27a0d345afeca65c9472)

Change-Id: I634ddb27e7a8dbe5c9d1dacdc83070efa470b50b
Reviewed-on: https://gerrit.openafs.org/13918
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

OPENAFS-SA-2019-002: Zero all server RPC args

Currently, our server-side RPC argument-handling code generated from
rxgen initializes complex arguments like so (for example, in
_RXAFS_BulkStatus):

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    FidsArray.AFSCBFids_val = 0;
    FidsArray.AFSCBFids_len = 0;
    CBArray.AFSCBs_val = 0;
    CBArray.AFSCBs_len = 0;
    StatArray.AFSBulkStats_val = 0;
    StatArray.AFSBulkStats_len = 0;

This is done for any input or output arguments, but only for types we
need to free afterwards (arrays, usually). We do not do this for
simple types, like single flat structs. In the above example, we do
this for the arrays FidsArray, StatArray, and CBArray, but 'Sync' is
not initialized to anything.

If some server RPC handlers never set a value for an output argument,
this means we'll send uninitialized stack memory to our peer.
Currently this can happen in, for example,
MRXSTATS_RetrieveProcessRPCStats if 'rxi_monitor_processStats' is
unset (specifically, the 'clock_sec' and 'clock_usec' arguments are
never set when rx_enableProcessRPCStats() has not been called).

To make sure we cannot send uninitialized data to our peer, change
rxgen to instead 'memset(&arg, 0, sizeof(arg));' for every single
parameter. Using memset in this way just makes this a little simpler
inside rxgen, since all we need to do this is the name of the
argument.

With this commit, the rxgen-generated code for the above example now
looks like this:

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    memset(&FidsArray, 0, sizeof(FidsArray));
    memset(&CBArray, 0, sizeof(CBArray));
    memset(&StatArray, 0, sizeof(StatsArray));
    memset(&Sync, 0, sizeof(Sync));

Reviewed-on: https://gerrit.openafs.org/13914
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 93aee3cf40622993b95bd1af77080a31670c24bb)

Change-Id: I6e19aaea57e545455b65851d1bedade584e482f0
Reviewed-on: https://gerrit.openafs.org/13917
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

OPENAFS-SA-2019-001: Skip server OUT args on error

Currently, part of our server-side RPC argument-handling code that's
generated from rxgen looks like this (for example):

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

When the server routine for implementing the RPC results a non-zero
value into z_result, the call will be aborted. However, before we
abort the call, we still call the xdr_* routines with XDR_ENCODE for
all of our output arguments. If the call has not already been aborted
for other reasons, we'll serialize the output argument data into the
Rx call. If we push more data than can fit in a single Rx packet for
the call, then we'll also send that data to the client. Many server
routines for implementing RPCs do not initialize the memory inside
their output arguments during certain errors, and so the memory may be
leaked to the peer.

To avoid this, just jump to the 'fail' label when a nonzero 'z_result'
is returned. This means we skip sending the output argument data to
the peer, but we still free any argument data that needs freeing, and
record the stats for the call (if needed). This makes the above
example now look like this:

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    if (z_result)
        goto fail;
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

Reviewed-on: https://gerrit.openafs.org/13913
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ea276e83e37e5bd27285a3d639f2158639172786)

Change-Id: I688cbf1a65903bf26a0db033687898f3fb5a54ea
Reviewed-on: https://gerrit.openafs.org/13916
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

Make OpenAFS 1.8.4

Update version strings for the 1.8.4 release.

Change-Id: I85102e0be54cf0ff28b706d35dba8e3601447cba
Reviewed-on: https://gerrit.openafs.org/13841
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

Update NEWS for OpenAFS 1.8.4

Finalize the 1.8.4 release notes.

Change-Id: Ida85451cdec65b2fe736d66572671293f30a6508
Reviewed-on: https://gerrit.openafs.org/13785
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

Make OpenAFS 1.8.4pre2

Update version strings for the second 1.8.4 prerelease.

Change-Id: I83ebb06aaae9484e0773b68f336e6d8752069824
Reviewed-on: https://gerrit.openafs.org/13839
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

Update NEWS for 1.8.4pre2

Release notes for the OpenAFS 1.8.4 prerelease 2.

Change-Id: Iad2098f56c9e5a9025761e21f609aa3c1584b4aa
Reviewed-on: https://gerrit.openafs.org/13840
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

Remove one more automake VERSION reference

The configure summary was still referencing the old automake-specific
VERSION var. Use the autoconf PACKAGE_VERSION var instead, so this
actually shows our version.

Reviewed-on: https://gerrit.openafs.org/13360
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0f65b40b24599d58cf30bfd47fae83ab54e1416a)

Change-Id: I5bd9399acc6e4c6dd19b94198354b600f35bee15
Reviewed-on: https://gerrit.openafs.org/13790
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Remove automake autoconf vars

Commit 4706854f (autoconf: updates and cleanup) removed our invocation
of AM_INIT_AUTOMAKE, which defines the output variables PACKAGE and
VERSION. Several files in our build system are still referencing
@PACKAGE@ and @VERSION@, though, leaving them un-substituted. This
most easily is seen as the AFSVersion version string remaining as
"@VERSION@" when the tree is built without git, but it also affects
some packaging in the tree.

Remove references to @VERSION@ and @PACKAGE@, replacing them with
their autoconf equivalents @PACKAGE_VERSION@ and @PACKAGE_TARNAME@.

Reviewed-on: https://gerrit.openafs.org/13357
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2f2c2ce62aa17ecac3651d64c1168af926f7458b)

Change-Id: If2b98b8930bc687170f53f852417fb9374bf6c60
Reviewed-on: https://gerrit.openafs.org/13789
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

LINUX 5.3.0: Use send_sig instead of force_sig

Linux 5.3.0 commit 3cf5d076fb4d48979f382bc9452765bf8b79e740 "signal
Remove task parameter from force_sig" (part of siginfo-linus branch)
changes the parameters for the Linux kernel function force_sig. See LKML
thread starting at https://lkml.org/lkml/2019/5/22/1351

According to the LKML discussion and the above commit message force_sig
is only safe to deliver a synchronous signal to the current task. To
send a signal to another task, we're supposed to use send_sig instead,
which has been available since at least linux 2.6.12-rc12.

Currently, rx_knet calls force_sig to kill the rxk_ListenerTask.  With
the Linux 5.3.0 kernel, this module fails to compile due to the above
noted changes.

Replace the force_sig call with send_sig.  In order to use send_sig, the
rxk_listener thread must allow SIGKILL and during shutdown (umount)
SIGKILL must be unblocked for the rxk_listener thread.

Note that SIGKILL is initially blocked on rxk_listener and is only
unblocked when shutting down the thread.  Having the signal blocked is
sufficient to prevent unwanted signals from reaching the rxk_listener
thread during normal operation.

Reviewed-on: https://gerrit.openafs.org/13753
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2b7af1243f46496c0b5973b3fa2a6396243f7613)

Change-Id: I6eb44311fbcc63adb6ebeb85a8e076922befd645
Reviewed-on: https://gerrit.openafs.org/13788
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

LINUX 5.3.0: Check for 'recurse' arg in keyring_search

Linux 5.3.0 commit dcf49dbc8077e278ddd1bc7298abc781496e8a08 "keys: Add a
'recurse' flag for keyring searches" adds a new parameter to
Linux kernel keyring_search function.

Update the call to keyring_search to include the recurse parameter if
available. Setting the parameter to true (1) maintains the current
search behavior.

Change-Id: I038117d1bccdf619a42132fba7d8d61b3ce3c14b
Reviewed-on: https://gerrit.openafs.org/13752
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-on: https://gerrit.openafs.org/13787
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Make OpenAFS 1.8.4pre1

Update version strings for the first 1.8.4 prerelease.

Change-Id: I9aa05d7bce308780a1dc815341856e2291579039
Reviewed-on: https://gerrit.openafs.org/13596
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Update NEWS for 1.8.4pre1

Release notes for the OpenAFS 1.8.4 prerelease 1.

Change-Id: I3976919660ff6a0eda82b71806e116f4322fb38a
Reviewed-on: https://gerrit.openafs.org/13643
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

libadmin: overlap warning in strcpy with gcc9

GCC 9 with --enable-checking produces a new warning/error in
afs_utilAdmin.c associated with a strcpy with the potential of an
overlap.  The index used is signed which triggers the new warning. The
source and target of the strcpy are contained within the same higher
level structure.

Change the variable 'index' from signed to unsigned to resolve the
warning/error. Change the variable 'total' in the same structure to
unsigned to be consistent with it's usage with 'index'.

Reviewed-on: https://gerrit.openafs.org/13660
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 79dffe29c8a0ec55c4231a18077efdfa7c1edf53)

Change-Id: I19a192ecea86314851e6889274eb030c5caff8cb
Reviewed-on: https://gerrit.openafs.org/13724
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

aklog: Avoid misleading AFSCELL message

Currently, if the AFSCELL environment variable is set, aklog (and
other libauth-using utilities) print out a message when
afsconf_GetLocalCell is called:

    Note: Operation is performed on cell env.example.com

However, this message is also printed (with the AFSCELL cell) when
aklog is given the -cell command-line argument, even though aklog
actually uses the cell given on the command line. For example:

    $ AFSCELL=env.example.com aklog -cell cli.example.com -d
    Note: Operation is performed on cell env.example.com
    Authenticating to cell cli.example.com (server srv1.example.com).
    [...]

libauth will normally not print the "Operation" message if we're not
using the default cell, but it determines this by checking if someone
called afsconf_GetCellInfo before calling afsconf_GetLocalCell. And
currently, aklog calls afsconf_GetLocalCell before
afsconf_GetCellInfo, so the message gets printed because libauth has
no way of knowing that we're actually using a different cell.

klog gets around this by making an additional ignored call to
afsconf_GetCellInfo before afsconf_GetLocalCell, but we can fix this
in aklog by just changing the order of the calls. So, just call
afsconf_GetCellInfo first; if we're using the local cell, we can just
give a NULL cell parameter, instead of looking up the local cellname
first.

Reviewed-on: https://gerrit.openafs.org/13371
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 877d9d79a32b9e81911cb567f844b11c693229f0)

Change-Id: I67350be8c25fb93975442175a64098123503b40c
Reviewed-on: https://gerrit.openafs.org/13676
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Avoid non-dir ENOENT errors in afs_lookup

Historically, there have been many subsystems in libafs that can
generate ENOENT errors for a variety of reasons. In addition to the
expected case where we lookup a name that doesn't exist, other
scenarios have caused ENOENT error codes to be generated, such as:
internal inconsistencies, I/O errors, or even abort codes from the
network.

When one of these scenarios cause an ENOENT error code in one of those
situations during afs_lookup() when the target name does actually
exist, it can be confusing to a user, or even result in incorrect
application behavior. On Linux in particular, ENOENT results from a
lookup are cached in negative dcache entries, and so can cause future
lookups for the same name to yield ENOENT errors.

Various commits have tried to avoid this abuse of the ENOENT error
code, such as 2aa4cb04 (afs: Stop abusing ENOENT). But we cannot
prevent receiving ENOENT abort codes from the network, and mistakes in
the future may cause more scenarios incorrectly yielding ENOENTs.

However, in afs_lookup, we do know that legitimate ENOENT errors can
only occur in one situation: when we have a valid directory blob, and the
afs_dir_Lookup() operation itself returns an ENOENT error for the
target name. For all other areas of afs_lookup(), we know that an
ENOENT error is not legitimate, since we may not be sure if the target
name exists or not.

So to proactively avoid incorrect ENOENT results, prevent afs_lookup
from returning ENOENT, except in the specific code path where
afs_dir_Lookup is called.

Reviewed-on: https://gerrit.openafs.org/13537
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 5f48367f2bd5bf1c0e689c79508177b649b9113b)

Change-Id: I2698c26d7b75146d92e1763d49dce135ad66f672
Reviewed-on: https://gerrit.openafs.org/13692
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

auth: make PGetTokens2 work with 3-char cellnames

PGetTokens2 accepts two different types of input:
- an integer 'iterator' to request the nth token set for a user
- a string cellname to request the user's token set for that cell

Unfortunately, it distinguishes between these by assuming if the input
length is sizeof(afs_int32) (4 bytes), it must be an integer.  This
assumption is incorrect if the cellname is three (3) characters long
plus a nul terminator.

The result is that the cellname string is interpreted as a very large
"n"; the subsequent search for the user's "very-large-nth-token" fails,
making it appear that the user has no valid token for this cell.

Improve on this heuristic by double-checking any putative integer input.
If it is actually a 3-character string, then process the input as a
cellname instead.

Introduced by commit 5ec5ad5dcca84e99e5f55987cc4f787cd482fdde 'New
GetToken pioctl'.

While here, add doxygen comments.

Reviewed-on: https://gerrit.openafs.org/13599
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit b0278994826f6bd1dfebc39f26282b8fbdadf1a0)

Change-Id: Ib64749d65f03fc564b1d987b426832442be8d5bd
Reviewed-on: https://gerrit.openafs.org/13679
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: Check for -restricted in SPR_Delete

Currently, all prdb write operations, except for SPR_Delete, will fail
with PRPERM if called by a non-system:administrators caller while
restricted mode is active.  SPR_Delete is missing this check, and so
is not affected by the -restricted option.

Fix this by inserting the same check for -restricted as all other code
paths that check for -restricted.

Reviewed-on: https://gerrit.openafs.org/13374
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2e556c0f23ae439c804352cf51fcf30878b03c7a)

Change-Id: I9a31cf4e6490aa13dc0c239d2660fc146553ee75
Reviewed-on: https://gerrit.openafs.org/13688
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: Fix AccessOK -restricted for SYSADMINID

According to the documentation, as well as other code paths that check
for -restricted, the -restricted option does not affect members of
system:administrators. Currently, though, AccessOK only bypasses the
-restricted check if the caller is SYSADMINID itself (i.e. localauth).

Fix AccessOK to only do the -restricted checks if the caller is not in
system:administrators, to match the documentation as well as other
ptserver operations.

Reviewed-on: https://gerrit.openafs.org/13373
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3a8fa4ecd65d5d743fdc573c9f0f261aee2063b6)

Change-Id: I786830efab229a50a521daf3efc624e949475030
Reviewed-on: https://gerrit.openafs.org/13687
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

ptserver: Fix AccessOK -restricted for addToGroup

The function AccessOK is used by all of ptserver RPC handlers that
need to do an authorization check, and the last two arguments are set
as such:

- When adding a member to a group, 'mem' is PRP_ADD_MEM and 'any' is
  PRP_ADD_ANY

- When removing a member from a group, 'mem' is PRP_REMOVE_MEM and
  'any' is 0

- When modifying an entry (setFieldsEntry) or modifying some global
  database fields, 'mem' and 'any' are both set to 0

- When reading an entry and not modifying it, 'mem' and/or 'any' are
  set to other values (depending on if we're checking membership,
  examining the entry itself, etc)

Commit 93ece98c (ptserver-restricted-mode-20050415) added a check to
AccessOK to make it return false for -restricted mode when we are
adding a member to a group, or when 'mem' and 'any' are both 0. This
didn't catch the case when we are removing a member from a group,
though, when 'mem' is PRP_REMOVE_MEM.

It looks like commit a614a8d9 (ptutils-restricted-accessok-20081025)
tried to fix this by adding a check for PRP_REMOVE_MEM, but it also
required 'any' to be set to 0 for the conditional to succeed. This is
true when removing a member from a group, but when adding a member to
a group, 'any' is PRP_ADD_ANY, and so this check fails.

This means that currently, when restricted mode is turned on,
non-admins can still run addToGroup and setFieldsEntry successfully.

Fix this by checking for PRP_ADD_MEM/PRP_REMOVE_MEM separately from
checking if 'mem'/'any' are set to 0. Break up this conditional into
separate if() statements with comments to try to make the checks
more clear.

Reviewed-on: https://gerrit.openafs.org/13370
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dfc78d533ef64c8d6daf134e2a0f67c5c16f7369)

Change-Id: I7f53570b42e2700a33dd5e72a31f6f7f8b876e79
Reviewed-on: https://gerrit.openafs.org/13686
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

auth: eliminate pointless retries in ktc_ListTokensEx

ktc_ListTokensEx is an iterator to provide the names of each cell for
which a user has a token set.  It does this by looking for the 1 through
nth token set for a given user.  However, as currently implemented,
it always continues searching up to the 100x safety limit even when
there are no more token sets for the user.

Instead, return immediately when VIOC_GETTOK2 returns EDOM (no more
tokens for this user).

Introduced by commit a86ad262d2a8be36f43ab0885a84dde37ddfc464 'auth: Add
the ktc_ListTokensEx function'.

Reviewed-on: https://gerrit.openafs.org/13598
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 95ae30c30d98a3219fd021e0ed83200c1b6c266f)

Change-Id: Ib0489b78b92861ae25b625b3054caf68f3b0a074
Reviewed-on: https://gerrit.openafs.org/13678
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

viced: correct option parsing for -vlru*, -novbc

Commit a5effd9f1011aa319fdf432c67aec604053b8656 "viced: Use libcmd for
command line options" modernized the option parsing for (da)fileserver,
but introduced a few errors for the following options:

-vlruthresh <nn>
-vlruinterval <nn>
-vlrumax <nn>
-novbc

Correct the errors.

Reviewed-on: https://gerrit.openafs.org/13365
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d058acb354cab9856303cc341a1f439e4f7f3454)

Change-Id: I5eceb3cc77cfca5c9ec68efdbaabd069c3690c5a
Reviewed-on: https://gerrit.openafs.org/13680
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

util: serverLog using memory after free

clang's scan-build detected a "use of memory after it is freed"
condition.

The function OpenLogFile frees the variable ourName before creating a
duplicate of the name passed to it.  However there is a call that uses
ourName as the parameter: OpenLogFile(ourName).  This results in freeing
ourName then doing a strdup of the same memory location.

Test the passed parameter and if it's the same as ourName already skip
the free and strdup.

This bug was introduced in commit
    340ec2f79208ee21c3130c4b1c13995947ce426c
    "util: allocate log filename buffers"

Reviewed-on: https://gerrit.openafs.org/13659
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f5f59cd8d336b153e2b762bb7afd16e6ab1b1ee2)

Change-Id: Ia1ae1144493fa682595b365324322d8d273c0cbb
Reviewed-on: https://gerrit.openafs.org/13675
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

add dkms dependency in Red Hat unit file

Currently, there is no explicit relationship between OpenAFS and dkms.
If dkms needs to rebuild the kernel module, OpenAFS will fail to mount
because modprobe will not load the module.  This change specifies that
OpenAFS should run after dkms if dkms is present.

Reviewed-on: https://gerrit.openafs.org/13654
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fbe2a03aa69bc19768302685d902a25e4d6e157a)

Change-Id: If08df50128a29642e9cdfc311811b99a7889a158
Reviewed-on: https://gerrit.openafs.org/13674
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: khm <khm@sciops.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

pioctl: limit fruitless token searches

getNthCell searches the afs_users table for the nth token set belonging to a
given user.  However, it is impossible for a user to have more than one
token set per cell.  If the caller specifies a number greater than the
total number of cells this cache manager knows about, we know the search
will be fruitless.

Instead, return early in this case, avoiding both the lock and the
search.

Reviewed-on: https://gerrit.openafs.org/13597
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fc7e1700fe84f623fb9163466d24226df00b1a2c)

Change-Id: Idfda263af173a7ca081fcea3eef0ec4a63e66eda
Reviewed-on: https://gerrit.openafs.org/13639
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Fix static expressions in conditionals

The conditions in these if statements are always true (or always false).
Remove the check in cmdebug.c, as it is unnecessary, and fix the check
in vlclient.c to actually check for a valid voltype. (via cppcheck)

Reviewed-on: https://gerrit.openafs.org/13158
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5cd5cd9fa8754a5af346fa6a392363b046316c75)

Change-Id: Ie3a2d6bfc99d1b5adf0524afc29dac30b655d04d
Reviewed-on: https://gerrit.openafs.org/13638
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: add a file-level comment to afs_osidnlc.c

This file doesn't currently do a great job of telling the reader what
it's used for.  Let's give them a hint, especially for the expansion
of "DNLC".

Reviewed-on: https://gerrit.openafs.org/13557
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3a5ab19fe04058e002bfea90f8b64fab4676de67)

Change-Id: I41c53e5a37cc2da8fa0578a9c5db476530103981
Reviewed-on: https://gerrit.openafs.org/13650
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: remove bogus comment from afs_IsTokenExpired

Remove an incorrect comment, introduced with commit
adf2e6e827c6caf55247c5e63b88775393156ae5 'Unix CM: Generalise token
storage'.

No functional change is incurred by this commit.

Reviewed-on: https://gerrit.openafs.org/13640
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 54c34d32e884a5bfb2352e7c8767d743ef3e4647)

Change-Id: I00f91947f9cd64694b2021e484b33dc9074fee94
Reviewed-on: https://gerrit.openafs.org/13651
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Use the ppc64le_linuxXX sysname for ppc64le builds

Commit 191e18eb (Open ppc64le_linux sysname space) added the
ppc64le_linux26 sysname, but it still must be manually specified when
running on ppc64le. Use the ppc64le_linux26 by default on ppc64le, so
we can compile without needing to specify an explicit sysname.

Reviewed-on: https://gerrit.openafs.org/13593
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4b6a4ff31a4197504bbcf2d4c14c24dee672d40e)

Change-Id: Icf8f8b42c499dc42bf5d637dae5ad3e261e68512
Reviewed-on: https://gerrit.openafs.org/13637
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

LINUX: Propagate afs_linux_readdir BlobScan errors

In afs_linux_readdir, if we detect an error code from BlobScan,
currently we 'break' out of the current while() loop. But right after
this loop, we reset 'code' to 0, ignoring the error we just got from
BlobScan, and acting like we just reached the end of the directory.

This means that if BlobScan could not process the given directory at
all, we'll just fail to iterate through some of the entries in the
given directory, and not report an error.

To fix this, process errors from BlobScan like we do for
afs_dir_GetVerifiedBlob, and return an error code and log a message
about the corrupted dir.

Reviewed-on: https://gerrit.openafs.org/13430
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 63f015d05293cd853dbd44e5115e6b378644dfb6)

Change-Id: Ia25bcfdb70cdb1dd1a7ce0efb84ef76beb78b247
Reviewed-on: https://gerrit.openafs.org/13591
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Throw EIO in DRead on empty dir blob

DRead currently returns ENOENT if we try to read a page beyond the end
of the given dir blob. We do this to indicate we've hit EOF, but we do
this even if the dir blob is completely empty (which is not a valid
dir blob).

If a dir blob in the cache is truncated due to cache corruption
issues, that means we'll indicate a normal EOF condition in that
directory for most code paths. If someone is trying to list the
directory's entries, for instance, we'll just return that there are no
entries in the dir, even though the dir itself is just invalid.

To avoid this for at least some cases, return an EIO error instead if
the dir blob is completely empty.

Reviewed-on: https://gerrit.openafs.org/13429
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 86d04ea70fd2e99606b1d1b5b68d980d92e7a3cd)

Change-Id: I067aae1f949051169225a3cc0bdba35ad76a4ec2
Reviewed-on: https://gerrit.openafs.org/13590
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Do not define AFS_SYSCALL for ppc64le_linux26

AFS_SYSCALL is defined to the syscall number we can use for a certain
platform (for pioctls and other AFS-specific kernel calls). On many
modern platforms, such as Linux, we don't use direct syscalls anymore,
instead routing our AFS-specific syscalls through an ioctl, and
AFS_SYSCALL is just used as a fallback for compatibility for older
OpenAFS releases that might still be using the syscall.

For new platforms, we have no need for this compatibility code path,
since there is no existing code we might need to be compatible with.
We should avoid defining AFS_SYSCALL for those, so we can avoid
manually-issuing syscalls in more cases. The ppc64le_linux26 platform
is a very new platform (introduced in 191e18eb "Open ppc64le_linux
sysname space"), and so should not have AFS_SYSCALL defined.

So, remove AFS_SYSCALL from ppc64le_linux26's param.h.

Reviewed-on: https://gerrit.openafs.org/13592
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 46563f929a851032d785634763963808d6e2bfeb)

Change-Id: Ib161b50a9156d3790134de4e1a8e66a1356e0fb6
Reviewed-on: https://gerrit.openafs.org/13636
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Open ppc64le_linux sysname space

While here, add config/param.ppc64le_linux26.h; it's just like
ppc64_linux26.h, except not AFSBIG_ENDIAN.

Reviewed-on: https://gerrit.openafs.org/13562
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 191e18ebcee3698a76b55912de0a41111c384128)

Change-Id: I9852da2a376a24269ff720a4da4881dae83036cd
Reviewed-on: https://gerrit.openafs.org/13589
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

redhat: RHEL8 add elfutils-devel as build dependency for kernel module

Building the kernel modules under RHEL8 produces the following error
message:
    Makefile:952: *** "Cannot generate ORC metadata for
     CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or
     elfutils-libelf-devel".  Stop.

Add elfutils-devel to the BuildRequires in the rpm spec when building
rhel >= 8

Add elfutils-devel to the BuildRequires in the rpm spec that
openafs-kmodtool produces

FIXES 134900

Reviewed-on: https://gerrit.openafs.org/13560
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 13817774518ada28f5fe68e0d00ef5dd00b67b55)

Change-Id: If4f453e6c459a2865626d4fd71bb47030e3deb58
Reviewed-on: https://gerrit.openafs.org/13563
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Raise osidnlc NCSIZE

The currrent size of the osi DNLC is very small; only 300 entries.
Raise it to 4096 entries, to give it some chance of actually helping.

In the future, of course, this should be runtime configurable, and we
should also raise the hash table size. For now, just raise the number
of entries without changing anything else, to try to make sure nothing
breaks.

With the hash size of 256, this means our hash chains will be at least
16 items long. However, traversing even hundreds of hash items should
still be better than frequently hitting the disk cache to find
entries, and acquiring more locks, etc.

Reviewed-on: https://gerrit.openafs.org/13531
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 12b46b6af778625a9c360dca61a59fcf30b76fd1)

Change-Id: Ib4fd8bd01e2df22617e5a549d4ac76ba1d50b2fd
Reviewed-on: https://gerrit.openafs.org/13559
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

dir: Honor non-ENOENT lookup errors

Currently, several places in src/dir/dir.c assume that any error from
a lower-level function (e.g. FindItem) means that the item we're
looking for does not exist in that directory. But if we encountered
some other error, that may not be the case; the directory blob may be
corrupt, we may have encountered some I/O error, etc.

To detect cases like this, return the actual error code from FindItem
&c, instead of always reporting ENOENT. For the code paths that are
actually specifically looking for if the target exists (in
afs_dir_Create), change our checks to specifically check for ENOENT,
and return any other error.

Do the same thing for a few similar callers in viced/afsfileprocs.c,
as well.

FIXES 134904

Reviewed-on: https://gerrit.openafs.org/13431
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0b3bd1b7cdc88ba62c8cd540e8628faa84e33cf9)

Change-Id: Ia81ff85821c1987b97390a683f1d442ca70db41e
Reviewed-on: https://gerrit.openafs.org/13543
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

LINUX: Avoid lookup ENOENT on fatal signals

Various Linux kernel operations on various Linux kernel versions can
fail if the current process has a pending fatal signal (i.e. SIGKILL),
including reads and writes to our local disk cache. Depending on what
and when something fails because of this, some parts of libafs throw
an ENOENT error, which may propagate up to callers, and be returned
from afs_lookup(). Notably this can happen via some functions in
src/dir/dir.c, and previously was possible with some code paths before
they were fixed by commit 2aa4cb04 (afs: Stop abusing ENOENT).

For the most part, the exact error given to the userspace caller
doesn't matter, since the process will die as soon as we return to
userspace. However, for ENOENT errors specifically for lookups, we
interpret this to mean that the target filename is known to not exist,
and so we create a negative dentry for that name, which is cached.
Future lookups for that filename will then result in ENOENT before any
AFS functions are called.

The lingering abuses of the ENOENT error code should be removed from
libafs entirely, but as an extra layer of safety, we can just avoid
returning ENOENT from lookups if the current process has a pending
fatal signal. So to do that, change all afs_lookup() callers in
src/afs/LINUX to translate ENOENT to EINTR if we have a pending fatal
signal. If fatal_signal_pending() is not available, then we don't do
this translation.

FIXES 134904

Reviewed-on: https://gerrit.openafs.org/13530
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8b6ae2893b517bd4e008cae94acff70abe4d2227)

Change-Id: I8bf1b24c97ed74b0b457d79f48b2f40416c1d37e
Reviewed-on: https://gerrit.openafs.org/13542
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Cleanup state on rxfs_*Init errors

Currently, rxfs_storeInit and rxfs_fetchInit return early if they
encounter an error while starting the relevant fetch/store RPC (e.g.
StartRXAFS_FetchData64). In this scenario, they osi_FreeSmallSpace
their rock before returning, but they never go through their
destructor to free the contents of the rock
(rxfs_storeDestroy/rxfs_fetchDestroy), leaking any resources inside
that have already been initialized.

The only thing that could have been initialized by this point is
v->call, so hitting this condition means we leak an Rx call, and means
we can report the wrong error code (since we never go through
rx_EndCall, we never look at the call's abort code). For
rxfs_fetchInit, most code paths call rx_EndCall explicitly, except for
the code path where StartRXAFS_FetchData64 itself fails.

For both fetches and stores, it's difficult to hit this condition,
because this requires that the StartRXAFS_* call fails, before we have
sent or received any data from the wire. However, this can be hit if
the call is already aborted before we use it, which can happen if the
underlying connection has already been aborted by a connection abort.

Before commit 0835d7c2 ("afs: make sure to call afs_Analyze after
afs_Conn"), this was most easily hit by trying to fetch data with a
bad security object (for example, with expired credentials). After the
first fetch failed due to a connection abort (e.g. RXKADEXPIRED),
afs_GetDCache would retry the fetch with the same connection, and
StartRXAFS_FetchData64 would fail because the connection and call were
already aborted. In this case, we'd leak the Rx call, and we would
throw an RXGEN_CC_MARSHAL error (-450), instead of the correct
RXKADEXPIRED error. This causes libafs to report that the target
server as unreachable, due to the negative error code.

With commit 0835d7c2, this doesn't happen because we call afs_Analyze
before retrying the fetch, which detects the invalid credentials and
forces creating a new connetion object. However, this situation should
still be possible if a different call on the same connection triggered
a connection-level abort before we called StartRXAFS_FetchData64.

To fix this and ensure that we don't leak Rx calls, explicitly call
rxfs_storeDestroy/rxfs_fetchDestroy in this error case, before
returning from rxfs_storeInit/rxfs_fetchInit.

Thanks to yadayada@in.ibm.com for reporting a related issue and
providing analysis.

Reviewed-on: https://gerrit.openafs.org/13510
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 11cc0a3c4e0d76f1650596bd1568f01367ab5be2)

Change-Id: I3c2d66a5a6128bb8b403dfa6ea7c37e32bd2f156
Reviewed-on: https://gerrit.openafs.org/13517
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

SOLARIS: Switch non-embedded vnodes for Solaris 11

Newer updates to Solaris 11 have been including several changes to the
vnode struct. Since we embed a vnode in our struct vcache, our kernel
module must be recompiled for any such change in order for the openafs
client to work at all.

To avoid the need for this, switch Solaris to using a non-embedded
vnode in our struct vcache. Follow a similar technique as is used in
DARWIN and XBSD, where we allocate a vnode in osi_AttachVnode, and
free it in afs_FlushVCache.

Reviewed-on: https://gerrit.openafs.org/12696
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2aafe7df403e6a848185d15495139c07bced2758)

Change-Id: I2f5b3e2b2b908ea9815fd7735a1abed511cec9cb
Reviewed-on: https://gerrit.openafs.org/13528
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

SOLARIS: Fix vnode/vcache casts

A few places were using vnodes and vcaches interchangeably. This is
incorrect, since they may not always be the same thing if we stop
embedding vnodes directly in vcaches Fix these to properly go through
AFSTOV/VTOAFS to convert between vcaches and vnodes.

Reviewed-on: https://gerrit.openafs.org/12695
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit a6499e0b086d964f3fcc65fe4be31edc33015061)

Change-Id: Ia6889966a7c595786f0a273b4c2a5a63fe60ddd3
Reviewed-on: https://gerrit.openafs.org/13527
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

SOLARIS: Accept vnodes in vnode ops

Currently, our vnode op callbacks look like this:

    int gafs_fsync(struct vcache *avc, afs_ucred_t *acred);

And a pointer to gafs_fsync is given directly to Solaris. This cannot
be correct, since 'struct vcache' is an OpenAFS type, so Solaris
cannot possibly give us a 'struct vcache'. The actual correct
signature for such a function is something like this:

    int gafs_fsync(struct vnode *vp, afs_ucred_t *acred);

And then the 'gafs_fsync' function is supposed to translate 'vp' into
a vcache.

This works on Solaris right now because we embed the vnode as the
first member in our vcache, and so a pointer to a vnode is also a
pointer to a vcache. However, this would break if we ever change
Solaris vcaches to use a non-embedded vnode (like on some other
platforms). And even now, this causes a lot of warnings in
osi_vnodeops.c, since the function signatures are wrong for our vnode
callbacks.

So to fix this, change all of these functions to accept a 'struct
vnode', and translate to/from vnodes and vcaches appropriately.

Reviewed-on: https://gerrit.openafs.org/12694
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit 9a2b11747ce355d9adc8a5a646c88f8f3d9765ee)

Change-Id: I85cee787e26886596a10c6b9a02f33f2bf28d65d
Reviewed-on: https://gerrit.openafs.org/13526
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

SOLARIS: Reorder definitions for vnode callbacks

Currently, many of the functions for our vnode ops are
forward-declared, right before they are referenced in the relevant
vnop template array. Move the function definitions to before the
references, so we can simply get rid of the forward declarations.

These functions are also all only referenced in this file, so declare
them 'static'.

Reviewed-on: https://gerrit.openafs.org/12693
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit 41a22dbf719629e0977fa963b3d19c6594d0d729)

Change-Id: I5840fef98d2ce15525c4981636fad6e5990cbad2
Reviewed-on: https://gerrit.openafs.org/13525
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

SOLARIS: Clean up some osi_vnodeops func defs

Currently, the Solaris osi_vnodeops.c file forward-declares many of
its function definitions, but doesn't declare the arguments. For
example:

    int afs_nfsrdwr();

This avoids type-checking for a few functions that are called before
they are defined in this file. Furthermore, many of these functions
are only used within this file, but are not declared 'static'.

To fix this weirdness, remove most of the forward declarations (most
are not referenced until the function is defined), and fully declare
the rest. Declare functions 'static' that are not referenced outside
of this file.

This commit only changes functions up to the 'afs_getsecattr'
definition. The rest of the file will be fixed in a future commit.

Reviewed-on: https://gerrit.openafs.org/12692
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit aa46af6ae35e4f026a8ed94012c3bc18c954de23)

Change-Id: I33f445ed253f1991896afff33e7cc14bf5e50b18
Reviewed-on: https://gerrit.openafs.org/13524
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

LINUX: correct include for ktime_get_coarse_real_ts64()

The include for the ktime_get_coarse_real_ts64() autoconf test is
incorrect; ktime_get_coarse_real_ts64() has always been in linux/ktime.h
(via #include timekeeping.h), not linux/time.h.

This autoconf test still ran correctly because the OpenAFS build was
inadvertently picking up ktime.h via the default autoconf include path.
Therefore, this commit is needed only to provide documentation and
clarity to future maintainers.

Introduced as a cut-n-paste error (from the current_kernel_time test)
with commit 3c454b39d04f4886536267c211171dae30dc0344 for Linux 4.20.

Reviewed-on: https://gerrit.openafs.org/13437
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 10b02075a262dbe802266ea4bcac3936dff5dd23)

Change-Id: Ide1adcc8536ed8829361e0961da96949099d5caf
Reviewed-on: https://gerrit.openafs.org/13523
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: Remove afs_xosi

Since OpenAFS 1.0, all platforms in libafs have a lock called
afs_xosi, which is acquired and released around calls like VOP_GETATTR
on cache files. However, this lock doesn't appear to protect anything;
on all platforms, the code that runs while the lock is held uses only
calls VOP_GETATTR and accesses local variables (aside from
afs_osi_cred, which we use similarly in many other places). The
purpose of the lock has never been documented, and is not mentioned at
all in the afs_rwlocks text file.

The comment by the afs_xosi lock declaration suggests that the lock
was originally introduced to protect access to 'tvattr', which perhaps
was a global variable in the past. All uses of 'tvattr' are local now,
though, so protecting access to it doesn't make any sense.

So, remove afs_xosi, to remove the unnecessary serialization of
VOP_GETATTR calls.

Reviewed-on: https://gerrit.openafs.org/13350
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d75bc6370f625479a67c7c0a50cce23c4d4a4ce5)

Change-Id: I33dc7935872cf071c4221d46cbb458e1f77185a2
Reviewed-on: https://gerrit.openafs.org/13529
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: make sure to call afs_Analyze after afs_Conn

The afs_Conn function is used to pick a connection for a given RPC. The
RPC is normally wrapped within a do-while loop which calls afs_Analyze
to handle the RPC code and manage the server connection references.
Among other things, afs_Analyze can mark the server as down, blacklist
idle servers, etc.

There are some special cases in which we break out of this do-while loop
early, by putting the connection reference given by afs_Conn and then
jumping out of the loop.

In these cases, be sure to call afs_Analyze to put the server connection
we got from afs_Conn, and to handle the RPC return code, possibly
marking the server as down or blacklisted.

Reviewed-on: https://gerrit.openafs.org/13288
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0835d7c2a183f896096684df06258aefd297f080)

Change-Id: Ic5648dbd250c33988d64284b906b3829a396a2cb
Reviewed-on: https://gerrit.openafs.org/13511
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Run ctfconvert/ctfmerge for all objects

Commit 88cb536f (autoconf: detect ctf-tools and add ctf to libafs)
introduced running ctfconvert and ctfmerge for libafs on Solaris, but
didn't add any CTF data for userspace code. This commit causes the
same commands to be run for every binary that we build (if the ctf
tools are available).

To accomplish this, also refactor how we run ctfconvert and ctfmerge.
The approach in commit 88cb536f would require us to modify the
makefile rule for every executable to run RUN_CTFCONVERT and
RUN_CTFMERGE, which is somewhat impractical. So instead in this
commit, we modify all of our *_CCRULE and *_LDRULE variables to wrap
the compiler invocation with the new CC_WRAPPER script. This means our
*RULE variables change from something like this:

    FOO_CCRULE = $(RUN_CC) $(CC) $(XXX_FLAGS) -o $@

to something like this:

    FOO_CCRULE = $(RUN_CC) $(CC_WRAPPER) $(CC) $(XXX_FLAGS) -o $@

CC_WRAPPER expands to the script src/config/cc-wrapper, which just
runs ctfconvert or ctfmerge on the relevant files after the
compiler/linker runs. If the CTF tools are not configured, CC_WRAPPER
expands to nothing, to limit our impact on other platforms.

This commit was developed in collaboration with
mbarbosa@sinenomine.net.

Reviewed-on: https://gerrit.openafs.org/13308
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c1d39153da00d5525b2f7874b2d214a7f1b1bb86)

Change-Id: Ic357293a946f0759aa032f7c93b4b56e74e9209a
Reviewed-on: https://gerrit.openafs.org/13487
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: do not reference the missing script

Currently, OpenAFS does not use automake. As a result, the missing script
is not copied to the build-tools directory. Since this script is not
present in the tree, am_missing_run is not initialized. Unfortunately,
the current version still has a few references to this variable. In order
to preserve a similar behavior, this commit replaces these references by
AC_ERROR.

While we are changing these, remove the AC_CHECK_PROGS calls for AR and
STRIP, since libtool already checks these for us.

Reviewed-on: https://gerrit.openafs.org/12982
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9d3ef9337fafe5dcf3865d3aced290be0f887c11)

Change-Id: Ibb2fa93e73f303cd68e9e030f1631476f1da329c
Reviewed-on: https://gerrit.openafs.org/13486
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Remove obsolete retsigtype

Only relevent for pre-c89 K&R compilers.

[mmeffie@sinenomine.net: avoid changes to src/external]

Reviewed-on: https://gerrit.openafs.org/12203
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a9644daa965fbf316943a07ad985b8ead2f4f31d)

Change-Id: I37f83e7d8a59d5ccffe8542f3c4090e667b48c16
Reviewed-on: https://gerrit.openafs.org/13485
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: reformat long lines

The autoupdate tool was run to modernize the autoconf macros but
generates very long lines. Manually reformat the long lines to make them
more reasonable.

Reviewed-on: https://gerrit.openafs.org/13125
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 451602a5e3a503d46eaecb3738d259e46023afcd)

Change-Id: I19f16a66fdc6b33889f08e5a095b1f3209b01a3c
Reviewed-on: https://gerrit.openafs.org/13484
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: autoupdate macros

Run autoupdate on macros.

[mmeffie@sinenomine.net: re-run autoupdate, no other edits]

Reviewed-on: https://gerrit.openafs.org/12202
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2e23fceec872795a39b915b73e48eb77a5d65afe)

Change-Id: I27eac1f2b6e468382976d7866aa1f5e648727534
Reviewed-on: https://gerrit.openafs.org/13483
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: update curses.m4

Replace the obsolete AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM
in the curses check for the getmaxyx macro.

This change was done manually instead of using autoupdate because the
program prologue argument for this particular check is an m4 macro,
which will not expand to code when autoupdate adds m4 quotes to the
AC_LANG_PROGRAM arguments.

Reviewed-on: https://gerrit.openafs.org/13021
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit f9c584a794c6a4c5d03fa1ee7f1b2b5e1309e7ee)

Change-Id: Ic0a1007f5a71496fd235eab6659a73e46393d317
Reviewed-on: https://gerrit.openafs.org/13482
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

pthread.m4: Add missing 'test' to conditional

Commit c5def62d (autoconf: update pthread checks) accidentally omitted
a 'test' in one of the conditionals. This causes an ugly error message
during configure:

    checking for pthread_attr_init in -lpthread... yes
    ./configure[31043]: x-lpthread: not found [No such file or directory]

Replace the missing 'test'.

Reviewed-on: https://gerrit.openafs.org/13342
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 38a094137f067255c586dd5c85f3040d7a7c4486)

Change-Id: Iaa7014c6ae58bd492930dbe4f39180111bacb67e
Reviewed-on: https://gerrit.openafs.org/13595
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: update pthread checks

Replace obsolete AC_TRY_COMPILE with AC_COMPILE_IFELSE.  Replace shell
if/then conditionals with AS_IF macros.  Reformat indentation and
quoting.

This change was done manually, since autoupdate copes poorly with the
old, nested AC_TRY_COMPILE macros.

Reviewed-on: https://gerrit.openafs.org/13018
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
(cherry picked from commit c5def62d7be4891f534b753374acbf5b524701eb)

Change-Id: I5cc8e5712dd742d20be92d04728eddbecf9c216c
Reviewed-on: https://gerrit.openafs.org/13481
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

autoconf: updates and cleanup

Update autoconf macros to their modern equivalents, according to what
the 'autoupdate' tool does. While we're here, remove automake references
that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor
of AFS_LT_INIT.

Reviewed-on: https://gerrit.openafs.org/12199
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 4706854f57043c8393baa922dd1974176e110a19)

Change-Id: I9b3b8a15ac73484f60d16448abd8cce2e0334201
Reviewed-on: https://gerrit.openafs.org/13480
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

libuafs: Stop clobbering CFLAGS

Currently, in the libuafs MakefileProto for every platform, CFLAGS is
set to a bunch of flags, ignoring any CFLAGS set by the 'make'
command-line provided by the user. Since most of the rest of the tree
honors CFLAGS, it is confusing and can cause errors when src/libuafs
ignore the user-set CFLAGS.

One example of this breaking the build is when building RHEL RPMs for
certain sub-architectures of the current machine. If you try to
'rpmbuild --target=i686' on 32-bit x86 RHEL 5, we will build with
-march=i686 in the CFLAGS, which will be used to build most objects
and is used in our configure tests. As a result, our configure tests
will say that gcc atomic intrinsics are available. But when we go to
build libuafs objects, we will not have -march=i686 in our CFLAGS,
which causes (on RHEL 5) gcc to default to building for i386, which
does not have gcc atomic intrinsics available. This causes build
errors like this:

    libuafs.a(rx.o): In function `rx_atomic_test_and_clear_bit':
    [...]/BUILD/openafs-1.8.0/src/rx/rx_atomic.h:462: undefined reference to `__sync_fetch_and_and_4'

To fix this, change the libuafs MakefileProtos to not set CFLAGS
directly; instead, set them in a new variable UAFS_CFLAGS.
Makefile.common then pulls those flags into MODULE_CFLAGS, which is
used in our *_CCRULE build rules.

While we are here, also move the common set of CFLAGS set by each
platform's MakefileProto into Makefile.common. Now, each MakefileProto
only needs to set CFLAGS that are specific to that platform, which
ends up being very few (since most platforms were using the exact same
set of CFLAGS).

Relevant issue identified and analyzed by mbarbosa@sinenomine.net.

Reviewed-on: https://gerrit.openafs.org/13262
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ee66819a0c1a9efa98b76a1c18af6233bda1e233)

Change-Id: Ia38d4701aeb4f690b12a6ffdbb42b8ec8c499486
Reviewed-on: https://gerrit.openafs.org/13544
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

DARWIN: replace macro exported by automake

Commit 4706854f57043c8393baa922dd1974176e110a19 removed automake
references from the source tree. As a result, VERSION (exported by
AM_INIT_AUTOMAKE and obtained from Autoconf's AC_INIT macro) is not
available anymore. Unfortunately, a reference to this macro can be found
in src/afs/DARWIN/osi_module.c. Consequently, builds on OS X fail with
the following message:

    osi_module.c:144:32: error: use of undeclared identifier 'VERSION'

To fix this problem, replace VERSION by PACKAGE_VERSION (defined by
AC_INIT).

Reviewed-on: https://gerrit.openafs.org/13354
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 07ed94cfd817dc5a4e2d2712570087388fe7828f)

Change-Id: I14c6c803766ea959dfc6fa4804960c067fc9f16c
Reviewed-on: https://gerrit.openafs.org/13584
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

doc: Remove one lingering reference to src/mcas

Reviewed-on: https://gerrit.openafs.org/13539
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e02ae66c7eef1bfc5df9c3e9f2acde3bc3102390)

Change-Id: Iba79e9f6b2908977a3ad43d802562f1cb8849d66
Reviewed-on: https://gerrit.openafs.org/13558
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

man-pages: create the man3 subdirectory in prep-noistall

This should fix a build failure reported on the openafs-devel list
today.

Reviewed-on: https://gerrit.openafs.org/13533
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e7ea4781f07b29f7f0fc0b5ba17303bd68022e54)

Change-Id: I996aec343f80031c7118e7b6b0d829751a85e228
Reviewed-on: https://gerrit.openafs.org/13535
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Make OpenAFS 1.8.3

Update version strings for the 1.8.3 release.

Change-Id: Ie8b29765e4f45bc3ddbe1aba9e31068da0bb54cf
Reviewed-on: https://gerrit.openafs.org/13546
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Update NEWS for 1.8.3

Finalize the release notes for OpenAFS 1.8.3

Change-Id: I5b5eeedde53a1135c003302719cfdeca4f67e8fd
Reviewed-on: https://gerrit.openafs.org/13545
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Make OpenAFS 1.8.3pre1

Update version strings for the first 1.8.3 prerelease.

Change-Id: I62d22cfba90ec89ac6734d7e8e08ce062dedff80
Reviewed-on: https://gerrit.openafs.org/13444
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Update NEWS for 1.8.3pre1

Release notes for the OpenAFS 1.8.3 prerelease

Change-Id: Ie9f988d0f03f1368125d0e5894d5dd5e9ef95d88
Reviewed-on: https://gerrit.openafs.org/13445
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

afs: avoid afs_GetDownDSlot panic on afs_WriteDCache failure

If afs_GetDownDSlot() finds insuffcient free slots in the
afs_freeDSList, it will walk the afs_DLRU attempting to flush and free
eligible dcaches.  However, if an error occurs during the flush to
CacheItems (afs_WriteDCache()), e.g., -EINTR, afs_GetDownDSlot() will
assert.

However, a panic in this case is overkill, since afs_GetDownDSlot() is a
best-effort attempt to free dslots.  The caller (afs_UFSGetDSlot()) will
allocate more dcaches if needed.

Instead:
- Refactor afs_GetDownDSlot() by moving the QRemove() call to after the
afs_WriteDCache logic, so it accompanies the logic that puts the dcache
back on the freelist.  This is safe because we hold the afs_xdcache W
lock for the duration of the routine.
- If afs_WriteDCache() returns an error, return early and let the caller
handle any recovery.

Reviewed-on: https://gerrit.openafs.org/13364
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d6f52d11c358f71b2c4357cb135e898de7c6277b)

Change-Id: I2630bf04b3e3a88a1fa00f693adf2a77290d47ef
Reviewed-on: https://gerrit.openafs.org/13503
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Redhat: 'clean build area' error message during dkms build/install

dkms invokes a make clean command before and after building the kernel
module. The make clean that is issued at the start of building results
in a nuisance error message because the Makefile doesn't yet exist

    Building module:
    cleaning build area...(bad exit status: 2)

In the dkms.conf file, built from within the openafs.spec, change the
command defined in the CLEAN statement to test for the existence of the
Makefile prior to running the actual make clean

Reviewed-on: https://gerrit.openafs.org/13460
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 10f2c469f45eece0e12573388ae66e392e2dff1c)

Change-Id: If3440b576ad62441bb6b970016fa9808b51abf70
Reviewed-on: https://gerrit.openafs.org/13479
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

Avoid format truncation warnings

With gcc 7.3, we start getting several warnings like the following:

vutil.c: In function ‘VWalkVolumeHeaders’:
vutil.c:860:34: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 63 [-Werror=format-truncation=]
      snprintf(name, VMAXPATHLEN, "%s" OS_DIRSEP "%s", partpath, dentry->d_name);

Most or all of these truncations should be okay, but increase the size
of the relevant buffers so we can build with warning checking turned
on.

Reviewed-on: https://gerrit.openafs.org/13274
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2daa413e3ec061e0653adbd1d6549f15e0659a62)

Change-Id: I61ae1ddae4b2d84147198a1dccb280d0da100a0b
Reviewed-on: https://gerrit.openafs.org/13459
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>