openafs.git
4 months agoLINUX: Include linux/time.h for linux/errqueue.h 50/13950/3
Cheyenne Wills [Wed, 20 Nov 2019 19:43:03 +0000]
LINUX: Include linux/time.h for linux/errqueue.h

The configuration test for errqueue.h fails with an undefined structure
error on a Linux 3.17 (or higher) system.  This prevents setting
HAVE_LINUX_ERRQUEUE_H, which is used to define AFS_RXERRQ_ENV.

Linux commit f24b9be5957b38bb420b838115040dc2031b7d0c (net-timestamp:
extend SCM_TIMESTAMPING ancillary data struct) - which was picked up in
linux 3.17 added a structure that uses the timespec structure.  After
this commit, we need to include linux/time.h to pull in the definition
of the timespec struct.

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

4 months agoubik: Log urecovery_CheckTid-aborted txes 62/13862/3
Andrew Deason [Wed, 11 Sep 2019 21:42:47 +0000]
ubik: Log urecovery_CheckTid-aborted txes

Log when urecovery_CheckTid aborts/ends a running remote transaction.
This is usually a rare event, occurring when some ubik sites get
"stuck" or confused about the state of the quorum. Logging some
details when this happens can be useful when investigating issues
post-mortem, or just to see why a transaction failed.

Change-Id: If0a7cd134aaac3722fe7214a1d8f0efab550ad11
Reviewed-on: https://gerrit.openafs.org/13862
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

4 months agoubik: Introduce ubik_CallRock 87/13987/15
Andrew Deason [Fri, 23 Aug 2019 17:21:54 +0000]
ubik: Introduce ubik_CallRock

In OpenAFS 1.0, the way we made dbserver RPC calls was to pass the
relevant RPC and arguments to ubik_Call()/ubik_Call_New(), which
coerced all of the RPC arguments into 'long's. To make this more
typesafe, in commit 4478d3a9 (ubik-call-sucks-20060703) most callers
were converted to use ubik_RPC_name()-style calls, which used
functions autogenerated by rxgen.

This latter approach, however, only lets us use the ubik_Call-style
site selection code with RPCs processed by rxgen; we can't insert
additional code to run before or after the relevant RPC.

To make our dbserver calls more flexible, but avoid coercing all of
our arguments into 'long's again, move back to the ubik_Call()-style
approach, but use actual typed arguments with a callback function and
a rock. Call it ubik_CallRock().

With this commit rxgen still generates the ubik_RPC_name()-style
stubs, but the stubs just call ubik_CallRock with a generated callback
function, instead of spitting out the equivalent of ubik_Call() in the
generated code itself.

To try to ensure that this commit doesn't incur any unintended extra
changes, make ubik_CallRock consist of the generated code that was
inside rxgen before this commit. This is almost identical to
ubik_Call, but not quite; consolidating these two functions can happen
in a future commit if desired.

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

5 months agoLINUX 5.6: define time_t and use timespec/timespec64 83/14083/7
Cheyenne Wills [Tue, 3 Mar 2020 22:39:49 +0000]
LINUX 5.6: define time_t and use timespec/timespec64

The time_t type and the structure timeval were removed for use in kernel
space code in Linux commits:
    412c53a680a97cb1ae2c0ab60230e193bee86387
        y2038: remove unused time32 interfaces
    c766d1472c70d25ad475cf56042af1652e792b23
        y2038: hide timeval/timespec/itimerval/itimerspec types

Add an autoconf test for the time_t type.

If time_t is missing, define the time_t type when building the kernel
module.

Change the vattr structure in LINUX/osi_vfs.h to use timespec/timespec64
instead of the timeval structure.

Conditionalize the definition of gettimeofday (needed by rand-fortuna.c) in
crypto/hcrypto/kernel/config.h.  It is unused by the Linux kernel module
and the function uses struct timeval that is no longer available.

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

5 months agoLINUX: Avoid building rand-fortuna-kernel.o 84/14084/3
Andrew Deason [Mon, 2 Mar 2020 22:17:55 +0000]
LINUX: Avoid building rand-fortuna-kernel.o

Currently, we build rand-fortuna-kernel.o for libafs on all platforms,
even though we only use the fortuna RNG on AIX, DragonFlyBSD, HP-UX,
and Irix. Everywhere else, our RAND_bytes() in
src/crypto/hcrypto/kernel/rand.c uses osi_readRandom() instead of
going through heimdal.

Building rand-fortuna.c causes occasional build headaches for the
kernel on Linux (see cc7f942, "LINUX: Disable kernel fortuna large
frame errors"). The most recent instance of this is that Linux 5.6
removes the definition for struct timeval, which is referenced in
rand-fortuna.c.

The Linux kernel is constantly changing, and so trying to keep
rand-fortuna.c building on Linux seems like a waste of ongoing effort.
So, just stop building rand-fortuna-kernel.o on Linux. The original
intent of building this file on all platforms was to avoid bitrot, so
still keep building rand-fortuna-kernel.o on all other platforms even
when it's not used; just avoid it on Linux specifically, the platform
that requires the most effort.

To accomplish this, move rand-fortuna-kernel.o from AFSAOBJS to
AFS_OS_OBJS, and remove it from the Linux-only AFSPAGOBJS.

Also remove our configure tests for -Wno-error=frame-larger-than=,
since they're no longer used by anything.

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

5 months agoopr: Introduce opr_cache 84/13884/11
Andrew Deason [Fri, 20 Sep 2019 19:19:23 +0000]
opr: Introduce opr_cache

Add a simple general-purpose in-memory cache implementation, called
opr_cache. Keys and values are simple flat opaque buffers (no complex
nested structures allowed), hashing is done with jhash, and cache
eviction is mostly random with some LRU bias.

Partly based off a different implementation by
mbarbosa@sinenomine.net.

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

5 months agoafs: Properly type afs_osi_suser cred arg 85/14085/3
Andrew Deason [Tue, 14 Jan 2020 16:51:42 +0000]
afs: Properly type afs_osi_suser cred arg

Currently, afs_osi_suser is declared with a void* argument, even
though its only argument is always effectively a afs_ucred_t*. This
allows us to call afs_osi_suser with any pointer type without the
compiler complaining. Currently, some callers call afs_osi_suser with
an incorrectly-typed afs_ucred_t** instead, like so:

    func(afs_ucred_t **credpp)
    {
        afs_ucred_t **acred = *acredpp; /* incorrect assignment */
        if (afs_osi_suser(acred)) {
            /* ... */
        }
    }

The actual code in the tree hides this to some degree behind various
function calls and layers of indirection (e.g. afs_suser()), but this
is effectively what we do. This causes compiler warnings because we
are doing incorrect pointer assignments, but the end result works
because afs_osi_suser actually uses an afs_ucred_t*.

The type confusion makes it very easy to accidentally give the wrong
type to afs_osi_suser. This only really matters on SOLARIS, since that
is the only platform that actually uses its argument to
afs_osi_suser().

To fix all of this, just declare afs_osi_suser as taking an
afs_ucred_t*, and fix all of the relevant functions to handle the
right type.

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

5 months agoLINUX: Initialize CellLRU during osi_Init 93/14093/9
Yadavendra Yadav [Thu, 5 Mar 2020 07:21:55 +0000]
LINUX: Initialize CellLRU during osi_Init

When OpenAFS kernel module gets loaded, it will create certain entries
in "proc" filesystem. One of those entries is "CellServDB", in case
we read "/proc/fs/openafs/CellServDB" without starting "afsd" it will
result in crash with NULL pointer deref. The reason for crash is
CellLRU has not been initialized yet (since "afsd" is not started)
i.e afs_CellInit is not yet called, because of this "next" and "prev"
pointers will be NULL. Inside "c_start()" we do not check for NULL
pointer while traversing CellLRU and this causes crash.

To avoid this initialize CellLRU during module intialization.

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

5 months agoCleanup vestiges of old shared library build directories 45/14045/2
Michael Meffie [Fri, 24 Jan 2020 18:40:28 +0000]
Cleanup vestiges of old shared library build directories

Remove traces of the old shlibrpc and shlibafsauthent build directories,
which are no longer needed since the conversion to libtool for building
shared libraries.

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

5 months agodoc: Replace src/SOURCE-MAP with src/README.md 03/14003/6
Michael Meffie [Thu, 12 Dec 2019 20:58:32 +0000]
doc: Replace src/SOURCE-MAP with src/README.md

Replace the old and poorly maintained "SOURCE-MAP" file with a markdown
formatted README.md file.  Try to organize the directories in sections
to hopefully make a more useful guide to the source code and build
directories.

Thanks to Cheyenne Wills and Benjamin Kaduk for suggestions.

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

5 months agoauth: accept a NULL afsconf_dir in afsconf_SetCellInfo again 61/14061/9
Michael Meffie [Fri, 21 Feb 2020 15:08:42 +0000]
auth: accept a NULL afsconf_dir in afsconf_SetCellInfo again

Commit 93b26c6f55245e2187e574eb928f5e0ce66a245e added the cellservDB
field to the afsconf_dir structure to track the CellServDB pathname.
This commit also changed the afsconf_SetCellInfo() and
afsconf_SetExtendedCellInfo() functions to use the new cellservDB member
to open the CellServDB file.

Unfortunately, the bosserver intentionally calls afsconf_SetCellInfo()
with a NULL afsconf_dir pointer when attempting to create the default
CellServDB and ThisCell files (e.g., "localcell"), which causes the
bosserver to crash on startup when the cell configuration is not present.

Fix this by calling the static function to lookup the CellServDB
pathname when a afsconf_dir data object is not given.

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

5 months agoauth: pass the directory name to _afsconf_CellServDBPath 76/14076/6
Michael Meffie [Thu, 20 Feb 2020 21:09:49 +0000]
auth: pass the directory name to _afsconf_CellServDBPath

Change the signature of the _afsconf_CellServDBPath() static function to
take just the base directory name of the CellServDB file instead of the
entire afsconf_dir data object. This makes it clear we do not need other
members of the afsconf_dir structure to compose the CellServDB path.

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

5 months agoauth: retire writeconfig.c 75/14075/5
Michael Meffie [Thu, 20 Feb 2020 20:58:27 +0000]
auth: retire writeconfig.c

Move the afsconf_SetCellInfo() and afsconf_SetExtendedCellInfo() to the
cellconfig.c file with the other afsconf_dir functions.

Retire the now empty writeconfig.c file.  At one point in the distant
past afsconf_SetCellInfo() did not have a afsconf_dir argument, so it
probably made sense to have a separate file to write the configuration.
Later, the afsconf_dir argument was added to afsconf_SetCellInfo() and
afsconf_SetExtendedInfo() to reset the auth cache, so these functions
are now better placed in cellconfig.c.

Note the contents of writeconfig.c were moved verbatim (including
comments), so this commit should have no functional changes.

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

5 months agoopr: Define opr_mutex_t in lockstub.h 86/13886/7
Andrew Deason [Wed, 2 Oct 2019 20:14:21 +0000]
opr: Define opr_mutex_t in lockstub.h

Like we do for opr_cv_t, define an opr_mutex_t to be a plain int, to
allow opr mutexes to be defined easily without ifdef guards.

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

5 months agoRedHat: support the ppc64le architecture 46/14046/2
Benjamin Kaduk [Sat, 25 Jan 2020 05:42:33 +0000]
RedHat: support the ppc64le architecture

Reported by zhenjiang.cai@powercore.com.cn.

FIXES 135065

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

5 months agoLinux: use override_creds when available 51/13751/4
Jeffrey Hutzelman [Thu, 2 May 2019 20:02:47 +0000]
Linux: use override_creds when available

Linux may perform some access control checks at the time of an I/O
operation, rather than relying solely on checks done when the file is
opened. In some cases (e.g. AppArmor), these checks are done based on
the current tasks's creds at the time of the I/O operation, not those
used when the file was open.

Because of this, we must use override_creds() / revert_creds() to make
sure we are using privileged credentials when performing I/O operations
on cache files. Otherwise, cache I/O operations done in the context of
a task with a restrictive AppArmor profile will fail.

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

5 months agowarn when starting without keys 11/13911/8
Michael Meffie [Fri, 18 Oct 2019 17:43:36 +0000]
warn when starting without keys

The server processes will happily start without keys and then fail all
authenticated access, including database synchronization and local
commands with -localauth.  At least issue warnings to let admins know
the keys are missing and that akeyconvert or asetkey needs to be run.

The situation is not helped by fact the filenames of the key files have
changed between versions. In 1.6.x the (non-DES) keys were in the
rxkad.keytab file and in later versions they are in the KeyFile* files,
so if you are used to 1.6.x it is not obvious what is wrong.

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

5 months agoimprove command-line help for --enable_peer_stats 72/14072/2
Mark Vitale [Wed, 19 Feb 2020 19:48:07 +0000]
improve command-line help for --enable_peer_stats

The command-line help for several OpenAFS servers lists an inaccurate
description for the --enable_peer_stats option:

   "enable RX transport statistics"

Improve the help description to be more clear and consistent with the
description for --enable-process-stats.

Introduced by the following commits:
cd3492d volser: Convert command line parsing to cmd
a5effd9 viced: Use libcmd for command line options
461603e vlserver: Use libcmd for command line parsing
0b9986c ptserver: Use libcmd for command line parsing

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

5 months agoLINUX 5.6: use struct proc_ops for proc_create 63/14063/2
Cheyenne Wills [Tue, 11 Feb 2020 18:29:42 +0000]
LINUX 5.6: use struct proc_ops for proc_create

The Linux commit d56c0d45f0e27f814e87a1676b6bdccccbc252e9
(proc: decouple proc from VFS with "struct proc_ops") was merged into
Linux 5.6rc1.  The commit replaces the 'file_operations' parameter for
proc_create with a new structure 'proc_ops'.

Conditionally initialize and use proc_ops structures instead of
file_operations structures for calls to proc_create.

Notes:
 * proc_ops.proc_ioctl is equivalent to file_operations.unlocked_ioctl
 * The macros HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL are both
   hardcoded to 1 in linux's fs.h
 * proc_ops.compat_ioctl is conditional on Linux's CONFIG_COMPAT macro
   which is a separate test from the HAVE_COMPAT_IOCTL macro

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

5 months agomacos: add anchors to synthetic.conf grep pattern 62/14062/3
Marcio Barbosa [Fri, 7 Feb 2020 17:58:56 +0000]
macos: add anchors to synthetic.conf grep pattern

The grep pattern that checks if /etc/synthetic.conf already has an entry
for afs is intended to check if this file holds a single column entry
named afs. Unfortunately, the current version does not completely
enforce this restriction. To fix this problem, add anchors to the grep
pattern in question.

Change-Id: I15a1fa1c250027b7d3ab67e686cbfbae853251a2
Reviewed-on: https://gerrit.openafs.org/14062
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 months agoafs: silence bogus warning about dcListCount uninitialized 48/14048/3
Mark Vitale [Mon, 27 Jan 2020 01:17:40 +0000]
afs: silence bogus warning about dcListCount uninitialized

Commit 3be5880d1d2a0aef6600047ed43d602949cd5f4d 'afs: Avoid panics in
afs_InvalidateAllSegments' is correct, but at least one compiler (gcc
4.3.4 on SLES 11.3) is fooled into issuing a warning:

    [...]/afs_segments.c: In function 'afs_InvalidateAllSegments_once':
    [...]/afs_segments.c:506: error: 'dcListCount' may be used uninitialized in this function

To silence the bogus warning, initialize dcListCount when defined.

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

6 months agovos: fix name availability check in vos rename 20/13720/5
Michael Meffie [Mon, 22 Jul 2019 19:20:24 +0000]
vos: fix name availability check in vos rename

The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.

The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.

Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed.  The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.

Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.

Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.

Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.

Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.

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

6 months agouss: more gcc9 truncation warning appeasement 49/14049/2
Mark Vitale [Mon, 27 Jan 2020 17:26:41 +0000]
uss: more gcc9 truncation warning appeasement

uss_procs_PickADir needs a larger buffer to avoid a truncation warning.
While here, replace some magic numbers with existing symbols.

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

6 months agotests: skip vos tests when a vlserver is already running 21/14021/5
Michael Meffie [Fri, 10 Jan 2020 15:54:20 +0000]
tests: skip vos tests when a vlserver is already running

The vos tests start a temporary vlserver process, which is problematic
when the local system already has an installed vlserver. Attempt to
temporarily bind a socket to the vlserver port, and if unable to bind
with an EADDRINUSE error, assume the vlserver is already running and
skip these tests.

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

6 months agoafs: Remove osi_VMDirty_p 23/14023/4
Andrew Deason [Thu, 9 Jan 2020 18:28:57 +0000]
afs: Remove osi_VMDirty_p

The function osi_VMDirty_p is mentioned in a few places in src/afs,
but it has always been ifdef'd or commented out, ever since OpenAFS
1.0. Remove the dead code.

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

6 months agoaklog: Make dummy write AIX-specific 22/14022/2
Andrew Deason [Thu, 9 Jan 2020 18:38:45 +0000]
aklog: Make dummy write AIX-specific

This weird write() call exists to work around some old AIX-specific
bug. The ifdef looks like it is intended to restrict this to pre-5
AIX, but it also turns this on for all non-AIX platforms.

Make this area AIX-specific, to avoid this weird write on other
platforms that have nothing to do with the relevant workaround.

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

7 months agotests: do not resolve addresses in vos/vl test 20/14020/3
Michael Meffie [Fri, 10 Jan 2020 14:06:38 +0000]
tests: do not resolve addresses in vos/vl test

The vos-t test adds a set of 10.* test addresses to a test vlserver and
runs vos to read them back.  When the test is run in an environment
where hosts have been assigned in the 10.* internal network, vos will resolve
the addresses to hostnames and the test fails.  Pass the -noresolve
option to vos for this test when checking for the expected list of
addresses.

Example test output before this commit:

    ./vos-t
    ...
    #   seen: 10.0.0.0
    10.0.0.1
    myhost.example.com
    10.0.0.3
    ...
    not ok 5 - vos output matches

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

7 months agoFBSD: Declare vnops/vfsops static 73/13973/4
Andrew Deason [Sun, 1 Dec 2019 21:39:04 +0000]
FBSD: Declare vnops/vfsops static

Declare our vnode and vfs operations as static functions, since they
are not referenced outside of osi_vfsops.c/osi_vnodeops.c. Shuffle
around the definitions in osi_vnodeops.c so that we don't need forward
declarations for the functions.

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

7 months agoFBSD: Remove support for 8.x and 9.x 42/13842/5
Andrew Deason [Sun, 1 Dec 2019 21:27:01 +0000]
FBSD: Remove support for 8.x and 9.x

According to <https://www.freebsd.org/security/unsupported.html>,
FreeBSD 8.x EoL was on August 1, 2015, and FreeBSD 9.x EoL was on
December 31, 2016. Remove our support for these versions, since they
haven't been supported by FreeBSD itself for a while.

FreeBSD 10.x EoL was on October 31, 2018, which has passed, but was
less than a year ago. So keep 10.x in for now.

Adjust our preprocessor checks accordingly:

- In FBSD-specific dirs, assume AFS_FBSD100_ENV and lower is always
  true. Assume __FreeBSD_version is always at least 1000000.

- In non-FBSD dirs, convert AFS_FBSD100_ENV and lower to AFS_FBSD_ENV.

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

7 months agotests: Explicitly build target 'all' by default 93/13993/3
Andrew Deason [Thu, 2 Jan 2020 02:25:05 +0000]
tests: Explicitly build target 'all' by default

Commit 68f40643 (Build tests by default) added new targets in our
top-level Makefile, that caused us to effectively run
'cd tests && make' as part of the default build. Since no explicit
target is provided, 'make' tries to build the first target in the
given Makefile. On some platforms (such as *BSD), 'make' finds the
first defined target as a pattern rule (%.c) from our included
makefiles, and tries to build the target %.c, which it cannot do. This
causes the build to fail with:

    cd tests && make
    make[3]: don't know how to make %.c. Stop

To fix this, just explicitly build the 'all' target when we build our
tests by default.

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

7 months agotests: Stop vlserver on errors 92/13992/3
Andrew Deason [Tue, 31 Dec 2019 18:25:32 +0000]
tests: Stop vlserver on errors

Currently, if we encounter an error and 'goto out' after starting the
test vlserver, we'll exit without stopping the test vlserver. This can
confuse the test harness, causing 'runtests' to hang forever.

To avoid this, move the afstest_StopServer() call to also run when
we're bailing out, but only if the server has actally started of
course.

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

7 months agotests: Introduce afstest_GetProgname 91/13991/2
Andrew Deason [Tue, 31 Dec 2019 18:04:48 +0000]
tests: Introduce afstest_GetProgname

Currently, in tests/volser/vos-t.c we call afs_com_err as
"authname-t", which is clearly a mistake during some code refactoring
(introduced in commit 2ce3fdc5, "tests: Abstract out code to produce a
Ubik client").

We could just change this to "vos-t", but instead of specifying
constant strings everywhere, change this to figure out what the
current command is called, and just use that. Put this code into a new
function, afstest_GetProgname, and convert existing tests to use that
instead of hard-coding the program name given to afs_com_err.

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

7 months agolibtool: Serialize building libfoo.la and libfoo.a 17/14017/2
Andrew Deason [Tue, 7 Jan 2020 19:02:21 +0000]
libtool: Serialize building libfoo.la and libfoo.a

We have a few libraries where we have separate targets to build
libfoo.la (to get libfoo.so) and libfoo.a. Currently, these targets
can be built in parallel, and both are built with libtool. This can
cause problems because of two behaviors with libtool:

- When running --mode=link for libfoo.a or libfoo.la, it effectively
  runs 'rm -rf .libs/libfoo.*' to clean up its work area.

- When running --mode=link for libfoo.a, libtool sets up some scratch
  space in .libs/libfoo.ax to unpack various static libs.

So when 'make libfoo.a' is running, libtool creates a .libs/libfoo.ax
dir, and unpacks various object files inside of it. If while that is
running, 'make libfoo.la' runs, it causes libtool to remove that
directory and all its contents. This causes 'make libfoo.a' to fail
with confusing messages like this (for libafsrpc.a):

    /bin/sh ../../libtool --quiet --mode=link --tag=CC  gcc -static   -O  -o libafsrpc.a [...]
    find: '.libs/libafsrpc.ax/libopr_pic.a': No such file or directory
    ar: .libs/libafsrpc.ax/libfsint_pic.a/afscbint.cs.o: No such file or directory
    make[3]: *** [Makefile:59: libafsrpc.a] Error

To avoid this, prevent building libfoo.la and libfoo.a at the same
time, by just making libfoo.la depend on libfoo.a. Do this for all of
the libraries we build in this way: libafshcrypto, libkopenafs,
libafsauthent, and libafsrpc.

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

7 months agoubik: Introduce ugen_secproc_func 86/13986/3
Andrew Deason [Fri, 1 Nov 2019 20:19:23 +0000]
ubik: Introduce ugen_secproc_func

We currently specify the signature of the 'secproc' function callback
in multiple places. Consolidate them into a single typedef.

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

7 months agodoc: Document new rxgk options 47/13947/6
Andrew Deason [Wed, 9 Oct 2019 18:54:40 +0000]
doc: Document new rxgk options

Commit e5b1e6f1 (Add rxgk client options to vl and pt utilities) added
a couple of new command-line options related to rxgk, but didn't add
them to the relevant man pages.

Add a brief description of these new options to the manpages for pts,
vos, ptserver, and vlserver.

Change-Id: I2d9bfdeb0a31d396740ca2a4d42e14c025b6f79e
Reviewed-on: https://gerrit.openafs.org/13947
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agoafs: Fix EIO error when reading a 4G or larger file 02/14002/3
Cheyenne Wills [Thu, 2 Jan 2020 18:18:16 +0000]
afs: Fix EIO error when reading a 4G or larger file

When reading a file with a file length of >= 4G, the cache manager is
failing the read with an EIO error.

In afs_GetDCache, the call to IsDCacheSizeOK is passed a parameter that
contains only the lower 32bits of the file length (which requires a 64
bit value). This results in the EIO error if the length is over 2^32 -1.

The AFSFetchStatus.Length member needs to be combined with the
AFSFetchStatus.Length_hi to obtain the full 64bit file length.

Fix the calls to IsDCacheSizeOK to use the full 64bit file length.

Commit "afs: Check dcache size when checking DVs
7c60a0fba11dd24494a5f383df8bea5fdbabbdd7" - gerrit 13436 - added the
IsDCacheSizeOK function and the associated calls.

As a note, the AFSFetchStatus.DataVersion is the lower 32 bits of the
full 64bit version number, AFSFetchStatus.dataVersionHigh contains
the high order 32bits.  The function IsDCacheSizeOK is passed just the
32bit component, the only use of the parameter is in an error message.

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

7 months agomacos: add entry for afs into synthetic.conf 28/13928/8
Marcio Barbosa [Sun, 22 Dec 2019 03:56:41 +0000]
macos: add entry for afs into synthetic.conf

The root mount point is read-only as of macOS 10.15. As a result, /afs
cannot be created at this location. To workaround this restriction,
macOS 10.15 provides an alternative way to create mount points at the
root. To make it possible, an entry for the mount point in question must
be added to /etc/synthetic.conf. The synthetic entities described in
this file are not physically present on the disk. Instead, they are
synthesized by the kernel during system boot.

This commit adds an entry for afs into the file mentioned above. Knowing
that this change only takes effect after reboot, also provide directions
to the user during the installation process.

Change-Id: I7a05f4b9a48e443dbaa20a624a92b8b54c510000
Reviewed-on: https://gerrit.openafs.org/13928
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agomacos: add script to notarize OpenAFS 71/13671/9
Marcio Barbosa [Sun, 22 Dec 2019 03:11:57 +0000]
macos: add script to notarize OpenAFS

In order to integrate the notarization process into our existing build
scripts, this patch introduces a script to automatically notarize the
OpenAFS package.

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

7 months agoDo not build shared-only libs for --disable-shared 27/13927/4
Andrew Deason [Wed, 23 Oct 2019 20:46:16 +0000]
Do not build shared-only libs for --disable-shared

Commit 0f1e54c4 (Pass -shared when linking some shared libraries)
changed some of our linking rules to pass -shared to libtool when
linking. When building with the --disable-shared configure option,
this causes those linker rules to fail, since shared libraries are
disabled. Before commit 0f1e54c4, we could build with --disable-shared
successfully.

To allow us to build again with --disable-shared, just don't build the
relevant shared-only libraries at all, when shared libraries are
disabled. To accomplish this, introduce a new substitution variable,
SHARED_ONLY, which allows certain lines in Makefiles to become
commented-out when shared libraries are disabled. Update all of the
shared-only libraries to be built conditionally based on this
variable.

Except for libuafs.la, which appears to be not referenced by anything.
Just remove the rules for that instead.

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

7 months agopts: Use cmd_AddParmAtOffset for common parms 46/13946/5
Andrew Deason [Sat, 26 Oct 2019 00:04:44 +0000]
pts: Use cmd_AddParmAtOffset for common parms

Update pts to use cmd_AddParmAtOffset and symbolic constants for our
common parameters, instead of using bare literals like '16'.

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

7 months agotests: Check if vlserver died during startup 42/13942/2
Andrew Deason [Wed, 30 Oct 2019 01:17:39 +0000]
tests: Check if vlserver died during startup

Currently, the volser/vos test starts a local vlserver to communicate
with. If the vlserver dies during startup, the spawned 'vos'
subprocesses take forever to run, since we need to wait for our Rx
calls to timeout for every operation.

To make it less annoying to detect and investigate errors that might
cause the vlserver to fail during startup, check if the vlserver dies
right away. We already sleep for 5 seconds when starting the vlserver,
so just check if the pid still exists after those 5 seconds.

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

7 months agorx: Make rx_identity_free idempotent 45/13945/3
Andrew Deason [Mon, 9 Sep 2019 19:27:40 +0000]
rx: Make rx_identity_free idempotent

rx_identity_free sets the given identity to NULL, but it
unconditionally derefs the given identity. Make it a no-op for NULL
identities, to make related cleanup code and destructors simpler.

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

7 months agorx: Make rx_opaque_free idempotent 44/13944/2
Andrew Deason [Wed, 21 Aug 2019 17:43:03 +0000]
rx: Make rx_opaque_free idempotent

Currently rx_opaque_free sets the given argument to NULL, a style that
helps prevent double-frees. However, it doesn't check if the given
buffer is already NULL, which makes potential callers that use a 'goto
done'-style cleanup block do something like:

 done:
    if (buf)
        rx_opaque_free(&buf);

To avoid the extra if(), make rx_opaque_free a no-op if it's given a
NULL buffer, similar to how free(NULL) is a no-op on most platforms.

Slightly refactor how we reference our argument as well, to limit the
number of layers of indirection the code needs to deal with.

Do the same for rx_opaque_zeroFree.

Note that there are currently no callers of
rx_opaque_free/rx_opaque_zeroFree, but future commits will add some.

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

7 months agoptserver: Fix WhoIsThisWithName indentation 43/13943/2
Andrew Deason [Tue, 24 Sep 2019 03:43:30 +0000]
ptserver: Fix WhoIsThisWithName indentation

Many lines in this block in WhoIsThisWithName are oddly indented by 1
more space than usual. Fix them.

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

7 months agoBuild tests by default 41/13941/2
Andrew Deason [Tue, 29 Oct 2019 22:22:04 +0000]
Build tests by default

While it's not feasible to run all of our tests by default during the
build, we should be able to at least make sure the tests can build.
So, make the default build targets also build our tests, by making the
'finale' target build the tests.

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

7 months agotests: Fix manpage tests for objdir builds 40/13940/2
Andrew Deason [Tue, 12 Nov 2019 02:34:27 +0000]
tests: Fix manpage tests for objdir builds

The manpage tests have a couple of problems when running for objdir
builds:

- We try to specify './tests-lib/perl5' as a directory to find our
  helper library. However, the cwd when we're running the tests is in
  an objdir build, where the helper library is in the srcdir. Fix this
  by using the SOURCE env var specified by the tests wrapper.

- All of these tests specify the directory in which to find the man
  pages in a subdir of BUILD, but our manpages are located in the src
  dir (since they are built by regen.sh, not by configure/make). Fix
  this by specifying a SOURCE-based directory instead.

To avoid needing to make the same change for each of these tests, also
refactor the manpage tests so each test only needs to specify the
subdirectory and command name, and get rid of some of the common
boilerplate.

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

7 months agomacos: prepare for notarization 70/13670/8
Marcio Barbosa [Tue, 26 Nov 2019 19:41:36 +0000]
macos: prepare for notarization

With the public release of macOS 10.14.5, all new and updated kernel
extensions must be notarized by Apple. To be taken into consideration,
all executables must be signed and the Hardened Runtime capability must
be enabled.

This patch adds the missing prerequisites mentioned above.

Change-Id: I2d3ad66cb7ce062b91d0616955f3bc2b06ca5822
Reviewed-on: https://gerrit.openafs.org/13670
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agomacos: packaging support for MacOS X 10.15 69/13669/7
Marcio Barbosa [Fri, 28 Jun 2019 03:40:55 +0000]
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>

7 months agomacos: add support for MacOS 10.15 68/13668/7
Marcio Barbosa [Mon, 18 Nov 2019 14:34:08 +0000]
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>

7 months agomacos: upgrade *.xib files 35/13935/7
Marcio Barbosa [Fri, 13 Dec 2019 03:03:04 +0000]
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>

7 months agomacos: tell the compiler the system include path 36/13936/9
Marcio Barbosa [Fri, 8 Nov 2019 02:56:13 +0000]
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>

7 months agotests: Fix most tests for objdir builds 39/13939/2
Andrew Deason [Tue, 12 Nov 2019 02:34:07 +0000]
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>

8 months agoFBSD: Remove pre-8 code 12/13812/5
Andrew Deason [Mon, 26 Aug 2019 04:21:23 +0000]
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>

8 months agoafs: Add ppc64le changes in osconf.m4 file. 80/13980/3
Yadavendra Yadav [Fri, 6 Dec 2019 09:53:34 +0000]
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>

8 months agoutil: Use a struct for afsUUID_to_string 31/13831/12
Cheyenne Wills [Mon, 2 Dec 2019 20:12:00 +0000]
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>

8 months agoviced: add opt to allow admin writes on RO servers 07/13707/7
Marcio Barbosa [Thu, 14 Nov 2019 20:29:56 +0000]
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>

8 months agoafs: Skip checking chunkBytes sanity for RW files 69/13969/2
Andrew Deason [Fri, 29 Nov 2019 17:42:47 +0000]
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>

8 months agoviced: prevent writes on readonly fileservers 34/13934/3
Marcio Barbosa [Thu, 14 Nov 2019 04:15:47 +0000]
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>

8 months agosys: retry lsetpag if errno is EINTR 95/12295/5
Marcio Barbosa [Mon, 6 Jun 2016 17:03:54 +0000]
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>

8 months agoafs: afs_pag_wait() makes process unkillable 60/12260/7
Marcio Barbosa [Thu, 7 Nov 2019 03:10:12 +0000]
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>

8 months agoafs: Ensure CDirty is set during afs_write loop 48/13948/3
Andrew Deason [Mon, 18 Nov 2019 02:58:15 +0000]
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>

9 months agoafs: Avoid giving wrong 'tf' to afs_InitVolSlot 33/13933/2
Andrew Deason [Tue, 5 Nov 2019 16:50:01 +0000]
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>

9 months agoafs: Avoid -1 error for vreadUIO/vwriteUIO 31/13931/2
Andrew Deason [Tue, 5 Nov 2019 02:03:43 +0000]
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>

9 months agodoc: Fix realm capitalization 30/13930/2
Andrew Deason [Mon, 4 Nov 2019 22:10:25 +0000]
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>

9 months agoOPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref 15/13915/3
Andrew Deason [Mon, 16 Sep 2019 19:06:53 +0000]
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>

9 months agoOPENAFS-SA-2019-002: Zero all server RPC args 14/13914/2
Andrew Deason [Thu, 8 Aug 2019 02:19:47 +0000]
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>

9 months agoOPENAFS-SA-2019-001: Skip server OUT args on error 13/13913/2
Andrew Deason [Thu, 8 Aug 2019 01:50:47 +0000]
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>

10 months agoLINUX 5.3: Add comments for fallthrough switch cases 81/13881/3
Cheyenne Wills [Tue, 1 Oct 2019 18:14:41 +0000]
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>

10 months agoafs: avoid extra VL_GetEntryByName for .readonly's 34/13334/4
Marcio Barbosa [Thu, 20 Sep 2018 12:44:59 +0000]
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>

10 months agoRedHat: package rxstat_* programs 83/13883/2
Michael Meffie [Tue, 1 Oct 2019 20:16:16 +0000]
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>

10 months agoRedHat: Update makesrpm.pl to use @PACKAGE_VERSION@ instead of @VERSION@ 87/13887/3
Cheyenne Wills [Thu, 3 Oct 2019 16:21:43 +0000]
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>

10 months agorx: Fix test for end of call queue for LWP 80/13880/3
Andrew Deason [Thu, 26 Sep 2019 18:35:51 +0000]
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>

10 months agoviced: consistently enforce host thread quota for ICBS(3) 73/13873/3
Mark Vitale [Tue, 17 Sep 2019 19:14:44 +0000]
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>

10 months agoRetire the AFS_PTR_FMT macro 30/13830/6
Cheyenne Wills [Tue, 24 Sep 2019 21:59:47 +0000]
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>

10 months agoPass -shared when linking some shared libraries 86/13786/6
Andrew Deason [Fri, 16 Aug 2019 17:48:21 +0000]
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>

10 months agoaklog: avoid infinite lifetime tokens by default 28/13828/12
Yadavendra Yadav [Wed, 28 Aug 2019 11:56:41 +0000]
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>

10 months agorx: add missing CLEAR_CALL_QUEUE_LOCK to LWP rx_GetCall 95/13695/3
Mark Vitale [Thu, 18 Jul 2019 02:07:45 +0000]
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>

10 months agoSOLARIS: add autoconfig support for Studio 12.6 67/13867/2
Mark Vitale [Mon, 16 Sep 2019 05:37:33 +0000]
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>

10 months agorx: clear call_queue_lock after removing call from queue 41/13641/4
Mark Vitale [Fri, 15 Mar 2019 03:15:29 +0000]
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>

10 months agoafs: Avoid panics in afs_InvalidateAllSegments 77/13677/3
Andrew Deason [Mon, 8 Jul 2019 19:49:23 +0000]
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>

10 months agoThe interminable rework of afs_random() 59/13759/3
Benjamin Kaduk [Fri, 9 Aug 2019 14:59:44 +0000]
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>

10 months agoaklog: use any enctype in get_credv5 27/13827/8
Yadavendra Yadav [Wed, 28 Aug 2019 11:34:31 +0000]
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>

10 months agoaklog: retry getting tokens for KRB5_KT_NOTFOUND error 26/13826/5
Yadavendra Yadav [Wed, 28 Aug 2019 11:13:35 +0000]
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>

10 months agorx: Introduce rxi_NetSend 17/13717/4
Andrew Deason [Sun, 21 Jul 2019 23:31:53 +0000]
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>

11 months agoaklog: Use HAVE_ENCODE_KRB5_ENC_TKT_PART for aklog impersonate 25/13825/6
Yadavendra Yadav [Wed, 28 Aug 2019 10:55:49 +0000]
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>

11 months agoptserver: Increase length limit of namelist, idlist, prlist, prentries 38/13838/3
Stephan Wiesand [Fri, 6 Sep 2019 11:35:02 +0000]
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>

11 months agoLINUX: Check for -Wno-error=frame-larger-than= 62/13762/3
Andrew Deason [Sat, 10 Aug 2019 03:36:17 +0000]
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>

11 months agovlserver: initialize nvlentry elements after read 55/13755/5
Cheyenne Wills [Fri, 9 Aug 2019 19:25:26 +0000]
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>

11 months agoopr: Include procmgmt_softsig.h for WINNT 24/13824/6
Andrew Deason [Tue, 27 Aug 2019 03:03:23 +0000]
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>

11 months agoaklog: Free client/server princs in get_credv5 61/13761/6
Yadavendra Yadav [Fri, 9 Aug 2019 21:24:38 +0000]
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>

11 months agoafs: Actually free resources during warm shutdown 16/13716/3
Andrew Deason [Sun, 21 Jul 2019 22:02:34 +0000]
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>

11 months agoaklog: free kbr5_creds before returning from rxkad_get_token 60/13760/4
Yadavendra Yadav [Fri, 9 Aug 2019 21:11:01 +0000]
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>

11 months agorx: Convert rx_FreeSQEList to rx_freeServerQueue 11/13811/3
Andrew Deason [Mon, 26 Aug 2019 00:30:30 +0000]
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>

11 months agolibafs: Create debug KMODDIR for FBSD debug inst 90/13690/5
Andrew Deason [Sun, 23 Jun 2019 22:48:53 +0000]
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>

11 months agoxstat: Define AFS_PTHREAD_ENV on WINNT 23/13823/3
Andrew Deason [Tue, 27 Aug 2019 02:17:30 +0000]
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>

11 months agoWINNT: Link tbutc against mtafsutil.lib 22/13822/3
Andrew Deason [Tue, 27 Aug 2019 01:33:58 +0000]
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>

11 months agorx: Export rx_GetCallStatus 20/13820/3
Andrew Deason [Tue, 27 Aug 2019 00:34:19 +0000]
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>

11 months agoWINNT: Do not link ptclient.obj in libafsauthent 19/13819/4
Andrew Deason [Mon, 26 Aug 2019 23:46:21 +0000]
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>

11 months agoWINNT: Link butc against audit 18/13818/3
Andrew Deason [Mon, 26 Aug 2019 23:14:48 +0000]
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>

11 months agoWINNT: Make opr_threadname_set a no-op 17/13817/2
Andrew Deason [Mon, 26 Aug 2019 22:40:56 +0000]
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>