macos: packaging support for MacOS X 10.15

This commit introduces the new set of changes / files required to
successfully create the dmg installer on OS X 10.15 "Catalina".

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

macos: add support for MacOS 10.15

This commit introduces the new set of changes / files required to
successfully build the OpenAFS source code on OS X 10.15 "Catalina".

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

macos: upgrade *.xib files

According to Xcode 11, the *.xib files updated by this commit use an
older format that is potentially insecure when decoded. To fix this
problem, Xcode automatically upgraded these files to the modern format.
These changes are required to build OpenAFS on Catalina (Xcode 11).

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

macos: tell the compiler the system include path

In order to support multiple SDKs, macOS Catalina no longer has the
/usr/include directory. As a result, the compiler needs to know where
these headers can be found. To successfully build OpenAFS on OSX 10.15,
set KROOT so the compiler knows the correct location of these headers.

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

tests: Fix most tests for objdir builds

Fix a few miscellaneous issues with building and running our tests in
objdir builds:

- Our C tests use -I$(srcdir)/../.. in the CFLAGS, so we can #include
  <tests/tap/basic.h>. However, basic.h actually gets copied from
  src/external/c-tap-harness/tests/tap/ to tests/tap/ during the
  build, and so basic.h is available in the objdir, not srcdir. For
  objdir builds, this causes building the tests to fail with failing
  to find basic.h. Fix this to use TOP_OBJDIR as the include path
  instead.

- Our 'make check' in tests/ tries to run ./libwrap; but our cwd will
  be in the objdir for objdir builds, and libwrap is a script in our
  srcdir. Fix this to run libwrap from the srcdir path.

- In tests/opr/softsig-t, it tries to find the 'softsig-helper' binary
  in the same dir as 'softsig-t'. However, softsig-t is just a script
  in the srcdir, but softsig-helper is a binary built in the objdir.
  Fix this to use the BUILD env var provided by the tests wrapper, by
  default.

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

FBSD: Remove pre-8 code

Commit 123f0fb1 (config: remove support for old FreeBSD releases)
removed our support for FreeBSD releases before FreeBSD 8. However,
various areas of code still reference the symbols from those old
versions (e.g. AFS_FBSD53_ENV). Remove our ifdef logic for these old
symbols, according to the following rules:

- In FBSD-specific dirs, assume AFS_FBSD80_ENV is always true (as well
  as the symbols for earlier versions)

- In non-FBSD dirs, convert AFS_FBSD80_ENV to AFS_FBSD_ENV (and do the
  same for all earlier versions)

This allows us to remove code that was specific to older FreeBSD
versions, and simplify some ifdef conditionals.

Also remove the definitions for AFS_FBSD80_ENV and earlier versions in
our existing param.h files.

With this commit, the functions afs_start, afs_vop_lock,
afs_vop_unlock, and afs_vop_islocked are now always unreferenced, so
remove them.

Change-Id: Ia5a5ba5ee5b71a86cb4514305e20f1bb34487100
Reviewed-on: https://gerrit.openafs.org/13812
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Add ppc64le changes in osconf.m4 file.

If swig package is installed on a ppc64le system, build fails for
"libuafs" while running "shlib-build". "shlib-build" gets executed for
builing ukernel.so and this is triggered if "LIBUAFS_BUILD_PERL" is not
empty. Having "swig" package on system sets "LIBUAFS_BUILD_PERL" to
'LIBUAFS_BUILD_PERL' value. The reason for build failure was inside
"shlib-build", 'linker' was not set (it was empty). 'linker' value is
set based on SHLIB_LINKER, which was not defined in  osconf.m4 if build
system is ppc64le.

To fix this add ppc64le_linux26 case in osconf.m4 file.

Change-Id: I79d2f78b2af34207c81f4f5ab05fdc387404acad
Reviewed-on: https://gerrit.openafs.org/13980
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

util: Use a struct for afsUUID_to_string

Replace the use of a character array with a structure that contains
the size of the buffer that is needed.  This allows the C compiler to
perform a type check to ensure the correct sized buffer is used. In
addition, the size of the buffer is now specified in just one location.

Change the signature of the afsUUID_to_string function to return a
pointer to the start of a formatted UUID. This allows the use of
afsUUID_to_string in a way that is consistent with other object
formatting functions:

    struct uuid_fmtbuf uuidstr;
    printf("... %s ...",
             afsUUID_to_string(uuid, &uuidstr));

Update callers to use the new uuid_fmtbuf struct when calling
afsUUID_to_string.

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

viced: add opt to allow admin writes on RO servers

Add the new option -admin-write to allow write requests from superusers
on file servers running in readonly mode (-readonly). This lets sites
run fileservers in readonly mode for normal users, but allows members of
the system:administrators group to modify content.

Change-Id: Id8ed3513a748815c07cb98e426c1d21ac300b416
Reviewed-on: https://gerrit.openafs.org/13707
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Skip checking chunkBytes sanity for RW files

Currently, the IsDCacheSizeOK check can trigger a false positive for a
dcache, if the data in the dcache was populated by a local write to a
file that was later extended with sparse data.

For example: say a client opens a new file, and writes 4 bytes to
offset 0, and then writes 4 bytes to offset 0x400000. After the first
write, the first chunk for the file will contain just 4 bytes, and
after the second write, the first chunk is unchanged (since we're
writing to a different area of the file), but the file is now 0x400004
bytes long. The sparse area of the file will be correctly filled with
zeroes for local reads and on the fileserver, but the 4-byte chunk
causes IsDCacheSizeOK to complain and mark the dcache as invalid.

Even though nothing is wrong, this causes the following scary messages
to potentially appear in the kernel log, and the relevant dcache to be
invalidated:

    afs: Detected corrupt dcache for file 1.536870913.2.2: chunk 0 (offset 0) has 4 bytes, but it should have 131072 bytes
    afs: (dcache 0xfffffdeadbeefb4d, file length 4194308, DV 1, dcache mtime 1575049956, index 996, dflags 0x2, mflags 0x0, states 0x4, vcache states 0x1)
    afs: Ignoring the dcache for now, but this may indicate corruption in the AFS cache, or a bug.

It's probably difficult or impossible to detect if this specific case
is happening, so to avoid this scenario, just avoid doing the size
check at all for RW data from the cache.

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

viced: prevent writes on readonly fileservers

Currently, a fileserver can be initialized as readonly. In this mode,
writes on this server should not be allowed. Unfortunately, updates on
files stored by readonly fileservers are not completely prevented. In
some situations, the check for RO server is omitted (e.g. if the user is
the owner of the file to be updated). In other situations, the same
check is redundant.

To fix these problems, consolidate this check in one place.

Change-Id: Id53e15216404dfe691a87c7b4964ff08924c262c
Reviewed-on: https://gerrit.openafs.org/13934
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

sys: retry lsetpag if errno is EINTR

The variable errno might be set by some system calls to indicate the
reason why the system call in question did not work as expected. If the
setpag system call is interrupted by a signal, the value of errno will
be EINTR. This value means that setpag did not succeed because it was
interrupted.

If lsetpag did not succeed and errno is equal to EINTR, try again.

Change-Id: Ibf306d62fc8d2fa9ccb0692f9031c5aa659b2bfe
Reviewed-on: https://gerrit.openafs.org/12295
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>

afs: afs_pag_wait() makes process unkillable

To enforce a maximum average rate of one PAG allocation per second,
afs_pag_wait(), called by afs_setpag*(), sleeps until the difference
between the current time and pag_epoch gets greater than pagCounter.
Unfortunately, this function ignores the code returned by afs_osi_Wait().
As a result, it is not possible to kill the process that requested the
new pag while afs_pag_wait() is sleeping.

To fix this problem, do not ignore the code returned by afs_osi_Wait().

Change-Id: I6be11a569edcafa6ecdf716e5315fc75f5a128e8
Reviewed-on: https://gerrit.openafs.org/12260
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Ensure CDirty is set during afs_write loop

Currently, in afs_write(), we set CDirty on the given vcache, and then
write the given data into various dcaches. When writing to a dcache,
we call afs_DoPartialWrite, which may cause us to flush the dirty data
to the fileserver and clear the CDirty bit.

If we were given more than 1 chunk of data to write, we will then go
through another iteration of the loop, writing more dirty data into
dcaches, but CDirty will not be set. This can cause issues with, for
example, afs_SimpleVStat() or afs_ProcessFS(), which use CDirty to
determine whether or not to merge in FetchStatus info from the
fileserver into our local cache. This can cause our local cache to
incorrectly reflect the state of the file on the fileserver, instead
of the state of the locally-modified file in our cache.

A more detailed example is as follows. Consider a small C program that
copies a file, fchmod()ing the destination before closing it:

    void
    do_copy(char *src_name, char *dest_name)
    {
        /* error checking elided */
        src_fd = open(src_name, O_RDONLY);
        dest_fd = open(dest_name, O_WRONLY|O_CREAT|O_TRUNC, 0755);
        fstat(src_fd, &st);
        src_buf = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, src_fd, 0);
        write(dest_fd, src_buf, st.st_size);
        munmap(src_buf, st.st_size);
        close(src_fd);
        fchmod(dest_fd, 0100644);
        close(dest_fd);
    }

Currently, on FBSD, using this to copy a 7862648-byte file, using a
smallish cache (10000 blocks) will cause the destination to appear to
be truncated, because avc->f.m.Length will be incorrect, even though
all of the relevant data was written to the fileserver.

On most other platforms such as SOLARIS and LINUX, this is not a
problem, since currently they only write one page of data at a time to
afs_write(), and so they never hit multiple iterations of the while()
loop inside afs_write().

To fix this, just set CDirty on every iteration of the while() loop in
afs_write(). In general, we need to set CDirty after calling
afs_DoPartialStore() anywhere if the caller continues to write more
data. But all callers already do this, except for this one instance in
afs_write().

Thanks to tcreech@tcreech.com for helping find occurrences of the
relevant issue.

FIXES 135041

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

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.

Change-Id: I53118960462c0057725e749cbf588e98024217c3
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>

afs: Avoid -1 error for vreadUIO/vwriteUIO

Commit c6b61a45 (afs: Verify osi_UFSOpen worked) added various checks
to return an error if a given osi_UFSOpen failed. However, two of
these checks (in afs_UFSReadUIO and afs_UFSWriteUIO) result in us
returning -1 on error, in functions that otherwise return errno codes
(e.g. ENOSPC). An error code of -1 might get interpreted as
RX_CALL_DEAD, which would be rather confusing, so use EIO as a generic
error instead.

Change-Id: I23b9a73b82d999d8ee4670b5e7ec39b9d820fb0f
Reviewed-on: https://gerrit.openafs.org/13931
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

doc: Fix realm capitalization

In this example, krbtgt.Example.COM clearly refers to the principal
name converted from krbtgt/Example.COM, and so by convention the realm
name would be in all caps. Fix this example to use the all-caps realm
name, for consistency.

This mistake was introduced by commit 1cc8feb6 (doc: replace hostnames
with IETF example hostnames), the realm was in all caps before that
commit.

Mistake spotted by Chas Williams.

Change-Id: Icaf4931868752064c4617c8ad778122e076ae3cb
Reviewed-on: https://gerrit.openafs.org/13930
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-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().

Change-Id: Ia36c58e5906f5e8df59936f845ae11e886e8ec38
Reviewed-on: https://gerrit.openafs.org/13915
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));

Change-Id: Iedccc25e50ee32bd1144e652b951496cb7dde5d2
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>

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;

Change-Id: I2bdea2e808bb215720492b0ba6ac1a88da61b954
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>

LINUX 5.3: Add comments for fallthrough switch cases

With commit 6e0f1c3b45102e7644d25cf34395ca980414317f (LINUX: Honor
--enable-checking for libafs) building libafs against a linux 5.3
kernel compiles with errors due to fall through in case statements when
--enable-checking / --enable-warning is used.

e.g.
  src/opr/jhash.h:82:17: error: this statement may fall through
                                [-Werror=implicit-fallthrough=]
         case 3 : c+=k[2];
                  ~^~~~~~

The GCC compiler will disable the implicit-fallthrough check for case
statements that contain a "special" comment ( /* fall through */ ).

Add the 'fall through' comment to indicate where fall throughs are
acceptable.

This commit only adds comments and does not alter any executable code.

The -Wimplicit-fallthrough flag was enabled globally in the linux kernel
build in 5.3-rc2 (commit: a035d552a93bb9ef6048733bb9f2a0dc857ff869
Makefile: Globally enable fall-through warning)

Change-Id: Ie6ca425e04b53a22d07b415cb8afd172af7e8081
Reviewed-on: https://gerrit.openafs.org/13881
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: avoid extra VL_GetEntryByName for .readonly's

In the VLDB, there's only one logical entry for a volume and its
associated clones; there are not separate entries for the RW volume
"avol", the RO volume "avol.readonly", and the BK volume
"avol.backup".  And so, when looking up a volume in the VLDB by name,
the vlserver ignores any trailing ".readonly" or ".backup" in the
given name.  More concretely, the result of calling
VL_GetEntryByName*("avol") is identical to that from calling
VL_GetEntryByName*("avol.readonly").

Accordingly, if afs_GetVolumeByName(name) failed because the volume
was not found in the VLDB, afs_GetVolumeByName(name.readonly) will
fail as well (barring a change in external circumstances, such as the
volume being created or a network connection coming back up).
Therefore, the extra call in EvalMountData() is not necessary and can
be removed.

Remove the extra call, to slightly improve the response time of the
client if the volume in question does not exist, and to reduce
vlserver load when patched clients are looking up nonexistent volumes.

Change-Id: I4f2f668107281565ae72a563a263121bd9bb7e3c
Reviewed-on: https://gerrit.openafs.org/13334
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

RedHat: package rxstat_* programs

Install libadmin rxstat_* sample programs with 'make install'/'make
dest'. Include these programs in the openafs rpm package.

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

RedHat: Update makesrpm.pl to use @PACKAGE_VERSION@ instead of @VERSION@

Commit 2f2c2ce62aa17ecac3651d64c1168af926f7458b
'Remove automake autoconf vars' replaced the automake variable @VERSION@
with the autoconf variable @PACKAGE_VERSION@. (Gerrit #13357)

The RedHat openafs.spec.in is not processed using autoconf, but
by 'makesrpm.pl', which was not updated to use @PACKAGE_VERSION@.

Update makesprm.pl to use @PACKAGE_VERSION@ instead of @VERSION@

Change-Id: I74d1d61e40e660459942ec68cfdedfe569a6abeb
Reviewed-on: https://gerrit.openafs.org/13887
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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.

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

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.

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

Retire the AFS_PTR_FMT macro

Originally '%x' was commonly used as the printf specifier for formatting
pointer values.

Commit 37fc3b01445cd6446f09c476ea2db47fea544b7d introduced the
AFS_PTR_FMT macro to support platform-dependent printf format specifiers
for pointer representation. This macro defined the format specifier as
'%p' for Windows, and '%x' for non-Windows platforms.

Commit 2cf12c43c6a5822212f1d4e42dca7c059a1a9000 changed the printf
pointer format specifier from '%x' to '%p' on non-Windows platforms as
well, so at this point '%p' is the printf pointer format specifier for
all supported platforms.

Since the AFS_PRT_FMT macro is no longer platform-dependent, and all C89
compilers support the '%p' specifier, retire the macro to simplify the
printf format strings.

Change-Id: I0cb13cccbe6a8d0000edd162b623ddcdb74c1cf7
Reviewed-on: https://gerrit.openafs.org/13830
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>

Pass -shared when linking some shared libraries

Currently, we use $(LT_LDLIB_shlib) to build most of our shared
libraries. This invokes libtool, passing our various flags like
PTH_LDFLAGS and PTH_CFLAGS (since all of our shared-library code is for
pthreads). Notably, we do NOT pass the -shared flag; the -shared flag
tells libtool to only build a shared library, and to not also build a
static library (on systems where libtool supports building shared and
static libraries simultaneously). Because of this, our LT_LDLIB_shlib
invocations build both, which is reasonably correct for our per-module
convenience libraries (that end up getting linked statically into the
binaries that we install), but is not entirely correct for the public
libraries that we install.  Specifically, for ABI compatibility
purposes, we must provide both shared and static libraries of the public
libraries that we install, and since libtool on AIX does not build (or
install) a static library at all with --mode-link unless -static is
passed, we have separate rules to build the shared and static libraries
for final installation.

This can cause install errors with parallel make (on non-AIX systems),
and possibly other errors, when we go to install the relevant library
into TOP_LIBDIR.  For example, in src/kopenafs, we have the following
rules:

    ${TOP_LIBDIR}/libkopenafs.${SHLIB_SUFFIX}: libkopenafs.la
            ${LT_INSTALL_DATA} libkopenafs.la ${TOP_LIBDIR}/libkopenafs.la
            ${RM} ${TOP_LIBDIR}/libkopenafs.la

    ${TOP_LIBDIR}/libkopenafs.a: libkopenafs.a
            ${INSTALL_DATA} libkopenafs.a $@

The rule to install libkopenafs.so will invoke libtool to do the
install, which will install libkopenafs.so, libkopenafs.so.X.Y, and
libkopenafs.a (from .libs/libkopenafs.a, not the libkopenafs.a we
built separately). If we are running the rule to install libkopenafs.a
in parallel, it may fail with an error like so:

    /usr/bin/install -c -m 644 libkopenafs.a /home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a
    /usr/bin/install: cannot create regular file '/home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a': File exists
    make[3]: *** [Makefile:35: /home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a] Error 1

Even without that error, this confusion means that the libkopenafs.a
installed into TOP_LIBDIR may be the one from
src/kopenafs/libkopenafs.a, or the one from libtool's
src/kopenafs/.libs/libkopenafs.a; it depends on what order the rules
are run. If those libraries are different, that could potentially
cause all sorts of other problems.

To avoid this, we can pass -shared to libtool when building our shared
libraries. We used to pass -shared when building shared libraries,
since -shared is almost always one our SHLIB_LDFLAGS set in
src/osconf.m4. However, ever since commit 2c3a517e (Retire
Makefile.shared), SHD_CFLAGS, SHD_LDFLAGS, and SHD_CCRULE have all
been unused, and SHD_LDFLAGS was the only place where we used
SHLIB_LDFLAGS. As a result, we never use SHLIB_LDFLAGS anywhere, and
so we never pass -shared to anything.

However, we cannot pass -shared to libtool when building all of our
shared libraries, since we do need the static library for our per-module
convenience libraries. For example, liboafs_rx.la has no
separately-built static library (librx.a is for LWP, liboafs_rx.{so,a}
is for pthreads), but liboafs_rx needs to be linked statically into all
of our command-line tools.

So to fix this, introduce a new linking rule, called
LT_LDLIB_shlib_only, which causes the given library to be built only
as a shared library (by giving -shared to libtool), and not as a
static library. Update the build rules to use this new linking rule
for the libraries that need it, and leave the others alone. Since the
only use of LT_LDLIB_shlib_missing is also used for a public library
(afshcrypto), also pass -shared in that rule.

Also remove SHD_* and SHLIB_LDFLAGS variables, since they are unused.

Change-Id: Ia9e040afa3819f1ff70d050a400fecb9624bb9ba
Reviewed-on: https://gerrit.openafs.org/13786
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

aklog: avoid infinite lifetime tokens by default

Currently we get tokens for infinite lifetime using aklog impersonate
feature. Based on inputs from Ben, this was done for server to server
tickets to be valid forever.  However on 1.8.x we have other
mechanisms that were usable for server-to-server authentication with
strong enctypes, so we do not need to provide user level akimpersonate
to generate tokens for infinite lifetime. For this we have added new
option -token-lifetime <hrs>, this can take values from 0 to 720
hours. If 0 is specified it means tokens will have infinite lifetime.
By default 10 hours will be token lifetime for akimpersonate tokens.

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

rx: add missing CLEAR_CALL_QUEUE_LOCK to LWP rx_GetCall

In all other places where we remove an rx_call from a queue, we also
CLEAR_CALL_QUEUE_LOCK.  This isn't necessary in the LWP
(non-RX_ENABLE_LOCKS) version of rx_GetCall because rx_call does not
have member call_queue_lock for LWP.  However, for the sake of
consistency for future maintainers, add a CLEAR_CALL_QUEUE_LOCK here as
well; it is a no-op for LWP.

No functional change is incurred by this commit.

Change-Id: Ibbb005fa15dd517fc5282574d0d4abd74e937e02
Reviewed-on: https://gerrit.openafs.org/13695
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

SOLARIS: add autoconfig support for Studio 12.6

Add the canonical install path for Studio 12.6 to the autoconfig test.

Change-Id: Id90ae1816845ed8aaa80be7b3d57846059084339
Reviewed-on: https://gerrit.openafs.org/13867
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rx: clear call_queue_lock after removing call from queue

The call_queue_lock is set to either rx_serverPool_lock or
rx_freeCallQueue_lock, depending on whether an rx_call resides in the
rx_incomingCallQueue or the rx_freeCallQueue, respectively.  This value
is used by rxi_ResetCall to lock the appropriate queue before removing a
call.  Therefore, the call_queue_lock should be cleared after a call is
removed from a queue.

This issue has no known external symptoms; however, repairing this is
helpful to developers examining core files.

Repair two instances where the call_queue_lock is not cleared.

Change-Id: Id1d9ac8454c1e07c10766dffb2a2beac7122bf3e
Reviewed-on: https://gerrit.openafs.org/13641
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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.

Change-Id: Icdc58a94f0cd5857903836d94e5cf7814ce7e088
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>

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.

Change-Id: Icb8bc1edd34ca29c3094b976436177b18bfc8d1d
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>

aklog: use any enctype in get_credv5

We currently always pass DES as the requested enctype to
get_credv5_akimpersonate, but this means we will fail to use our
service princ if we're using another enctype (say, AES) with rxkad-k5.
To allow this to work with any enctype, just don't pass any requested
enctypes, and just use the enctype inside the 'entry' returned to us
from krb5_kt_get_entry.

Remove all of the logic associated with the now-unused
"allowed_enctypes" argument. Also remove the logic handling the case
where "service_principal" is NULL (since no callers pass a NULL
service_principal), to make it easier to take out the allowed_enctypes
related code.

Change-Id: Id11514ead26e15a287791c40509a001a1861df97
Reviewed-on: https://gerrit.openafs.org/13827
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

aklog: retry getting tokens for KRB5_KT_NOTFOUND error

If we're creating tokens with -keytab and our AFS service principal is
afs@<cellname>, we'll first try creating tokens with
afs/<cellname>@<cellname> and krb5_kt_get_entry will fail with
KRB5_KT_NOTFOUND. Since we do not retry for KRB5_KT_NOTFOUND error, we
will not get tokens. So in order to get tokens for principal
afs@<cellname> we should retry for KRB5_KT_NOTFOUND error. Thanks to
jpjanosi@us.ibm.com for finding this issue and suggesting a fix.

Change-Id: I8af9df9876973badc4631f509eebcda46d667cef
Reviewed-on: https://gerrit.openafs.org/13826
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

rx: Introduce rxi_NetSend

Introduce a small wrapper around osi_NetSend, called rxi_NetSend. This
small wrapper allows future commits to change the code around our
osi_NetSend calls, without needing to change every single call site,
or every implementation of osi_NetSend.

Change most call sites to use rxi_NetSend, instead of osi_NetSend. Do
not change a few callers in the platform-specific kernel shutdown
sequence, since those call osi_NetSend for platform-specific reasons.

This commit on its own does not change any behavior with osi_NetSend;
it is just code reorganization.

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

aklog: Use HAVE_ENCODE_KRB5_ENC_TKT_PART for aklog impersonate

In get_credv5_akimpersonate we use HAVE_ENCODE_KRB5_ENC_TKT which is not
defined, due to this we always return -1 from this routine for non
Heimdal case. We have a another define i.e
HAVE_ENCODE_KRB5_ENC_TKT_PART which is defined if
encode_krb5_enc_tkt_part function is present. In current code
encode_krb5_enc_tkt_part is called from krb5_encrypt_tkt_part and
krb5_encrypt_tkt_part is called from get_credv5_akimpersonate for non
Heimdal case. So we should change HAVE_ENCODE_KRB5_ENC_TKT to
HAVE_ENCODE_KRB5_ENC_TKT_PART.
Also while we're here, add a declaration for the internal function
encode_krb5_ticket, so we can build this newly-enabled code without
warnings.

Change-Id: I8f740e319ad279e284efaa407e6f92d0dc7a1bf6
Reviewed-on: https://gerrit.openafs.org/13825
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>

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.

Change-Id: I857bb3b697909668eb71224b631dfbb7e3c03d3c
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>

LINUX: Check for -Wno-error=frame-larger-than=

Commit cc7f942a (LINUX: Disable kernel fortuna large frame errors)
added -Wno-error=frame-larger-than= to the CFLAGS for a file, but
older gcc (like 4.3.4 from SLES 11.x) does not support this flag,
causing a compiler error.

To avoid this, add a configure check for
-Wno-error=frame-larger-than=, and only use it if the compiler
supports it.

Thanks to mvitale@sinenomine.net for discovering the error.

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

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.

Change-Id: I9533e3a40922c76d4179e0ada393103c2aa533dd
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>

opr: Include procmgmt_softsig.h for WINNT

On WINNT, procmgmt_softsig.h exists to implement our opr softsig
routines in terms of procmgmt routines. Any time we include
opr/softsig.h in cross-platform code, we currently must also include
afs/procmgmt_softsig.h so we can build on WINNT. We currently do not
do this in src/xstat, causing build failures on WINNT.

To avoid this, just make opr/softsig.h include procmgmt_softsig.h
itself, so all of the opr/softsig.h users don't have to remember to do
this. Link xstat_*_test against procmgmt, so linking will succeed for
those tools.

Change-Id: I2dc8226d438be25cdccbe96474220d7c81ae25b9
Reviewed-on: https://gerrit.openafs.org/13824
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

aklog: Free client/server princs in get_credv5

Inside get_credv5, client_principal is static so the first time
get_credv5 runs we'll allocate memory for it, and on subsequent calls
we'll reuse the same value.

However, if we call get_credv5_akimpersonate, we'll free
client_principal and never change what client_principal points to. If we
need to call get_credv5 again (because we need to retry getting creds),
we'll reuse the old value for client_principal, but since it points to
free memory we'll segfault or cause other problems.

To avoid this, change get_credv5 so we allocate the client and server
principals on each invocation of get_credv5 and free them before
returning from get_credv5. Since we free the client and server
principals inside get_credv5, remove freeing the client and server
principals inside get_credv5_akimpersonate.

Change-Id: Ie263aa2c03efc75e818d9007347dca9e42380dd4
Reviewed-on: https://gerrit.openafs.org/13761
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Actually free resources during warm shutdown

Currently, the shutdown_*() code paths for several subsystems only
free the memory for that subsystem for "cold" shutdowns, and not for
"warm" shutdowns. This means the memory gets leaked during a "warm"
shutdown, since we never free these resources anywhere else.
Specifically, this happens in shutdown_bufferpackage, shutdown_AFS,
and shutdown_osinet.

To avoid these leaks for warm shutdowns, just move the
afs_cold_shutdown check around a little, so we free the relevant items
in either codepath.

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

aklog: free kbr5_creds before returning from rxkad_get_token

rxkad_get_ticket allocates 'v5cred' which should be freed when we
return from rxkad_get_token.

Change-Id: I09b20781f0856ab8e230e0af271e9d0c58fee90c
Reviewed-on: https://gerrit.openafs.org/13760
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

rx: Convert rx_FreeSQEList to rx_freeServerQueue

Currently, rx_serverQueueEntry structs are placed on the
rx_FreeSQEList linked list instead of being freed directly, but
managing this list is done a bit oddly. The first field in struct
rx_FreeSQEList is an opr_queue, but we don't use the opr_queue_*
macros to manage the list. Instead, we just assume the first field in
a struct rx_serverQueueEntry is a pointer that we can use to link
entries together. This is currently true and works, but it's an odd
way of maintaining such a list, and of course would break if we ever
moved the fields around in struct rx_serverQueueEntry.

Make this code more closely follow the normal way of managing
opr_queue lists, by using opr_queue_* macros, and changing
rx_FreeSQEList to be an opr_queue itself. Change the name to
rx_freeServerQueue to ensure all callers are changed, and to match the
naming convention for the other linked lists for rx_serverQueueEntry
structs. Also move rx_freeServerQueue and its associated lock
freeSQEList_lock to be declared static inside rx.c, since neither are
referenced outside of rx.c.

The general idea for this commit suggested by kaduk@mit.edu.

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

libafs: Create debug KMODDIR for FBSD debug inst

Commit 99418024 (libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst)
made it so we create the kmod installation dir before copying our
module into it. However, if we build a 'debug' variant of our module,
the FreeBSD build process also installs debug symbols in a different
directory, ${DESTDIR}${KERN_DEBUGDIR}${KMODDIR}, which may not exist.
So do the same thing for that dir too, if --enable-debug-kernel is
turned on, so the build still works.

To do this, introduce the LIBAFS_REQ_DIRS var, to make it easier to
keep track of which dirs we may need to create.

Change-Id: Id1ad72f6c19d5949d38ee97334b4014ae6ef16ad
Reviewed-on: https://gerrit.openafs.org/13690
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Andrew Deason <adeason@sinenomine.net>

xstat: Define AFS_PTHREAD_ENV on WINNT

Commit 6b67cac4 (convert xstat and friends to pthreads) converted the
xstat utilities to pthreads, but we still need to explicitly pass
AFS_PTHREAD_ENV on WINNT to enable various pthread-specific code
paths. So give -DAFS_PTHREAD_ENV for our objects in this dir.

Change-Id: I222b99399a5fad3df528be2bc31823eb8bc52c62
Reviewed-on: https://gerrit.openafs.org/13823
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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).

Change-Id: Id29888d88bfdd9585e017217a9951eb645c65336
Reviewed-on: https://gerrit.openafs.org/13822
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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>

WINNT: Do not link ptclient.obj in libafsauthent

ptclient.c contains a stub definition for osi_audit, but audit.c
already contains a real definition for osi_audit. libafsauthent
doesn't seem to actually need anything from ptclient (and the Unix
libafsauthent doesn't appear to use it), so just don't include
ptclient when linking libafsauthent.

Change-Id: I4172b80138e5ea121fc3ae2689cf4ed23c81e35b
Reviewed-on: https://gerrit.openafs.org/13819
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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.

Change-Id: I65f4d87085a8917c9b11d7c27b8e3902cd2a1c1c
Reviewed-on: https://gerrit.openafs.org/13818
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

WINNT: Make opr_threadname_set a no-op

We don't supply an implementation for opr_threadname_set for WINNT;
don't pretend that we do.

Change-Id: Ifa8042253d0aa10f365356d93cea3fad4686371a
Reviewed-on: https://gerrit.openafs.org/13817
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rxkad: Improve ticket5 import from Heimdal

The current method of importing our ticket5 code from Heimdal has a
few issues:

- The der-protos.h file we generate contains numerous function
  prototype declarations that looks like this:

    ret-type func(parm-list, type */* comment */);

  which cause numerous warnings on WINNT, because the '*/*' sequence
  looks like the end of a nonexistent comment. This was previously
  fixed manually in commit 8b5d3a73 (rxkad: remove warnings from
  der-protos.h), but each time we regenerated our ticket5 code, the
  same thing would happen.

- We manually insert an include for "asn1_err.h" in our v5der.c, and
  the v5gen.c we pull in has an include for <asn1_err.h> inside it.
  During a WINNT build, these can pull in different asn1_err.h files
  (one from us, and one from the "Heimdal compatibility layer SDK" or
  anything else in our include paths). Since the asn1_err.h in our
  tree doesn't have an include guard, the code for both gets included,
  which can cause various problems.

- Our current asn1_err.h file that we include is ultimately generated
  by the awk-based compile_et from e2fsprogs, not the C-based
  compile_et from Heimdal. This likely happened by accident because
  the Heimdal build system uses the system compile_et by default. This
  flavor of compile_et generates arguably inferior comerr-based header
  files (they lack include guards, and they use #define constants
  instead of enums).

Fix these issues with some edits to our README.v5 script:

- Apply a simple sed filter when we pull in der-protos.h to change
  '*/*' into '* /*', to remove the relevant warnings.

- Instead of inserting an include for asn1_err.h into v5der.c in our
  import script, just put it in ticket5.c, making it easier to see and
  edit. Change this to <asn1_err.h> so it uses the same asn1_err.h as
  in v5gen.c.

- Add a note to run the Heimdal build with COMPILE_ET=no, so the
  Heimdal build system uses the in-tree compile_et, instead of
  whatever is on the relevant system.

With these changes, redo the Heimdal import from the same version of
the Heimdal codebase.

Change-Id: I01e06f2799f1c828b8224c3425079b313ffb5b6b
Reviewed-on: https://gerrit.openafs.org/13816
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

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.

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

rxgk: Add NTMakefile to install headers

Commit 83eec909 (Implement afsconf_GetRXGKKey) added a reference to
rx/rxgk_types.h inside cellconfig.p.h. Nothing ever added src/rxgk
WINNT makefiles, so that include file is never installed into
place, breaking the WINNT build when code tries to include
cellconfig.h.

To fix this and other code that needs rxgk header files, create an
NTMakefile for src/rxgk, which just exists to install headers into
place. Call it from the top-level NTMakefile right before copying in
the auth headers.

Change-Id: Id111479f55b4c330640e80d167a8af664fe3622e
Reviewed-on: https://gerrit.openafs.org/13814
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

rx: Avoid leaking 'sq' in libafs rx_GetCall

Currently, in rx_GetCall when building for the kernel, if we notice
that we're shutting down (that is, if afs_termState has reached
AFSOP_STOP_RXCALLBACK), we return immediately. However, 'sq' may have
been allocated much earlier in this function, and if we return here,
we never free 'sq' or set it on any list.

Returning immediately is also unnecessary here; if we just 'break' out
of our wait loop, 'call' will still be NULL, and we'll break out of
the outer loop, and go through the rest of the function like normal.
The only difference is, if we 'break' instead of 'return'ing, we'll
put 'sq' on the free list before returning.

So, just 'break' out of the loop instead of returning, so we put 'sq'
on the free list and avoid leaking its memory.

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

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'.

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

afs: Introduce afs_FreeFirstToken

Change afs_FreeOneToken to unlink the given token from its container,
instead of requiring its caller to do so. Rename the function to
afs_FreeFirstToken, to help indicate the change in behavior.

Also, while we are changing afs_FreeTokens to accommodate this change,
simplify afs_FreeTokens a little, making it resemble
afs_DiscardExpiredTokens a bit more.

[kaduk@mit.edu: add note about dead store elimination]

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

FBSD: Use ucontext for FreeBSD 10+ on amd64

Currently, running any LWP program on recent FreeBSD on amd64 causes
(or can cause) a SIGBUS very quickly. This is possibly because our
stack management code in LWP only ensures our stacks are 4 or 8-byte
aligned in most cases (except DARWIN, which gets 16-byte-aligned
stacks), according to the value of STACK_ALIGN. The amd64 ABI mandates
that stacks be 16-byte-aligned, and some function calls assume that
this is followed, causing a SIGBUS when it is not. FreeBSD on amd64
currently uses process.amd64.s for its savecontext() implementation,
which does not do any checking or fixup of the stack alignment.

This behavior has been observed on amd64 with FreeBSD 11 specifically,
but it probably happens on any FreeBSD release when using clang.
FreeBSD switched to clang as the default compiler with FreeBSD 10, so
this probably occurs with FreeBSD 10 and newer.

We could perhaps try to fix this by changing our stack management
code, but we can also avoid most of this nonsense by just using
ucontext instead of our custom assembly code. So, do that, by setting
USE_UCONTEXT for FreeBSD 10+. Also enable the same 'stackvar'-based
workaround in savecontext() as Linux uses, since otherwise 'topstack'
appears to always be NULL, and triggers our stack overflow checks.

Note that while LWP use is deprecated, as of this commit many small
utilities (like 'fs') are still linked to LWP, and so are unusable
without a fix like this.

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

FBSD: Set KERNBUILDDIR for --with-bsd-kernel-build

Currently, specifying --with-bsd-kernel-build during configure causes
us to set BSD_KERNEL_BUILD, which sets KBLD in MakefileProto.FBSD.in,
but nothing ever uses KBLD. This means that when we use
--with-bsd-kernel-build, we don't actually build against the
configuration for that kernel, which can result in a libafs.ko that
cannot be loaded or causes other errors. Specifically, if trying to
build for a VIMAGE kernel, the kernel complains when trying to load
libafs:

    [...] kernel: link_elf_obj: symbol in_ifaddrhead undefined
    [...] kernel: linker_load_file: Unsupported file type

The FreeBSD module build system looks for KERNBUILDDIR for an
alternative build, which it uses to pull in opt_global.h and other
required pieces from the build tree. So just specify KERNBUILDDIR if
we have one.

At the same time, avoid setting our default value for BSD_KERNEL_BUILD
for FBSD when the calculated dir doesn't exist. At least for the
default GENERIC kernel on FreeBSD 11.2-RELEASE, there may not be a
build dir on the running machine, and so setting BSD_KERNEL_BUILD to
the calculated value causes the build to fail when it doesn't exist.

Change-Id: Ib3079354f9f6dba13970de5308bbcecaf9b35059
Reviewed-on: https://gerrit.openafs.org/13746
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

FBSD: Call CURVNET_SET/CURVNET_RESTORE for VIMAGE

In commit 9703b023 (FBSD: VIMAGE support), we changed a couple of our
variable references to their V_* equivalents, to accommodate kernels
with VIMAGE turned on. This allows us to build, but causes us to crash
whenever we hit that code when VIMAGE is enabled, because the relevant
macros reference 'curvnet', which is NULL outside of networking code.

What we're supposed to do is to set 'curvnet' before entering
networking code by calling 'CURVNET_SET(xxx)', and reset it afterwards
by calling 'CURVNET_RESTORE()'. We must make exactly one _RESTORE call
for each _SET, and they are supposed to be run at the same level of
scope.

So to avoid the crashes, make the relevant CURVNET_* calls whenever we
look at networking info. We currently only do this in a few places:

- In afs_SetServerPrefs, to try to detect if a given server address is
  in the same network as one our local interfaces (V_in_ifaddrhead)

- In rxi_GetIFInfo, for some MTU-related info (V_ifnet)

- In rxi_FindIfnet, for some MTU-related info (ifa_ifwithnet)

As for what vnet we actually set 'curvnet' to, we could set it to the
vnet of the current thread (TD_TO_VNET(curthread)), or we could set it
to the vnet of an associated network object (a socket, an interface,
etc). Since all of our network-related code goes through Rx, in this
commit we set curvnet to the vnet of the Rx socket
(rx_socket->so_vnet).

Note that VIMAGE is optional in 11-RELEASE, but is turned on by
default in 12.0-RELEASE. For more information, see:
https://wiki.freebsd.org/VIMAGE/porting-to-vimage

[adeason@dson.org: Reworded commit message; moved some code around.]

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

afs: Update style in afs_tokens.c

Fix a few style nits and other minor edits in afs_tokens.c. Mark a few
functions 'static' that are not referenced outside of that file.

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

rx: Update style in rx_opaque.c

Fix a few style nits in rx_opaque.c

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

Remove dead code

There is a perhaps-surprisingly large amount of code disabled behind
directives like '#if 0', '#ifdef notdef', and '#ifdef notyet'. At
best, this code is clutter, and at worst some of it is
confusing/outdated, and/or confusingly nested inside other
preprocessor conditionals. Sometimes this disabled code shows up when
grepping the tree, and causes a nuisance when refactoring related
areas of code.

Get rid of all of it. If anyone ever wants this code back, it can
always be restored by reverting portions of this commit.

Also delete some comments that clearly refer to the disabled code, and
in some cases, adjust the adjacent comments to make sense accordingly.

This commit doesn't touch any files in src/external/.

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

Remove a couple more uses of libafsauthent.a

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

LINUX: Make sysctl definitions more concise

Our sysctl definitions are quite verbose, and adding new ones involves
copying a bunch of lines. Make these a little easier to specify, by
defining some new preprocessor macros.

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

LINUX: Honor --enable-checking for libafs

When we build the kernel module on LINUX, we don't pass in any of our
CFLAGS, since the Linux buildsystem itself figures out what flags are
needed. However, this means that we don't pass in -Werror when
--enable-checking is turned on, so warnings may not cause the build to
fail.

To fix this, create a new autoconf variable, called CFLAGS_WERROR,
that only contains -Werror if --enable-checking is turned on. We then
pass that into the Linux module buildsystem, so -Werror is given to
the compiler when building our module.

Change-Id: I0f1ec8b1a8096d10642c67b86314604c20ea2c60
Reviewed-on: https://gerrit.openafs.org/13682
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Free afs_thiscell during shutdown

Currently, afs_thiscell can be allocated (via strdup) during client
startup, but is never freed. Free it in shutdown_cell() to avoid
leaking the memory.

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

afs: Introduce shutdown_dynroot()

Add a shutdown sequence for dynroot, which frees the afs_dynrootDir
and afs_dynrootMountDir blobs, if they exist. Otherwise, we can leak
the memory allocated for those blobs.

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

FBSD: Remove unnecessary explicit osi_fbsd_alloc

AFS_KALLOC is already defined to be osi_fbsd_alloc on FBSD, so this
extra #ifdef here is completely unnecessary. Remove it.

Do the same for AFS_KFREE/osi_fbsd_free.

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

FBSD: Give 0 'rootrefs' to vflush on unmount

Currently, in afs_unmount, we give vflush a 'rootrefs' arg of 1,
indicating that we hold 1 reference on the root vnode. But ever since
commit 6eb1088a (freebsd: properly track vcache references), we drop
the ref for the root vnode at the beginning of this function.

What happens currently in afs_unmount for a normal successful umount
is something like this (at least, on FreeBSD 11.2-RELEASE):

- We afs_PutVCache the afs_globalVp vcache, reducing its v_usecount
  and v_holdcnt to 0, and afs_globalVp is set to NULL.

- vflush calls afs_root() to get the root vnode, which sees that
  afs_globalVp is NULL, and so calls afs_GetVCache for the root fid
  and returns it (and sets afs_globalVp to that vcache), with a
  v_usecount of 1.

- vflush tries to vgonel() all of our vnodes, which calls our
  afs_vop_reclaim, which calls afs_FlushVCache(). For the root vnode
  specifically, vflush() sees that v_usecount is nonzero, and so skips
  calling vgonel() at first, but later calls vgone() on it
  specifically because we gave a nonzero 'rootrefs'. The resulting
  afs_FlushVCache() for the root vnode fails, because the root vnode's
  v_usecount is still 1. Since a failure from afs_vop_reclaim would
  cause a panic, we just log a warning and try to continue on anyway.

- vflush() calls vrele() on the root vnode, right before returning.

All of this allows the unmount to proceed, but this means that most of
afs_FlushVCache() doesn't actually run for the root vcache, and it
means we always log a warning like this on unmount:

    afs_vop_reclaim: afs_FlushVCache failed code 16 [...]

In addition, this means that setting afs_globalVp at the beginning of
afs_unmount() is largely pointless, since it gets set to a vcache
again near the beginning of vflush().

To avoid all of this, stop lying to vflush about how many references
to the root vnode we hold, and just say that we hold 0 references.

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

FBSD: Handle F_UNLCK in VOP_ADVLOCK

When a_fl->type is F_UNLCK, FreeBSD gives our VOP_ADVLOCK an a_op of
F_UNLCK, instead of F_SETLK like we expect. This causes afs_lockctl to
return EINVAL, since F_UNLCK isn't a normal fcntl lock op, and so
userspace requests to unlock fcntl-style locks always fail. This can
be seen, for example, when trying to use sqlite3 to access a database
that lives in afs.

This F_UNLCK behavior in FreeBSD seems a bit peculiar, but has been
around effectively forever (since 4.4BSD-Lite). So just work around
it.

[adeason@dson.org: minor style adjustments and commit message/comment
rewording.]

Change-Id: I8bfaff9274e40761aa291930430a08b83b524d1b
Reviewed-on: https://gerrit.openafs.org/12579
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

afs: Fix a few ARCH/osi_vcache.c style errors

Most of the ARCH/osi_vcache.c implementations were defining functions
like:

void
osi_foo(args) {
    /* impl */
}

But our prevailing style is:

void
osi_foo(args)
{
    /* impl */
}

Fix them to follow our prevailing style, and fix a couple of the more
obvious errors with identation and goto label.

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

afs: Check for invalid afs_fakestat_enable values

The only valid values for afs_fakestat_enable right now are 0, 1, and
2. Check if the given value actually matches one of those, in case we
have mismatched libafs/afsd versions, and future code adds new values.

Return EINVAL and log a message if we're given an unknown value.

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

LINUX: Turn on AFS_NEW_BKG

AFS_NEW_BKG allows libafs to request the afsd background daemon
processes to do certain userspace operations. This is currently only
used on DARWIN for handling EXDEV file moves, but this framework can
be useful on LINUX, as well. So, turn it on for LINUX.

This commit does not introduce any new background operations for LINUX
to actually use; we're just turning on the new framework. Future
commits will introduce new background operations.

Change-Id: I5d371f85b87899ce6ab2d5e520954a893679d37e
Reviewed-on: https://gerrit.openafs.org/13284
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

afs: Remove reference to nonexistent function

The real lie here is that TellALittleWhiteLie exists in afs_vcache.c.
That has never been true, ever since OpenAFS 1.0.

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

afs: Remove useless afs_GetVCache arguments

The 'avc' argument in afs_GetVCache has never been used, all the way
back to OpenAFS 1.0. The 'cached' argument was set correctly, but none
of its callers ever looked at the result of 'cached'. Remove these
useless arguments.

afs_LookupVCache and afs_GetRootVCache also had the same 'cached'
argument, which was also never used by callers. Remove it for those,
as well.

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

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.

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

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: I54b7ed686bf1fb4c42789e5d251ae76789e9fc88
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>

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__

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

LINUX: Disable kernel fortuna large frame errors

The rand-fortuna.c we get from Heimdal's hcrypto currently sometimes
causes a warning on LINUX when building in the kernel, because
fortuna_reseed() has a (potentially) large stack size:

.../src/libafs/MODLOAD-.../rand-fortuna-kernel.c:549:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Currently this does not cause the build to fail, even with
--enable-checking, since -Werror is not given in the CFLAGS when
building our kernel module. But if -Werror is passed in CFLAGS (in a
future commit), this would cause the build to fail.

Since this is an external source file, we cannot change it directly.
At least for now, just prevent this warning from breaking the build by
passing -Wno-error=frame-larger-than= into the CFLAGS for that file.

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

restorevol: replace snprintf with asprintf

GCC is generating format-truncations warnings. With newer levels of gcc
(e.g. gcc8) and --checking-enabled these warnings result in errors and
failed builds.  In addition clang8 static analysis tools are reporting
memory leaks.

Replace snprintf with asprintf and eliminate some of the large work
buffers that are being placed on the stack. In order to correct some of
the format-truncation errors the size of the buffers grew significantly
(e.g. gcc is reporting the need to resize some of the buffers from 256
bytes to 4K in order to eliminate the warnings).

Ensure allocated work buffers are freed before function return.

Obtained a clean build with gcc9/clang8 with --enable-checking and a
clean scan-build report with clang8.

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

afs: Skip IsDCacheSizeOK for CDirty/VDIR

IsDCacheSizeOK currently can incorrectly flag a dcache as corrupted,
since the size of a dcache may not match the size of the underlying
file in a couple of RW conditions:

- If someone is writing to a file beyond EOF, the intermediate
  'sparse' area may be populated by 0-length dcaches until the data is
  written to the fileserver.

- Directories may be modified locally instead of being fetched from
  the fileserver, which can sometimes result in a directory blob of
  differing sizes.

To avoid false positives detecting dcache corruption, just skip the
IsDCacheSizeOK check for directories, and any file with pending writes
(CDirty).

Also add some extra information to the logging messages when this
"corruption" is detected, so false positives may be more easily
detected in the future.

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

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.

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

LINUX: Avoid re-taking global lock in afs_dentry_iput

“dput” function internally can call dentry_iput which  results in
calling afs_dentry_iput. So in case before calling “dput” if global lock
was held then when afs_dentry_iput is called it will again try to lock
global lock and will result in deadlock scenario.  So to avoid this
deadlock make sure if global lock is already taken before calling
afs_dentry_iput, don’t try to lock it again.  This issue was partially
fixed in commit 0dac4de8 (Linux: drop GLOCK before calling dput)

Change-Id: I71f18c58d5254f0cf0c68ef04c22268ed70dd50f
Reviewed-on: https://gerrit.openafs.org/13725
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

build: fix --enable-rxgk help format

Move the dnl macros out of the AC_ARG_ENABLE to fix the
formatting of the --enable-rxgk help string.

Before this commit:

  $ ./configure --help | grep -C2 rxgk

    --enable-kauth          install the deprecated kauth server, pam modules,
                            and utilities (defaults to disabled)
        --enable-rxgk           Include experimental support for the RXGK security
                            class (defaults to disabled)
    --disable-strip-binaries

After this commit:

  $ ./configure --help | grep -C2 rxgk

    --enable-kauth          install the deprecated kauth server, pam modules,
                            and utilities (defaults to disabled)
    --enable-rxgk           Include experimental support for the RXGK security
                            class (defaults to disabled)
    --disable-strip-binaries

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

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.

Change-Id: I30fbe0971ba3e05dc6ac61e7b2ded2fd1777374d
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>

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.

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

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.

Change-Id: I0c854fd89c0bae1c313ae1f382e58fd410b719e6
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>

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.

Change-Id: Icda0d86444f505604abe9fa1cc2450d7538be7ef
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>

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.

Change-Id: If175d0f95f0ede0f252844086a2a023da5580732
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>

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.

Change-Id: I1c91600fd38b1179f02fa6eadea631b6eb8edb6d
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>

LINUX: Minor osi_vfsop.c cleanup

- Fix the formatting on afs_mount/afs_get_sb definitions

- Declare a couple of functions static that are not referenced outside
  of this file

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

afs: Add AFS_USPC_SHUTDOWN bkg request

When AFS_NEW_BKG was added, the kernel module indicated to the
relevant afsd process that it's time to shutdown by returning -2. This
works on DARWIN, but it's difficult to make this work on all
platforms, because of the different way that platforms handle error
codes from our pioctls and other AFS syscalls.

Specifically, on LINUX, negative error codes are assumed to be
negative errno codes, and so returning -2 from the syscall handler
means we return -1 to userspace, with errno set to 2 (ENOENT).

Getting this to work consistently across platforms is probably more
trouble than its worth, so instead of relying on specific return codes
from the syscall, just add a new background daemon operation called
AFS_USPC_SHUTDOWN, which just tells the background daemon to exit.

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

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'.

Change-Id: Icaa99e278a5d8262caeaec0b2723e826a57554aa
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>

afs: Check dcache size when checking DVs

Currently, if the dcache for a file has nonsensical length (due to
cache corruption or other bugs), we never notice, and we serve
obviously bad data to applications. For example, the vcache metadata
for a file may say the file is 2k bytes long, but the dcache for that
file only has 1k bytes in it (or more commonly, 0 bytes).

This situation is easily detectable, since the dcache and vcache refer
to the same version of the same file (when the DVs match), and so we
can check if the two lengths make sense together. So to avoid giving
bad data to userspace applications, perform a sanity check on the
lengths at the same time we check for DV matches (to see if the dcache
looks "fresh" and not stale). If the lengths do not make sense
together, we just pretend that the dcache is old, and so we'll ignore
it and fetch a new copy from the fileserver.

Also check the size of the data fetched from the fileserver for a
newly-fetched dcache in afs_GetDCache, to avoid returning a bad dcache
if the dcache isn't already present in the cache.

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

LINUX: Unlock page on afs_linux_read_cache errors

When afs_linux_read_cache is called with a non-NULL task, it is
responsible for unlocking 'page' (unless it's unlocked in a background
task), even if we encounter an error. Currently we almost always do
unlock the given page for a non-NULL task, but if we manage to hit one
of the codepaths that 'goto out', we skip over the unlock_page() call
near the end of the function, and the page never gets unlocked.

As a result, the page stays locked forever. That generally means any
future access to the same file will block forever, and when we try to
flush the relevant vcache, we will block waiting for the page lock
while holding GLOCK. (This can happen via the background daemon via
e.g. afs_ShakeLooseVCaches -> osi_TryEvictVCache -> afs_FlushVCache ->
osi_VM_FlushVCache -> vmtruncate -> ... -> truncate_inode_pages_range
-> __lock_page on Linux 2.6.32-754.2.1.el6.) This quickly brings the
whole client to a halt until the machine can be forcibly rebooted.

To solve this, just move the 'out:' label to before the page unlock.
Add a few locking-related comments around the relevant code to help
explain some relevant details.

The relevant code has changed and been refactored over the years, but
this problem has probably existed ever since this code was originally
converted to using the readpage() of the underlying cache fs, in
commit 88a03758 (Use readpage, not read for fastpath access).

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

afs: Introduce afs_IsDCacheFresh

Numerous places in libafs check the DV of a dcache against the DV of
the vcache for the same file, in order to check if the dcache is up to
date and can be used. Consolidate all of these checks into a new
function, afs_IsDCacheFresh, to make it easier for future commits to
alter this logic.

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

Change-Id: Iedc02b0f5d7d0542ab00ff1effdde03c2a851df4
Reviewed-on: https://gerrit.openafs.org/13435
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Andrew Deason <adeason@sinenomine.net>

afscp: Add -l option

Add the -l option to afscp, to "loop" the given FetchData/StoreData
request over and over.

When using this mode, we alternate between using a couple of rx calls,
to avoid getting slowed down by rx BUSY packets when we start a new
call on the same channel too quickly.

Change-Id: I90ee8e9804a0bf59ff654398b1fe6e46a99a3062
Reviewed-on: https://gerrit.openafs.org/13657
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Andrew Deason <adeason@sinenomine.net>