openafs.git
2 months agoRevert "vos: take RO volume offline during convertROtoRW" 39/14339/3
Marcio Barbosa [Mon, 31 Aug 2020 19:56:56 +0000]
Revert "vos: take RO volume offline during convertROtoRW"

This reverts commit 32d35db64061e4102281c235cf693341f9de9271. While that
commit did fix the mentioned problem, depending on "vos" to set the
volume to be converted as "out of service" is not ideal. Instead, this
volume should be set as offline by the SAFSVolConvertROtoRWvolume RPC,
executed on the volume server.

The proper fix for this problem will be introduced by another commit.

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

2 months agobuild: Add rpm target 14/14114/17
Michael Meffie [Mon, 24 Aug 2020 17:12:13 +0000]
build: Add rpm target

Add a top-level makefile target to build RPMs for Red Hat distributions
from the currently checked out commit. The resulting rpms are placed in
the packages/rpmbuild/RPMS/<arch> directory.

The rpm target is intended to be a convenience for testing changes to
the rpm packaging or generating packages for local testing.

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

2 months agomakesrpm: Support custom version strings 16/14116/16
Michael Meffie [Fri, 1 May 2020 18:05:24 +0000]
makesrpm: Support custom version strings

The makesrpm.pl script generates a source RPM by creating a temporary
rpmbuild workspace, populating the SOURCES and SPECS directories in that
workspace, running rpmbuild to build the source RPM, and finally copying
the resulting source RPM out of the temporary workspace.

The name of the source RPM file created by rpmbuild depends on the
package version and release strings. Unfortunately, the format of the
source RPM file name changed around OpenAFS 1.6.0, so makesrpm.pl has
special logic to find the version string and extra code depending on the
detected OpenAFS version.

Instead of trying to predict the name of the resulting source RPM file
from the OpenAFS version string, and having different logic for old
versions of OpenAFS, use a filename glob to find resulting source RPM
file name in the temporary rpmbuild workspace.

Remove the major, minor, and patch level variables, which were only used
to guess the name of the resulting source RPM file name.

Convert '-' characters to '_' in the package version and package
release, since the '-' character is reserved by rpm as a field
separator.

While here, add the --dir option to specify the path of the generated
source RPM, and change the 'srpm' makefile target to use the new --dir
option, instead of changing the current directory before running
makesrpm.pl.  Also, add a dependency on the 'dist' makefile target,
since the the source and document tarballs are required to build the
source RPM.

Add pod documentation and add the --help (-h) option to print a brief
help message, and add the --man option to print the full man page.

With this change, we can build a source RPM even when the .version file
in the src.tar.bz file has a custom format or was created from a
checkout of the master branch or other non-release reference.

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

2 months agoCorrect our contributor's code of conduct 20/14320/2
Stephan Wiesand [Tue, 25 Aug 2020 21:34:39 +0000]
Correct our contributor's code of conduct

There are no races. Racism does exist though.

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

2 months agoUKERNEL: Build linktest with COMMON_CFLAGS 24/14324/3
Andrew Deason [Wed, 26 Aug 2020 20:41:00 +0000]
UKERNEL: Build linktest with COMMON_CFLAGS

Currently, 'linktest' in libuafs is built with a weird custom rule
that specifies several various CFLAGS and LDFLAGS, etc. One
side-effect of this is that linktest is built without specifying -O,
even if optimization is otherwise enabled.

Normally nobody would care about the optimization of linktest, since
it's never supposed to be run, but this can cause an error when
building with -D_FORTIFY_SOURCE=1 on some systems (such as RHEL7):

    In file included from /usr/include/sys/types.h:25:0,
                     from /.../src/config/afsconfig.h:1485,
                     from /.../src/libuafs/linktest.c:15:
    /usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
     #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
        ^
    cc1: all warnings being treated as errors
    make[3]: *** [linktest] Error 1

For now, to fix this just include $(COMMON_CFLAGS) in the flags we
give for linktest, so $(OPTMZ) also gets pulled in, and building
linktest gets a little closer to a normal compilation step.

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

2 months agoptserver: Remove duplicate ubik_SetLock in listSuperGroups 38/14338/3
Jan Iven [Tue, 1 Sep 2020 12:51:25 +0000]
ptserver: Remove duplicate ubik_SetLock in listSuperGroups

It looks like a call to ubik_SetLock(.. LOCKREAD) was left in
place in listSuperGroups after locking was moved to ReadPreamble
in commit a6d64d70 (ptserver: Refactor per-call ubik initialisation)
When compiled with 'supergroups', and once contacted by
"pts mem -expandgroups ..", ptserver will therefore abort() with
Ubik: Internal Error: attempted to take lock twice
This patch removes the superfluous ubik_SetLock.

FIXES 135147

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

3 months agoINSTALL: document the minimum Linux kernel level 05/14305/5
Cheyenne Wills [Mon, 24 Aug 2020 17:10:30 +0000]
INSTALL: document the minimum Linux kernel level

The change associated with gerrit #14300 removed support for older
Linux kernels (2.6.10 and earlier).

The commit 'Import of code from autoconf-archive' (d8205bbb4) introduced
a check for Autoconf 2.64.  Autoconf 2.64 was released in 2009.

The commit 'regen.sh: Use libtoolize -i, and .gitignore generated
build-tools' (a7cc505d3) introduced a dependency on libtool's  '-i'
option.  Libtool supported the '-i' option with libtool 1.9b in 2004.

Update the INSTALL instructions to document a minimum Linux kernel
level and the minimum levels for autoconf and libtool.

Notes: RHEL4 (EOL in 2017) had a 2.6.9 kernel and RHEL5 has a 2.6.18
kernel. RHEL5 has libtool 1.5.22 and autoconf 2.59, RHEL6 has libtool
2.2.6 and autoconf 2.63, and RHEL7 has libtool 2.4.2 and autoconf 2.69.

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

3 months agoafs: Avoid NatPing event on all connection 12/14312/3
Yadavendra Yadav [Thu, 20 Aug 2020 20:24:00 +0000]
afs: Avoid NatPing event on all connection

Inside release_conns_user_server, connection vector is traversed and after
destroying a connection new eligible connection is found on which NatPing
event will be set. Ideally there should be only one connection on which
NatPing should be set but in current code while traversing all connection
of server a NatPing event is set on all connections to that server. In
cases where we have large number of connection to a server this can lead
to huge number of “RX_PACKET_TYPE_VERSION” packets sent to a server.
Since this happen during Garbage collection of user structs, to simulate
this issue below steps were tried

  - had one script which “cd” to a volume mount and then script sleeps for
    large time.
  - Ran one infinite while loop where above script was called using PAG
    based tokens (As new connection will be created for each PAG)
  - Instrumented the code, so that we hit above code segment where NatPing
    event is set. Mainly reduced NOTOKTIMEOUT to 60 sec.

To fix this issue set NatPing on one connection and once it is set break
from “for” loop traversing the server connection.

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

3 months agovos: avoid 'half-locked' volume after interrupted 'vos rename' 57/14157/3
Mark Vitale [Mon, 20 Apr 2020 18:51:08 +0000]
vos: avoid 'half-locked' volume after interrupted 'vos rename'

Reported symptoms:

If a 'vos rename' is interrupted after it has locked the volume and
replaced the VLDB entry, but before it has unlocked the volume, the
volume will remain locked.  However, the locked volume will NOT be
listed as locked in any vos commands that display locked status (see
below for details).

Background:

Most vos write operations lock the VLDB volume entry before proceeding,
then release the volume lock when finished.  This is accomplished via
VL_SetLock and VL_ReleaseLock, respectively.

VL_SetLock always sets these members in the VLDB volume entry:
- flags is modified to set the required VLOP_* code bit as specified
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to the current time

VL_ReleaseLock always sets them as follows:
- flags is cleared of any VLOP_* code bit
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to 0

VL_ReplaceEntry(N) may also optionally clear each of these members:
- flags operation bits may be explicitly cleared via LOCKREL_OPCODE
- LockAFSid may be explicitly cleared via LOCKREL_AFSID
- LockTimestamp may be explicitly cleared via LOCKREL_TIMESTAMP

When all 3 options are specified, VL_ReplaceEntry also does the
functional equivalent of a VL_ReleaseLock.  Most vos operations use this
method.  However, when no lock release options are specified on
VL_ReplaceEntry(N), the VLDB entry is simply replaced with the supplied
entry.  This includes whatever flags values are specified in the
supplied entry; therefore, this amounts to an additional, implicit way
to set or modify the flags.

Root cause:

'vos rename' (UV_RenameVolume) is the only vos operation that does all
of the following things:
- accepts a replacement volume entry that was obtained before VL_SetLock
  (and thus does NOT have any lock flags set)
- issues VL_SetLock (which sets the lock flag in the VLDB)
- issues VL_ReplaceEntry(N) with the original unlocked entry, and with
  no lock release options (thus with explicit intent to leave the lock
  flag unchanged, but inadvertently doing an implicit clear of the lock
  flag in the VLDB)
- (performs some additional volserver work)
- issues VL_ReleaseLock to release the volume lock

Therefore, if 'vos rename' is cancelled or killed before reaching the
final VL_ReleaseLock step, the VLDB entry is left with the lock flags
cleared but the LockTimestamp still set.  As we will see below, this
'half-locked' state produces confusing results from other vos commands.

Detection of locked state:

The 'vos lock' command (and all other vos commands that issue
VL_SetLock) use the lock timestamp to determine if a volume is locked.

However, several other vos commands ('vos listvldb <vol>', 'vos examine
<vol>', 'vos listvldb -locked') use the VLDB entry's lock flags (not the
lock timestamp) to determine if the volume is locked.  Therefore, if the
lock flags have been cleared but the lock timestamp is still set, these
commands fail to detect that the volume is still locked.  Yet an
administrator's 'vos lock <volume>' will still fail with:

  Could not lock VLDB entry for volume <volume>
  VLDB: vldb entry is already locked

This is the external manifestation of the 'half-locked' state.

Workaround and fix:

This scenario has a simple workaround: 'vos unlock <volume>'.  However,
to avoid this confusing outcome in the first place, modify the 'vos
rename' logic so that the lock flags are no longer inadvertently
cleared.  Now, if the 'vos rename' is interrupted before the volume is
unlocked, it will still appear locked in normal vos command output.

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

3 months agorxgen: remove dead code hndle_param_tail 22/14322/2
Mark Vitale [Tue, 25 Aug 2020 16:37:09 +0000]
rxgen: remove dead code hndle_param_tail

Since the original IBM code import, hndle_param_tail has been dead code.
It was later ifdef'd out in commit 8f2df21ffe59
'pull-prototypes-to-head-20020821'

Remove the dead code from the tree.

No functional change is incurred by this commit.

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

3 months agobos: suppress unnecessary warn if -noauth 06/14306/2
Marcio Barbosa [Tue, 18 Aug 2020 13:56:26 +0000]
bos: suppress unnecessary warn if -noauth

Commit d008089a7 (Add interface to select client security objects)
consolidated the code that selects the client security objects into a
set of new interfaces. Before this commit, the "bos: running
unauthenticated" message, which warns the user when an unauthenticated
connection is established, used to be suppressed if the -noauth flag was
specified.

Similarly to commit b3c16324e (ubik: Make ugen_ClientInit honor
noAuthFlag), recover the original behavior avoiding warn messages about
unauthenticated connections if the -noauth flag is provided.

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

3 months agovlserver: fix missing read-only entries from ListAttributesN2 54/14154/7
Michael Meffie [Thu, 16 Apr 2020 20:29:09 +0000]
vlserver: fix missing read-only entries from ListAttributesN2

The ListAttributesN2() RPC can fail to list read-only entries under
certain circumstances. This RPC is used by the `vos listvldb` command to
retrieve vldb entries (unless the -name option is given). The `vos
listvldb` command fails to list volume entries when run with the
'-server' option for volumes that have read-only replicas, but have not
been released.

Consider the following example volume:

    $ vos create fs1.example.com a test
    $ vos addsite fs1.example.com a test
    $ vos addsite fs2.example.com a test
    $ vos listvldb
    ...
    test
        RWrite: 536870921
        number of sites -> 3
           server fs1.example.com partition /vicepa RW Site
           server fs1.example.com partition /vicepa RO Site  -- Not released
           server fs2.example.com partition /vicepa RO Site  -- Not released

`vos listvldb` fails to find the volume when the search is limited to
server 'fs2':

    $ vos listvldb -server fs2.example.com
    VLDB entries for server fs2.example.com
    Total entries: 0

Instead of the expected results:

    $ vos listvldb -server fs2.example.com
    test
        RWrite: 536870921
        number of sites -> 3
           server fs1.example.com partition /vicepa RW Site
           server fs1.example.com partition /vicepa RO Site  -- Not released
           server fs2.example.com partition /vicepa RO Site  -- Not released

This situation makes it difficult to remove old server addresses from
the vldb.  In this situation, 'vos remaddrs' and 'vos changeaddr
-remove' commands will complain the server addresses are still in use by
volume entries, however running 'vos listvldb -server' will not show
which volumes entries are in use.

The entries are not listed for unreleased volumes because the
ListAttributesN2() RPC is currently checking the volume VLF_ROEXISTS
flag, instead of the server site flags (serverFlags) to determine when
the entry is a read-only site. The volume VLF_ROEXISTS flag is set when
a volume is released.

To fix this, make ListAttributesN2 check for the VLSF_ROVOL site flag,
instead of the VLF_ROEXISTS entry flag.

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

3 months agoLINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL 00/14300/7
Cheyenne Wills [Mon, 17 Aug 2020 14:20:11 +0000]
LINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL

Linux-5.9-rc1 commit 'fs: remove the HAVE_UNLOCKED_IOCTL and
HAVE_COMPAT_IOCTL defines' (4e24566a) removed the two referenced macros
from the kernel.

The support for unlocked_ioctl and compat_ioctl were introduced in
Linux 2.6.11.

Remove references to HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL using
the assumption that they were always defined.

Notes:

With this change, building against kernels 2.6.10 and older will fail.
RHEL4 (EOL in March 2017) used a 2.6.9 kernel.  RHEL5 uses a 2.6.18
kernel.

In linux-2.6.33-rc1 the commit messages for "staging: comedi:
Remove check for HAVE_UNLOCKED_IOCTL" (00a1855c) and "Staging: comedi:
remove check for HAVE_COMPAT_IOCTL" (5d7ae225) both state that all new
kernels have support for unlocked_ioctl/compat_ioctl so the checks can
be removed along with removing support for older kernels.

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

3 months agovos: avoid CreateVolume when restoring over an existing volume 08/14208/7
Michael Meffie [Fri, 15 May 2020 16:01:44 +0000]
vos: avoid CreateVolume when restoring over an existing volume

Currently, the UV_RestoreVolume2 function always attempts to create a
new volume, even when doing a incremental restore over an existing
volume.  When the volume already exists, the volume creation operation
fails on the volume server with a VVOLEXISTS error. The client will then
attempt to obtain a transaction on the existing volume. If a transaction
is obtained, the incremental restore operation will proceed. If a full
restore is being done, the existing volume is removed and a new empty
volume is created.

Unfortunately, the failed volume creation is logged to by the volume
server, and so litters the log file with:

    Volser: CreateVolume: Unable to create the volume; aborted, error code 104

To avoid polluting the volume server log with these messages, reverse
the logic in UV_RestoreVolume2. Assume the volume already exists and try
to get the transaction first when doing an incremental restore. Create a
new volume if the transaction cannot be obtained because the volume is
not present.  When doing a full restore, remove the existing volume, if
one exists, and then create a new empty volume.

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

3 months agotests: Accommodate c-tap-harness 4.7 95/14295/5
Michael Meffie [Tue, 4 Aug 2020 14:34:07 +0000]
tests: Accommodate c-tap-harness 4.7

The SOURCE and BUILD environment variables have been changed to
C_TAP_SOURCE and C_TAP_BUILD in the new version of c-tap-harness.  The
runtests command syntax has changed as well.

Convert all of the old SOURCE and BUILD environment variables to the new
C_TAP_SOURCE and C_TAP_BUILD names.

Add the required -l command line option to specify the test list.

Add the new runtests -v option to run the tests in verbose mode to make
it easier to see which tests failed.

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

3 months agoImport of code from c-tap-harness 94/14294/2
Russ Allbery [Tue, 4 Aug 2020 00:59:25 +0000]
Import of code from c-tap-harness

This commit updates the code imported from c-tap-harness to
abdb66561ffd4d2f238fdb06f448ccf09d80c059 (release/4.7)

Upstream changes are:

Daniel Collins (1):
      Add is_blob() test function.

Daniel Kahn Gillmor (1):
      LICENSE: use https for all URLs

Daria Brashear (1):
      Add verbose mode environment variable to runtests

Julien ÉLIE (2):
      Document -v in usage and comments of runtests
      Avoid realloc of zero length in tests/runtests.c

Marc Dionne (1):
      Add test_cleanup_register_with_data

Russ Allbery (115):
      clang --analyze cleanups for runtests
      Modernize POD tests
      Update README to my current layout
      Explicitly note that test programs must be executable
      Fix comment typo in tests/runtests.c
      Switch to a copyright-format 1.0 LICENSE file
      Flush harness output after each line
      Show the test count as ? when the plan is deferred
      More correctly backspace over test counts when aborting
      Refactor test list handling
      Allow passing tests on the runtests command line
      Don't allow command-line arguments if a list was given
      Search for tests under the name given as well
      Release 2.0
      Fix backward incompatibility when searching for tests
      Document decision to ignore TAP version directives
      Release 2.1
      Document different runtests behavior in bail handling
      Change exit status of bail to 255
      Release 2.2
      Add a new test_cleanup_register C API
      Add warn_unused_result attributes
      Add portability for warn_unsed_result attributes to tap/macros.h
      Minor coding style fix (spacing) in runtests.c
      Split the runtests usage string for ISO C90 string limits
      Include stddef.h
      Diagnose failure to register the exit handler
      Use diag internally in the basic C TAP library
      Some additional comments about cleanup functions
      Move repetitive printing code in the C TAP library to a macro
      Set a flag when bailing for more correct cleanup
      Change my email address to eagle@eyrie.org
      Release 2.3
      Add diag_file_add and diag_file_remove functions
      Don't die for unknown files passed to diag_file_remove
      Release 2.4
      Update comment about AIX and WCOREDUMP
      Don't test for NULL before calling free
      Be more careful about file descriptors in child processes
      Run cleanup functions in non-primary processes as well
      Release 3.0
      Update collective package copyright notices at start of LICENSE
      Check integer overflows on memory allocation, fix string creation
      Switch POD spelling test to use Lancaster consensus variable
      Add new bnrealloc API for brealloc with checked multiplication
      Rename nrealloc to reallocarray
      Return the test status from test functions
      Fix the overflow check for breallocarray
      Fix the overflow check for xreallocarray in runtests
      Restructure test result reallocation in runtests
      Change diag and sysdiag to always return true
      Release 3.1
      Fix typos in basic.c and basic.h
      Fix usage message when running runtests with no arguments
      Update introductory runtests comments for current syntax
      Add the -l flag to suggested runtests invocation in README
      Support comments and blank lines in test lists
      Release 3.2
      Update licensing information
      Various improvements to verbose support
      Compile warning-free with Clang, check Autoconf macros
      Release 3.3
      Remove unnecessary assert.h include in tap/basic.c
      Fix some additional -v documentation issues
      Rebalance usage to avoid too-long strings
      Fix segfault in runtests with empty test list
      Release 3.4
      Document running autogen if starting from Git
      Rename autogen to bootstrap
      Support and prefer C_TAP_SOURCE and C_TAP_BUILD
      Fix comment typo in tests/runtests.c
      Add missing va_end to is_double
      Release 4.0
      Fix all non-https www.eyrie.org URLs
      Add is_bool C test function
      Add DocKnot metadata and a Markdown README file
      Update documentation for new DocKnot standards
      Release 4.1
      Use more defaults from DocKnot templates
      Fix new fall-through warning in GCC 7
      Use compiler warnings from rra-c-util, fix issues
      Merge pull request #4 from solemnwarning/master
      Coding style fixes and NEWS for is_blob
      Re-enable -Wunknown-pragmas for GCC
      Avoid zero-length realloc allocations in breallocarray
      Update copyright date on tests/runtests.c
      Release 4.2
      Add SPDX-License-Identifier headers to source files
      Add and run new check-cppcheck target
      Fix instructions for running one test
      Identify values as left and right
      Fix is_string comparisons with NULL pointers
      Add support for running tests under valgrind
      Replace putc with fprintf
      Update shared files from rra-c-util
      Release 4.3
      Update NEWS date for 4.3 release
      Collapse some copyright dates
      NEWS and coding style for test_cleanup_register_with_data
      Remove unused variables caught by Clang scan-build
      Update to rra-c-util 8.0
      Fix error checking in bstrndup
      Release 4.4
      Add support for C++
      Document that C TAP Harness can be built as C++
      Release 4.5
      Regenerate README files
      Reformat using clang-format 10
      Update to rra-c-util 8.1
      Release 4.6
      Fix spelling errors caught by codespell
      Protect the test suite against C_TAP_VERBOSE
      Switch to GitHub Actions for CI
      Add NEWS entry for GCC 10 warning fixes
      Release 4.7

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

3 months agoafs: Always define our own osi_timeval32_t 38/14238/5
Andrew Deason [Tue, 2 Jun 2020 18:37:00 +0000]
afs: Always define our own osi_timeval32_t

Since OpenAFS 1.0, osi_GetTime has taken a timeval-like pointer, which
contains 32-bit fields (the actual type has been called either
osi_timeval_t or osi_timeval32_t over time). For platforms that have a
native timeval-like type with 32-bit fields, we just define
osi_timeval32_t to that type, and elsewhere we define our own struct
to be osi_timeval32_t. For platforms that use the native timeval, we
can then define osi_GetTime() to just be, e.g., microtime().

This approach is difficult to maintain, though, because we must keep
track of whether 'struct timeval' contains 32-bit fields on each
platform, which can depend on many factors. It's easy to make mistakes
(the current tree already contains mistakes), and there's not much
benefit.

To avoid all of this, just always define osi_timeval32_t to be our own
struct with afs_int32 fields, and provide definitions for osi_GetTime
that convert from the native time struct to our osi_timeval32_t. This
does mean that for some platforms we do an unnecessary type
conversion, but this is a small price to pay for more straightforward
and maintainable code.

To be a little more sure that our types are correct, change
osi_GetTime to be defined as an inline function instead of a macro.

At the same time, do a similar conversion for the KERNEL
implementation of the rx clock_GetTime function. Get rid of
platform-specific mess, and do a straightforward type conversion
between osi_timeval32_t and struct clock in an inline function.

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

3 months agoafs: Move osi_GetTime out of param.h 37/14237/3
Andrew Deason [Tue, 2 Jun 2020 18:12:14 +0000]
afs: Move osi_GetTime out of param.h

Most platforms currently #define osi_GetTime in their param.h. This is
really redundant, since the definition of osi_GetTime almost never
changes for a given platform, so we end up with many copies of the
same osi_GetTime definition for a given platform.

Move osi_GetTime out of param.h for these platforms, and define it in
osi_machdep.h instead, which is where most platform-specific
definitions go.

For DFBSD, we don't have an osi_machdep.h at all yet, so create a new
one to contain the osi_GetTime definition. Currently we don't build
libafs at all on DFBSD, but do this anyway so we don't lose the
existing osi_GetTime definition.

For NBSD, we were providing (conflicting!) definitions for osi_GetTime
in param.h and in osi_machdep.h. Just remove the definitions in
param.h, since those should have been getting overridden by the
osi_machdep.h definition.

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

4 months agoafs: Avoid using logical OR when setting f_fsid 92/14292/4
Cheyenne Wills [Mon, 27 Jul 2020 18:31:35 +0000]
afs: Avoid using logical OR when setting f_fsid

Building with clang-10 produces the warning/error message
    warning: converting the result of '<<' to a boolean always evaluates
    to true [-Wtautological-constant-compare]
for the expression
    abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;

The message is because a logical OR '||' is used instead of a bitwise
OR '|'.  The result of this expression will always set the f_fsid
member to a 1 and not the intended value of AFS_VFSMAGIC combined with
AFS_VFSFSID.

Update the expression to use a bitwise OR instead of the logical OR.

Note: This will change value stored in the f_fsid that is returned from
statfs.

Using a logical OR has existed since OpenAFS 1.0 for hpux/solaris and in
UKERNEL since OpenAFS 1.5 with the commit 'UKERNEL: add uafs_statvfs'
b822971a.

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

4 months agoafs: Set AFS_VFSFSID to a numerical value 79/14279/9
Cheyenne Wills [Mon, 27 Jul 2020 18:31:03 +0000]
afs: Set AFS_VFSFSID to a numerical value

Currently when UKERNEL is defined, AFS_VFSFSID is always set to
AFS_MOUNT_AFS, which is a string for many platforms for UKERNEL.

Update src/afs/afs.h to insure that the define for AFS_VFSFSID is a
numeric value when building UKERNEL.

Clean up the preprocessor indentation in src/afs/afs.h in the area
around the AFS_VFSFSID defines.

Thanks to adeason@sinenomine.net for pointing out a much easier solution
for resolving this problem.

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

4 months agoclang-10: ignore fallthrough warning in generated code 75/14275/9
Cheyenne Wills [Thu, 23 Jul 2020 21:43:42 +0000]
clang-10: ignore fallthrough warning in generated code

Clang-10 will not recognize '/* fall through */' as an indicator to
turn off the fallthrough warning due to the lack of a 'break' in a case
statement.

Code generated by flex uses the '/* fall through */' comments to turn
off compiler warnings for fallthroughs in case statements.

For code generated by flex, ignore the implicit-fallthrough via pragma
or disable the warning via a compile time flag.

Add new env variable "CFLAGS_NOIMPLICIT_FALLTHROUGH" to selectively
disable the compile check in Makefiles when checking is enabled.

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

4 months agoclang-10: use AFS_FALLTHROUGH for case fallthrough 74/14274/9
Cheyenne Wills [Mon, 27 Jul 2020 14:33:03 +0000]
clang-10: use AFS_FALLTHROUGH for case fallthrough

Clang-10 will not recognize '/* fallthrough */' as an indicator to
turn off the fallthrough diagnostic due to the lack of a 'break' in a
case statement.  Clang-10 requires the '__attribute__((fallthrough))'
statement to disable the diagnostic.

In addition clang-10 is finding additional locations where fall throughs
occur.

Determine if the compiler supports '__attribute__((fallthrough))' to
disable the implicit fallthrough diagnostic.

Define a new macro 'AFS_FALLTHROUGH' that will disable the fallthrough
diagnostic. Set it as a wrapper for the Linux kernel's 'fallthrough'
macro if available, otherwise set it as a wrapper macro for
'__attribute__((fallthrough))' if the compiler supports it.

Update CODING to document the use of AFS_FALLTHROUGH when needing to
fallthrough between case statements.

Replace the '/* fallthrough */' comments with AFS_FALLTHROUGH, and add
AFS_FALLTHROUGH as needed.

Replace some fallthroughs with a break (or goto) if the flow was was
just to a break (or goto).

e.g.   case x:                 case x:
           somestmt;               somestmt;
                                   break;
       case y:                 case y:
           break;                  break;

Correct a mis-indented brace '}' in src/WINNT/afsd/smb3.c

Note, the clang maintainers have rejected the use of comments as a flag
to turn off the fall through warnings.

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

4 months agoredhat: Add make to the dkms-openafs pre-requirements 66/14266/3
Michael Meffie [Thu, 2 Jul 2020 01:50:09 +0000]
redhat: Add make to the dkms-openafs pre-requirements

If `make` is not installed before dkms-openafs, the OpenAFS kernel
module is not built during the dkms-openafs package installation.

The failure happens in the "checking if linux kernel module build works"
configure step, which invokes `make` to check the linux buildsystem.
configure fails when `make` is not available, and gives the unhelpful
suggestion (in this case) of configuring with --disable-kernel module.

Running the configure.log in the dkms build directory shows:

    configure:7739: checking if linux kernel module build works
    make -C /lib/modules/4.18.0-193.6.3.el8_2.x86_64/build M=/var/lib/dkms/openafs/...
    ./configure: line 7771: make: command not found
    configure: failed using Makefile:

Avoid this build failure by adding `make` to the list of dkms-openafs
package pre-requirements.

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

4 months agovol: Blank opts in VOptDefaults 80/14280/2
Andrew Deason [Fri, 29 May 2020 17:57:50 +0000]
vol: Blank opts in VOptDefaults

Instead of needing to set every single field in the 'opts' structure
individually, blank the whole thing to make sure the entire struct is
initialized. Remove the now-redundant lines that initialize various
items to 0.

Change-Id: I799cdb55becd66a8f3d6ec2f81338843038d0abd
Reviewed-on: https://gerrit.openafs.org/14280
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

4 months agovolser: Don't NUL-pad failed pread()s in dumps 55/14255/3
Andrew Deason [Tue, 23 Jun 2020 03:54:52 +0000]
volser: Don't NUL-pad failed pread()s in dumps

Currently, the volserver SAFSVolDump RPC and the 'voldump' utility
handle short reads from pread() for vnode payloads by padding the
missing data with NUL bytes. That is, if we request 4k of data for our
pread() call, and we only get back 1k of data, we'll write 1k of data
to the volume dump stream followed by 3k of NUL bytes, and log
messages like this:

    1 Volser: DumpFile: Error reading inode 1234 for vnode 5678
    1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960

This can happen if we hit EOF on the underlying file sooner than
expected, or if the OS just responds with fewer bytes than requested
for any reason.

The same code path tries to do the same NUL-padding if pread() returns
an error (for example, EIO), padding the entire e.g. 4k block with
NULs. However, in this case, the "padding" code often doesn't work as
intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k
in this example), like so:

    if (n < howMany)

Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and
so compilers will promote 'n' to the unsigned type, causing this
conditional to fail when n is -1. As a result, all of the relevant log
messages are skipped, and the data in the dumpstream gets corrupted
(we skip a block of data, and our 'howFar' offset goes back by 1). So
this can result in rare silent data corruption in volume dumps, which
can occur during volume releases, moves, etc.

To fix all of this, remove this bizarre NUL-padding behavior in the
volserver. Instead:

- For actual errors from pread(), return an error, like we do for I/O
  errors in most other code paths.

- For short reads, just write out the amount of data we actually read,
  and keep going.

- For premature EOF, treat it like a pread() error, but log a slightly
  different message.

For the 'voldump' utility, the padding behavior can make sense if a
user is trying to recover volume data offline in a disaster recovery
scenario. So for voldump, add a new switch (-pad-errors) to enable the
padding behavior, but change the default behavior to bail out on
errors.

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

4 months agobutc: fix int to float conversion warning 77/14277/6
Cheyenne Wills [Thu, 16 Jul 2020 21:52:00 +0000]
butc: fix int to float conversion warning

Building with clang-10 results in 2 warnings/errors associated with
with trying to convert 0x7fffffff to a floating point value.

    tcmain.c:240:18: error: implicit conversion from 'int' to 'float'
                 changes value from 2147483647 to 2147483648 [-Werror,
                 -Wimplicit-int-float-conversion]
    if ((total > 0x7fffffff) || (total < 0))    /* Don't go over 2G */

and the same conversion warning on the statement on the following line:
    total = 0x7fffffff;

Use floating point and decimal constants instead of the hex constants.

For the test, use 2147483648.0 which is cleanly represented by a float.
Change the comparison in the test from '>' to '>='.

If the total value exceeds 2G, just assign the max value directly to the
return variable.

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

4 months agoautoconf: fix detection for fallthrough attribute 73/14273/5
Cheyenne Wills [Thu, 16 Jul 2020 21:07:15 +0000]
autoconf: fix detection for fallthrough attribute

Due to bug <https://savannah.gnu.org/patch/?9949>,
ax_gcc_func_attribute.m4 fails to properly detect __attribute__((fallthrough))
in clang. Until this is fixed in autoconf-archive upstream, fix our
local copy of ax_gcc_func_attribute.m4, so we can detect
__attribute__((fallthrough)) to make --enable-checking work with clang.

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

4 months agocf: Make local copy of ax_gcc_func_attribute.m4 72/14272/4
Cheyenne Wills [Thu, 16 Jul 2020 21:05:13 +0000]
cf: Make local copy of ax_gcc_func_attribute.m4

Make a local copy of ax_gcc_func_attribute from autoconf-archive. This
is needed in order to fix a bug in the detection of the fallthrough
attribute.

Remove ax_gcc_func_attribute.m4 from src/external/autoconf-archive/m4.
Update LICENSE file to point to the local copy in src/cf.

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

4 months agorx: prevent leakage of non-cached rx_connections (pthread) 42/13042/5
Mark Vitale [Fri, 20 Apr 2018 04:57:28 +0000]
rx: prevent leakage of non-cached rx_connections (pthread)

The rxi_connectionCache (AFS_PTHREAD_ENV only) allows applications to
reuse rx_connection structs.  Cached rx_connections are obtained via
rx_GetCachedConnection and released via rx_ReleaseCachedConnection.
This feature is used most heavily by libadmin and kauth, but there are
other users in the tree as well.

For instance, ubikclient routines ubik_ClientInit and ubik_ClientDestroy
call rx_ReleaseCachedConnections (if AFS_PTHREAD_ENV) when disposing of
their rx_connections.  Unfortunately, in many cases these rx_connections
were obtained via rx_NewConnection, _not_ from the cache via
rx_GetCachedConnection.  In those cases, rx_ReleaseCachedConnection will
not find the rx_connection in the rxi_connectionCache, and thus it
returns without doing anything.

Therefore, when ubik_ClientInit is passed an existing ubik_client (for
re-initialization) that contains rx_connections NOT allocated via
rx_GetCachedConnection, those connections are not destroyed, but will be
silently leaked.  Similarly, ubik_ClientDestroy will leak its
rx_connections when it frees the ubik_client struct.

For example, the fileserver host package calls ubik_ClientInit (via
hpr_Initialize) and ubik_ClientDestroy (via hpr_End) to manage
connections to the ptserver.  However, these connections were obtained
via rx_NewConnection, not rx_GetCachedConnection.  If the fileserver has
a failed call to the ptserver that sets prfail=1, the next RPC scheduled
for that client (in CallPreamble) will refresh the thread's ubik_client
(viced_uclient_key) by calling hprEnd -> ubik_ClientDestroy ->
rx_ReleaseCachedConnection.  The "released" connections will be leaked.

This problem exists in all versions of OpenAFS going back to IBM 1.0.
Starting with 1.8.x, many components that were formerly LWP-only are now
pthreaded and thus susceptible to this leak.

It seems difficult and error-prone to identify all possible code paths
that may pass a non-cached rx_connection to rx_ReleaseCachedConnection,
and convert them to obtain connections via rx_GetCachedConnection.

Instead, prevent all existing and future leaks by modifying the connection
cache to:
- flag all rx_connections it allocates
- correctly release any rx_connection it is passed, whether they came
  from the cache or not.

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

4 months agorx: fix out-of-range value for RX_CONN_NAT_PING 41/13041/4
Mark Vitale [Mon, 30 Apr 2018 22:34:28 +0000]
rx: fix out-of-range value for RX_CONN_NAT_PING

Commit 496fb87372555f6acddd4fd88b03c94c85f48511 ("rx: avoid nat ping
until connection is attached") introduced functionality to defer turning
on NAT ping for server connections until after reachability had been
established for the client.

Unfortunately, this feature could never work correctly because it
assigned an out-of-range flag value of 256 (0x100) for the u_char flags
field. Instead of calling this out as an error, both gcc and Solaris cc
elide this flag so that it is never set in
rx_SetConnSecondsUntilNatPing(), Furthermore, the test in
rxi_ConnClearAttachWait() will always fail; therefore
rxi_ScheduleNatKeepAliveEvent is never called after attach wait has
ended.

Fortunately, this bug is currently moot - not actually exposed in
OpenAFS. (It was discovered by inspection). This is because there are
currently no rx_connection objects in the tree that have both NAT ping
and checkReach (rx_SetCheckReach) enabled. I also searched git history
and found no time when this bug could ever have been exposed. This does
raise the question of why the original commit was needed; but instead of
reverting the original commit, this commit attempts to fix it.

To prevent problems if NAT ping and checkReach are ever both enabled for
an rx_connection, enlarge the rx_connection flags member so that the
RX_CONN_NAT_PING value is no longer out of range.

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

4 months agoauth: Avoid cellconfig.c stdio renaming 14/14214/3
Andrew Deason [Mon, 18 May 2020 17:38:31 +0000]
auth: Avoid cellconfig.c stdio renaming

Since commit 35777145 (solaris-fopen-sucks-20060916), cellconfig.c has
redirected fopen, fclose, and fgets to local functions on
non-64bit-sparc Solaris, in order to work around that platform's stdio
limitations.

Commit 7c431f7571 (auth: retire writeconfig.c) moved the contents of
writeconfig.c into cellconfig.c. The previous writeconfig.c contained
some calls to stdio, including calling fprintf() on a pointer returned
by fopen() in that file.

Because fopen() was redirected to our local version, this means that
afsconf_SetExtendedCellInfo() calls fopen() to get an
afsconf_iobuffer*, and passes that pointer to the real system
fprintf() later on (instead of a native FILE*). The compiler does warn
about this, but this only happens on Solaris, where --enable-checking
is not implemented, so the build never fails.

To avoid this, remove the #defines for fopen, fgets, and fclose.
Instead, change all of the old cellconfig.c callers to explicitly call
afsconf_fopen, afsconf_fgets, and afsconf_fclose. On the affected
Solaris platforms, we keep our local definitions, and for other
platforms, we just make those functions call their system stdio
equivalents. For the code that was pulled in from writeconfig.c,
callers will just call the system fopen, fprintf, and fclose.

We still keep our local afsconf_FILE* definition on all platforms, so
the compiler will still do typechecking for our local afsconf_f*
functions on all platforms. So now if we make a mistake, it should be
a mistake on all platforms, so platforms with --enable-checking should
flag the error.

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

4 months agoafs: Let afs_ShakeLooseVCaches run longer 54/14254/3
Andrew Deason [Fri, 26 Jul 2019 20:28:44 +0000]
afs: Let afs_ShakeLooseVCaches run longer

Currently, when afs_ShakeLooseVCaches runs osi_TryEvictVCache, we
check if osi_TryEvictVCache slept (i.e. dropped afs_xvcache/GLOCK). If
we sleep over 100 times, then we stop trying to evict vcaches and
return.

If we have recently accessed a lot of AFS files, this limitation can
severely reduce our ability to keep our number of vcaches limited to a
reasonable size. For example:

Say a Linux client runs a process that quickly accesses 1 million
files (a simple 'find' command) and then does nothing else. A few
minutes later, afs_ShakeLooseVCaches is run, but since all of the
newly accessed vcaches have dentries attached to them, we will sleep
on each one in order to try to prune the attached dentries. This means
that afs_ShakeLooseVCaches will evict 100 vcaches, and then return,
leaving us with still almost 1 million vcaches. This will happen
repeatedly until afs_ShakeLooseVCaches finally works its way through
all of the vcaches (which takes quite a while, if we only clear 100 at
once), or the dentries get pruned by other means (such as, if Linux
evicts them due to memory pressure).

The limit of 100 sleeps was originally added in commit 29277d96
(newvcache-dont-spin-20060128), but the current effect of it was
largely introduced in commit 9be76c0d (Refactor afs_NewVCache). It
exists to ensure that afs_ShakeLooseVCaches doesn't take forever to
run, but the limit of 100 sleeps may seem quite low, especially if
those 100 sleeps run very quickly.

To avoid the situation described above, instead of limiting
afs_ShakeLooseVCaches based on a fixed number of sleeps, limit it
based on how long we've been running, and set an arbitrary limit of
roughly 3 seconds. Only check how long we've been running after 100
sleeps like before, so we're not constantly checking the time while
running.

Log a new warning if we exit afs_ShakeLooseVCaches prematurely if
we've been running for too long, to help indicate what is going on.

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

4 months agoafs: Skip bulkstat if stat cache looks full 56/13256/4
Andrew Deason [Mon, 16 Jul 2018 21:53:34 +0000]
afs: Skip bulkstat if stat cache looks full

Currently, afs_lookup() will try to prefetch dir entries for normal
dirs via bulkstat whenever multiple pids are reading that dir.
However, if we already have a lot of vcaches, ShakeLooseVCaches may be
struggling to limit the vcaches we already have. Entering
afs_DoBulkStat can make this worse, since we grab afs_xvcache
repeatedly, we may kick out other vcaches, and we'll possibly create
30 new vcaches that may not even be used before they're evicted.

To try to avoid this, skip running afs_DoBulkStat if it looks like the
stat cache is really full.

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

4 months agoafs: Log warning when we detect too many vcaches 55/13255/4
Andrew Deason [Mon, 16 Jul 2018 21:44:14 +0000]
afs: Log warning when we detect too many vcaches

Currently, afs_ShakeLooseVCaches has a kind of warning that is logged
when we fail to free up any vcaches. This information can be useful to
know, since it may be a sign that users are trying to access way more
files than our configured vcache limit, hindering performance as we
constantly try to evict and re-create vcaches for files.

However, the current warning is not clear at all to non-expert users,
and it can only occur for non-dynamic vcaches (which is uncommon these
days).

To improve this, try to make a general determination if it looks like
the stat cache is "stressed", and log a message if so after
afs_ShakeLooseVCaches runs (for all platforms, regardless of dynamic
vcaches). Also try to make the message a little more user-friendly,
and only log it (at most) once per 4 hours.

Determining whether the stat cache looks stressed or not is difficult
and arguably subjective (especially for dynamic vcaches). This commit
draws a few arbitrary lines in the sand to make the decision, so at
least something will be logged in the cases where users are constantly
accessing way more files than our configured vcache limit.

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

4 months agoviced: propagate return from CleanupTimedOutCallBacks_r 56/14256/2
Mark Vitale [Thu, 25 Jun 2020 15:45:19 +0000]
viced: propagate return from CleanupTimedOutCallBacks_r

The fileserver's FiveMinuteCheckLWP periodically calls
CleanupTimedOutCallBacks, and logs an informational messages if the
return code indicates that any callbacks were discarded.

However, since the original IBM code import,  CleanupTimedOutCallBacks
has 1) ignored the return value from CleanupTimedOutCallBacks_r and 2)
unconditionally returned 0.  This makes the informational message
essentially dead code.

Instead, check the code from CleanupTimedOutCallBacks_r and pass it back
to the caller.

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

5 months agoLINUX: Close cacheFp if no ->readpage in fastpath 52/14252/5
Andrew Deason [Fri, 19 Jun 2020 02:16:09 +0000]
LINUX: Close cacheFp if no ->readpage in fastpath

In afs_linux_readpage_fastpath, if we discover that our disk cache fs
has no ->readpage function, we'll 'goto out', but we never close our
cacheFp. To make sure we close it, add a filp_close() call to the
'goto out' cleanup code.

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

5 months agoLINUX: Don't panic on some file open errors 42/14242/9
Cheyenne Wills [Thu, 2 Jul 2020 19:39:27 +0000]
LINUX: Don't panic on some file open errors

Commit 'LINUX: Return NULL for afs_linux_raw_open error' (f6af4a155)
updated afs_linux_raw_open to return NULL on some errors, but still
panics if obtaining the dentry fails.

Commit 'afs: Verify osi_UFSOpen worked' (c6b61a451) updated callers of
osi_UFSOpen to verify whether or not the open was successful.  This
meant osi_UFSOpen (and routines it calls) could pass back an error
indication rather than panic when an error is encountered.

Update afs_linux_raw_open to return a failure instead of panic if unable
to obtain a dentry.

Update osi_UFSOpen to return a NULL instead of panic if unable to obtain
memory or fails to open the file. All callers of osi_UFSOpen handle a
fail return, though some will still issue a panic.

Update afs_linux_readpage_fastpath and afs_linux_readpages to not panic
if afs_linux_raw_open fails.  Instead of panic, return an error.

For testing, an error can be forced by removing a file from the
cache directory.

Note this work is based on a commit by pruiter@sinenomine.net

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

5 months agoafs: Avoid panics on failed return from afs_CFileOpen 41/14241/8
Cheyenne Wills [Fri, 19 Jun 2020 14:01:14 +0000]
afs: Avoid panics on failed return from afs_CFileOpen

afs_CFileOpen is a macro that invokes the open "method" of the
afs_cacheOps structure, and for disk caches the osi_UFSOpen function is
used.

Currently osi_UFSOpen will panic if there is an error encountered while
opening a file.

Prepare to handle osi_UFSOpen function returning a NULL instead of
issuing a panic (future commit).

Update callers of afs_CFileOpen to test for an error and to return an
error instead of issuing a panic.

While this commit eliminates some panics, it does not address some of the
more complex cases associated with errors from afs_CFileOpen.

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

5 months agoLINUX 5.8: use lru_cache_add 49/14249/8
Cheyenne Wills [Thu, 25 Jun 2020 16:43:53 +0000]
LINUX 5.8: use lru_cache_add

With Linux-5.8-rc1 commit 'mm: fold and remove lru_cache_add_anon() and
lru_cache_add_file()' (6058eaec), the lru_cache_add_file function is
removed since it was functionally equivalent to lru_cache_add.

Replace lru_cache_add_file with lru_cache_add.

Introduce a new autoconf test to determine if lru_cache_add is present

For reference, the Linux changes associated with the lru caches:

  __pagevec_lru_add introduced before v2.6.12-rc2

  lru_cache_add_file introduced in v2.6.28-rc1
  __pagevec_lru_add_file replaces __pagevec_lru_add in v2.6.28-rc1
     vmscan: split LRU lists into anon & file sets (4f98a2fee)

  __pagevec_lru_add removed in v5.7 with a note to use lru_cache_add_file
     mm/swap.c: not necessary to export __pagevec_lru_add() (bde07cfc6)

  lru_cache_add_file removed in v5.8
     mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
      (6058eaec)
  lru_cache_add exported
     mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
      (6058eaec)

Openafs will use:
  lru_cache_add on 5.8 kernels
  lru_cache_add_file from 2.6.28 through 5.7 kernels
  __pagevec_lru_add/__pagevec_lru_add_file on pre 2.6.28 kernels

Change-Id: I79ebe4a81425bf8a8a327ddf2d3474aff9df039d
Reviewed-on: https://gerrit.openafs.org/14249
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 months agoRecode a couple files from ISO 8859-1 to UTF-8 65/14265/2
Benjamin Kaduk [Wed, 1 Jul 2020 04:55:45 +0000]
Recode a couple files from ISO 8859-1 to UTF-8

Reported by Debian's lintian(1).
The CellServDB, as an externally maintained file, is left unchanged.

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

5 months agoafs: Bound afs_DoBulkStat dir scan 53/13253/3
Andrew Deason [Sun, 8 Jul 2018 20:00:02 +0000]
afs: Bound afs_DoBulkStat dir scan

Currently, afs_DoBulkStat will scan the entire directory blob, looking
for entries to stat. If all or almost all entries are already stat'd,
we'll scan through the entire directory, doing nontrivial work on
each entry (we grab afs_xvcache, at least). All of this work is pretty
pointless, since the entries are already cached and so we won't do
anything. If many processes are trying to acquire afs_xvcache, this
can contribute to performance issues.

To avoid this, provide a constant bound on the number of entries we'll
search through: nentries * 4. The current arbitrary limits cap
nentries at 30, so this means we're capping the afs_DoBulkStat search
to 120 entries.

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

5 months agoafs: Avoid needless W-locks for afs_FindVCache 56/12656/4
Andrew Deason [Thu, 13 Jul 2017 22:40:36 +0000]
afs: Avoid needless W-locks for afs_FindVCache

The callers of afs_FindVCache must hold at least a read lock on
afs_xvcache; some hold a shared or write lock (and set IS_SLOCK or
IS_WLOCK in the given flags). Two callers (afs_EvalFakeStat_int and
afs_DoBulkStat) currently hold a write lock, but neither of them need
to.

In the optimal case, where afs_FindVCache finds the given vcache, this
means that we unnecessarily hold a write lock on afs_xvcache. This can
impact performance, since afs_xvcache can be a very frequently
accessed lock (a simple operation like afs_PutVCache briefly holds a
read lock, for example).

To avoid this, have afs_DoBulkStat hold a shared lock on afs_xvcache,
upgrading to a write lock when needed. afs_EvalFakeStat_int doesn't
ever need a write lock at all, so just convert it to a read lock.

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

5 months agoutil: Handle serverLogMutex lock across forks 39/14239/8
Kailas Zadbuke [Wed, 3 Jun 2020 10:14:08 +0000]
util: Handle serverLogMutex lock across forks

If a process forks when another thread has serverLogMutex locked, the
child process inherits the locked serverLogMutex. This causes a deadlock
when code in the child process tries to lock serverLogMutex, since we
can never unlock serverLogMutex because the locking thread no longer
exists. This can happen in the salvageserver, since the salvageserver
locks serverLogMutex in different threads, and forks to handle salvage
jobs.

To avoid this deadlock, we register handlers using pthread_atfork()
so that the serverLogMutex will be held during the fork. The fork will
be blocked until the worker thread releases the serverLogMutex. Hence the
serverLogMutex will be held until the fork is complete and it will be
released in the parent and child threads.

Thanks to Yadavendra Yadav(yadayada@in.ibm.com) for working with me
on this issue.

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

5 months agoafs: Split out bulkstat conditions into a function 54/13254/3
Andrew Deason [Mon, 16 Jul 2018 21:08:13 +0000]
afs: Split out bulkstat conditions into a function

Our current if() statement for determining whether we should run
afs_DoBulkStat to prefetch dir entries is a bit large, and grows over
time. Split this logic out into a separate function to make it easier
to maintain, and add some comments to help explain each condition.

This commit should have no visible effects; it's just code
reorganization.

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

5 months agoafs: Change VerifyVCache2 calls to VerifyVCache 55/12655/4
Andrew Deason [Thu, 13 Jul 2017 22:40:21 +0000]
afs: Change VerifyVCache2 calls to VerifyVCache

afs_VerifyVCache is a macro that (on most platforms) effectively
expands to:

    if ((avc->f.states & CStatd)) {
        return 0;
    } else {
        return afs_VerifyVCache2(...);
    }

Some callers call afs_VerifyVCache2 directly, since they already check
for CStatd for other reasons. A few callers currently call
afs_VerifyVCache2, but without guaranteeing that CStatd is not set.
Specifically, in afs_getattr and afs_linux_VerifyVCache, CStatd could
be set while afs_CreateReq drops GLOCK. And in afs_linux_readdir,
CStatd could be cleared at multiple different points before the
VerifyVCache call.

This can result in afs_VerifyVCache2 acquiring a write-lock on the
vcache, even when CStatd is already set, which is an unnecessary
performance hit.

To avoid this, change these call sites to use afs_VerifyVCache instead
of calling afs_VerifyVCache2 directly, which skips the write lock when
CStatd is already set.

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

5 months agoLINUX: replace BUG() call with osi_Panic() in osi_linux_free 50/14250/2
Mark Vitale [Thu, 18 Jun 2020 17:43:35 +0000]
LINUX: replace BUG() call with osi_Panic() in osi_linux_free

If osi_linux_free fails, it printf's an error message, then calls BUG().
This is the sole open-coded call to BUG() in OpenAFS; all other calls
to BUG() are indirect via osi_Panic().

For consistency, eliminate this direct BUG() call by replacing the
printf and BUG() with an equivalent osi_Panic().  This also ensures that
the error messsage is logged as critical, and prefixed with "openafs:".

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

5 months agoLINUX 5.8: do not set name field in backing_dev_info 48/14248/4
Cheyenne Wills [Wed, 17 Jun 2020 00:35:46 +0000]
LINUX 5.8: do not set name field in backing_dev_info

Linux-5.8-rc1 commit 'bdi: remove the name field in struct
backing_dev_info' (1cd925d5838)

Do not set the name field in the backing_dev_info structure if it is
not available. Uses an existing config test
    'STRUCT_BACKING_DEV_INFO_HAS_NAME'

Note the name field in the backing_dev_info structure was added in
Linux-2.6.32

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

5 months agoLINUX 5.8: Replace kernel_setsockopt with new funcs 47/14247/4
Cheyenne Wills [Thu, 18 Jun 2020 22:39:22 +0000]
LINUX 5.8: Replace kernel_setsockopt with new funcs

Linux 5.8-rc1 commit 'net: remove kernel_setsockopt' (5a892ff2facb)
retires the kernel_setsockopt function. In prior kernel commits new
functions (ip_sock_set_*) were added to replace the specific functions
performed by kernel_setsockopt.

Define new config test 'HAVE_IP_SOCK_SET' if the 'ip_sock_set' functions
are available. The config define 'HAVE_KERNEL_SETSOCKOPT' is no longer
set in Linux 5.8.

Create wrapper functions that replace the kernel_setsockopt calls with
calls to the appropriate Linux kernel function(s) (depending on what
functions the kernel supports).

Remove the unused 'kernel_getsockopt' function (used for building with
pre 2.6.19 kernels).

For reference
    Linux 2.6.19 introduced kernel_setsockopt
    Linux 5.8 removed kernel_setsockopt and replaced the functionality
              with a set of new functions (ip_sock_set_*)

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

5 months agotests: Modernize writekeyfile.c 46/14246/4
Andrew Deason [Wed, 17 Jun 2020 17:23:46 +0000]
tests: Modernize writekeyfile.c

tests/auth/writekeyfile.c contains some code used to generate
tests/auth/KeyFile, which is used to test code interpreting the
old-style KeyFile format. This code currently has a few problems:

- We don't check the results of afstest_mkdtemp, which could allow
  symlink attacks from other users on the system.

- We duplicate some logic from afstest_BuildTestConfig, in order to
  build a temporary config dir.

- writekeyfile isn't built or run by default (it only exists to
  generate KeyFile, so it's almost never run), so eventual bitrot is
  quite likely, and the existing code already generates warnings.

To avoid this, change writekeyfile.c to use the existing
afstest_BuildTestConfig to generate a local config dir. To ensure we
avoid bitrot, build writekeyfile by default, and create a test to run
it, to make sure it can generate a KeyFile as expected.

Note that the KeyFile.short we test against is different than the
KeyFile currently in the tree. The existing KeyFile was generated from
an older OpenAFS release, which always generated 100-byte KeyFiles,
even if we only have a few keys. The current codebase only writes out
as much key data as needed, so the generated KeyFiles are shorter (but
still understandable by older OpenAFS releases).

Keep the old 100-byte KeyFile around, since that's what older OpenAFS
would generate, and create a new KeyFile.short to test against, to
make sure our code for generating KeyFiles doesn't change any further.

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

5 months agotests: Use usleep instead of nanosleep 44/14244/5
Cheyenne Wills [Tue, 16 Jun 2020 21:20:20 +0000]
tests: Use usleep instead of nanosleep

Commit "Build tests by default" 68f406436cc21853ff854c514353e7eb607cb6cb
changes the build so tests are always built.

On Solaris 10 the build fails because nanosleep is in librt, which we do
not link against.

Replace nanosleep with usleep.  This avoids introducing extra configure
tests just for Solaris 10.

Note that with Solaris 11 nanosleep was moved from librt to libc, the
standard C library.

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

5 months agotests: Emulate mkdtemp when not available 43/14243/8
Cheyenne Wills [Wed, 17 Jun 2020 19:08:18 +0000]
tests: Emulate mkdtemp when not available

Commit "Build tests by default" 68f406436cc21853ff854c514353e7eb607cb6cb
changes the build so tests are always built.

On Solaris 10 Update 10 and earlier the build fails because the mkdtemp
function is not available.

Introduce a wrapper 'afstest_mkdtemp' that uses mkdtemp if available,
otherwise uses mktemp/mkdir.

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

5 months agomake-release: Run git describe once 50/14150/3
Michael Meffie [Thu, 16 Apr 2020 13:41:41 +0000]
make-release: Run git describe once

Run git describe once at the beginning of make-release to find the
version information used to derive the tarball file names and saved in
the .version file.

This is a cleanup and refactoring change to prepare for a future commit.

Change-Id: I0debeeffa5d2c63ab1498588766cb36424d15cd5
Reviewed-on: https://gerrit.openafs.org/14150
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 agomake-release: Create output directory if needed 15/14115/5
Michael Meffie [Fri, 27 Mar 2020 15:29:24 +0000]
make-release: Create output directory if needed

Automatically create the --dir directory if it does not already exist,
which makes this script slightly easier to use. Remove the now
uneeded mkdir from the top-level makefile.

Change-Id: I1f4561120a70263b0b2b194e65fec55fb5666f40
Reviewed-on: https://gerrit.openafs.org/14115
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 agomake-release: Remove unused optional version argument 49/14149/4
Michael Meffie [Thu, 16 Apr 2020 11:21:51 +0000]
make-release: Remove unused optional version argument

The make-release help shows an optional version argument, but in fact
the version info is always generated from the git tag name argument,
which makes sense when creating releases.

Continue to throw away the second positional argument just in case
someone is still passing a second argument, but issue a warning if they
do.

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

5 months agomake-release: Clean up whitespace and spelling 48/14148/3
Michael Meffie [Thu, 16 Apr 2020 11:37:39 +0000]
make-release: Clean up whitespace and spelling

Fix whitespace errors, convert tabs to spaces, fix spelling errors, and
fix pod markup in the make-release script.

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

6 months agoafs: Remove osi_GetuTime 36/14236/2
Andrew Deason [Tue, 2 Jun 2020 16:12:58 +0000]
afs: Remove osi_GetuTime

osi_GetuTime has always been #define'd to be the same thing as
osi_GetTime, ever since OpenAFS 1.0. Get rid of this redundant macro,
and just use osi_GetTime instead.

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

6 months agoafs/viced: New UAE (unified_afs) error codes 35/14235/2
Jeffrey Altman [Sun, 31 May 2020 17:05:02 +0000]
afs/viced: New UAE (unified_afs) error codes

The following registrations werte submitted to registrar@central.org
as [rt.central.org #135105].

  UAECANCELED, "Operation canceled"            (49733499L)
  UAENOTRECOVERABLE, "State not recoverable"   (49733500L)
  UAENOTSUP, "Not supported"                   (49733501L)
  UAEOTHER, "Other"                            (49733502L)
  UAEOWNERDEAD, "Owner dead"                   (49733503L)
  UAEPROCLIM, "Too many processes"             (49733504L)
  UAEDISCON, "Graceful shutdown in progress"   (49733505L)

Change-Id: I1458b8a9441b3826756ca67af70eee5e835d989f
Reviewed-on: https://gerrit.openafs.org/14235
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

6 months agoutil: Fix segfault in the func ConstructLocalPath 23/14223/3
Cheyenne Wills [Fri, 29 May 2020 16:36:13 +0000]
util: Fix segfault in the func ConstructLocalPath

The function ConstructLocalPath will segfault if passed a NULL for
the command path parameter.

Update ConstructLocalPath to test the passed command path for a NULL
and return ENOENT.

The segfault can be triggered by setting up a BosConfig with a dafs
bnode that does not contain all the required parms.  This setup results
in bosserver segfaulting.  With the fix, bosserver now logs an error and
exits cleanly.

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

6 months agoDARWIN: ensure OpenAFS.pkg is signed 21/14221/3
Mark Vitale [Mon, 11 May 2020 00:53:22 +0000]
DARWIN: ensure OpenAFS.pkg is signed

Installation fails because the OpenAFS.pkg was inadvertently omitted
from the codesign logic.

Ensure that the package is signed.

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

6 months agoDARWIN: ensure PrefPane materials are properly signed 20/14220/3
Mark Vitale [Mon, 11 May 2020 00:51:59 +0000]
DARWIN: ensure PrefPane materials are properly signed

Notarization fails because some prefPane materials were inadvertently
omitted by the codesign logic.

Ensure that these objects are properly signed.

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

6 months agovol: Avoid building devname.c on AFS_NAMEI_ENV 95/13995/4
Andrew Deason [Sat, 21 Dec 2019 03:02:45 +0000]
vol: Avoid building devname.c on AFS_NAMEI_ENV

Everything in devname.c is for the inode vol backend, so skip building
it when AFS_NAMEI_ENV is defined.

While we're doing this, alter the #ifdefs inside this file to assume
that we're not on XBSD, DARWIN, or LINUX, since those platforms are
all namei-only.

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

6 months agovol: Indent ifdef maze in devname.c 94/13994/4
Andrew Deason [Sat, 21 Dec 2019 03:01:13 +0000]
vol: Indent ifdef maze in devname.c

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

6 months agoFBSD: Add support for FreeBSD 12.1 82/13982/5
Tim Creech [Tue, 10 Dec 2019 02:13:58 +0000]
FBSD: Add support for FreeBSD 12.1

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

6 months agoFBSD: Ignore VI_DOOMED vnodes 72/13972/6
Andrew Deason [Mon, 25 Nov 2019 04:36:17 +0000]
FBSD: Ignore VI_DOOMED vnodes

Currently on FreeBSD, osi_TryEvictVCache calls vgone() for our vnode
after checking if the given vcache is in use. vgone() then calls our
VOP_RECLAIM operation, which calls afs_vop_reclaim, which calls
afs_FlushVCache to finally actually flush the vcache.

The current approach has at least the following major issues:

- In afs_vop_reclaim, we return success even if afs_FlushVCache()
  fails. This allows FreeBSD to reuse the vnode for another file, but
  the vnode is still being referenced by our vcache, which is
  referenced by the global VLRU and various other structures. This
  causes all kinds of weird errors, since we try to use the underlying
  vnode for different files.

- After the relevant checks in osi_TryEvictVCache are done, another
  thread can acquire a new reference to our vcache (this can happen
  while vgone() is running up until the vnode is locked). This new
  reference will cause afs_FlushVCache to fail.

- Our afs_vop_reclaim callback is called while the vnode is locked,
  and can acquire afs_xvcache. Other code locks the vnode while
  afs_xvcache is already held (such as afs_PutVCache -> vrele). This
  can lead to deadlocks if two threads try to run these codepaths for
  the same vnode at the same time.

- afs_vop_reclaim optionally acquires afs_xvcache based on the return
  value of CheckLock(&afs_xvcache). However, CheckLock just returns if
  that lock is locked by anyone, not if the current thread holds the
  lock. This can result in the rest of the function running without
  afs_xvcache actually being held if we drop AFS_GLOCK at any point.

- osi_TryEvictVCache() tries to vn_lock() the target vnode, but we may
  already have another vnode locked in the current thread. If the
  vnode we're trying to evict is a descendant of a vnode we already
  have locked, this can deadlock.

To fix these issues, make some changes to how our vcache management
works on FreeBSD:

- Do not allow anyone to hold a new reference on a VI_DOOMED vnode.
  We do this by checking for VI_DOOMED in osi_vnhold, and returning an
  error if VI_DOOMED is set.

- In afs_vop_reclaim, panic if afs_FlushVCache fails. With the new
  VI_DOOMED check, afs_FlushVCache show now never fail; and if it
  somehow does, panic'ing immediately is better than corrupting
  various structures and panic'ing later on.

- Move around some of the relevant locking in afs_vop_reclaim to fix
  the lock-related issues.

- In osi_TryEvictVCache, don't wait for the vnode lock (LK_NOWAIT);
  treat the vnode as "in use" if we can't immediately obtain the lock.

Thanks to tcreech@tcreech.com and kaduk@mit.edu for insight and help
investigating the relevant issues.

FIXES 135041

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

6 months agoDARWIN: remove vestigial etap_event_t typedefs 19/14219/2
Mark Vitale [Mon, 11 May 2020 02:13:13 +0000]
DARWIN: remove vestigial etap_event_t typedefs

These typedefs have been present since commit
a41175cfbbf4d06ccfe14ae54bef8b7464ecd80b
"initial-darwin-support-20010327"; at least some of this material was
obtained directly from IBM after the initial code import.

Based on research of old Darwin source code and kernel documentation,
the Event Trace Analysis Package (ETAP) was a lock-profiling interface
provided in older versions of Mach and xnu.  ETAP was not enabled by
default; the kernel had to be recompiled with certain options to enable
it.  Support for ETAP was removed from the xnu tree sometime between
xnu-517 (10.3 Panther) and xnu-792 (10.4 Tiger), although some
references remain in the latter under PPC support (osfmk/ppc/hw_lock.s).
All remaining references to etap_event_t disappeared when PPC support
was removed, some time between xnu-1456.1.26 (10.6 Snow Leopard) and
xnu-1699.24.8 (10.7.2 Lion).

Therefore, it is possible that these typedefs were needed in the past by
(IBM/Transarc) AFS to support use of some lock APIs (e.g.,
simple_lock_init, usimple_lock_init) after the ETAP code was withdrawn
from xnu.  However, these typedefs have probably always been vestigial
for OpenAFS, because OpenAFS has never used any lock API that took
etap_event_t as an argument.

Regardless, OpenAFS does not need these definitions to build and run on
any currently supported version of macOS.

Remove the vestigial code.

No functional change should be incurred by this commit.

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

6 months agoDARWIN: remove errant typedef for etap_event_t 18/14218/3
Mark Vitale [Mon, 11 May 2020 02:07:39 +0000]
DARWIN: remove errant typedef for etap_event_t

This code has been dead since its introduction, because XAFS_DARWIN_ENV
is a typo for AFS_DARWIN_ENV.

Introduced from day 1 of DARWIN support with commit
a41175cfbbf4d06ccfe14ae54bef8b7464ecd80b
"initial-darwin-support-20010327".

No functional change should be incurred by this commit.

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

6 months agoConvert all osi_timeval_t to osi_timeval32_t 15/14215/5
Mark Vitale [Mon, 18 May 2020 18:19:25 +0000]
Convert all osi_timeval_t to osi_timeval32_t

Since commit 130144850c6d05bc69e06257a5d7219eb98697d8 "xstat: cm xstat
time values are 32 bit", OpenAFS has had two timeval definitions:
osi_timeval_t and osi_timeval32_t.  Since they are functionally
equivalent, convert all references to osi_timeval_t to osi_timeval32_t.
This makes clear that this struct is always expected to contain 32-bit
members for tv_sec and tv_usec.

There are still a few platforms where osi_timeval32_t is mistakenly
defined with 64-bit members; these will be addressed in future commits.

No functional change should be incurred by this commit.

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

6 months agoUKERNEL: remove dead code osi_SetTime 91/14191/7
Mark Vitale [Mon, 4 May 2020 21:35:05 +0000]
UKERNEL: remove dead code osi_SetTime

osi_SetTime has been dead code since the original IBM code import.
Remove it from the tree.

No functional change is incurred by this commit.

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

6 months agoUKERNEL: remove redundant declaration of osi_GetTime 92/14192/7
Mark Vitale [Tue, 5 May 2020 15:26:00 +0000]
UKERNEL: remove redundant declaration of osi_GetTime

Commit c861bb0d779b54236b63eda87d9dfaf7792d1659 "Additional UKERNEL
headers, prototyping and other fixes" added the following lines to
src/rx/rx_prototypes.h:

  #if defined(UKERNEL) && !defined(osi_GetTime)
  extern int osi_GetTime(struct timeval *tv);
  #endif

However, this appears to be redundant with the declaration in
src/afs/afs_prototypes.h:

  #ifdef UKERNEL
  ...
  extern int osi_GetTime(struct timeval *tv);
  ...
  #endif

which was added much earlier with commit
8f2df21ffe59e9aa66219bf24656775b584c122d
"pull-prototypes-to-head-20020821".

Remove the redundant declaration in rx/rx_prototypes.h.

No functional change is incurrred by this commit.

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

6 months agoafs: remove commented xstats externs 97/14197/9
Mark Vitale [Thu, 16 Apr 2020 13:02:00 +0000]
afs: remove commented xstats externs

Extern declarations for the xstats recording areas have been commented
out since 8f2df21ffe59e9aa66219bf24656775b584c122d
"pull-prototypes-to-head-20020821".

Remove the vestigial comments.

No functional change is incurred by this commit.

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

6 months agoafs: remove stats dead code 96/14196/9
Mark Vitale [Sun, 5 Apr 2020 21:10:42 +0000]
afs: remove stats dead code

afs_GetCMSTats, afs_AddToMean, and macro AFS_MEANCNT have been dead code
since the original IBM code import.  Remove them from the tree.

No functional change is incurred by this commit.

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

6 months agoLINUX 5.6: define osi_timeval32_t for 32-bit Linux 16/14216/6
Mark Vitale [Mon, 18 May 2020 21:20:26 +0000]
LINUX 5.6: define osi_timeval32_t for 32-bit Linux

For 32-bit Linux (e.g., arch i586), AFS_LINUX_64BIT_KERNEL is not
defined, so osi_timeval32_t is defined as a typedef of the native
'timeval'.  However, as of commit
c766d1472c70d25ad475cf56042af1652e792b23 "y2038: hide
timeval/timespec/itimerval/itimerspec types" (Linux 5.6), the native
timeval struct is no longer available.  On such a kernel, the OpenAFS
build will fail because osi_timeval32_t is not properly defined.

Instead, add new conditionals to properly define osi_timeval32_t for
this platform.

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

6 months agoafs: Refactor osi_vnhold/AFS_FAST_HOLD 71/13971/6
Andrew Deason [Tue, 19 Nov 2019 05:17:12 +0000]
afs: Refactor osi_vnhold/AFS_FAST_HOLD

Make a few changes to osi_vnhold and AFS_FAST_HOLD:

- Currently, the second argument of osi_vnhold ("retry") is never used
  by any implementation. Get rid of it.

- AFS_FAST_HOLD() is the same as osi_vnhold(). Get rid of
  AFS_FAST_HOLD, and just have all callers use osi_vnhold instead.

- Allow osi_vnhold to return an error, and adjust callers to handle
  it.

- Change osi_vnhold to be a real function, instead of a macro, to make
  nontrivial implementations less cumbersome.

Most platforms never return an error from osi_vnhold(), so the added
code paths to check the return value of osi_vnhold() will not trigger.
However, this lets us add future commits that do make osi_vnhold()
return an error.

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

6 months agovlserver: Return error when growing beyond 2 GiB 80/14180/4
Andrew Deason [Fri, 1 May 2020 20:02:08 +0000]
vlserver: Return error when growing beyond 2 GiB

In the vlserver, when we add a new vlentry or extent block, we grow
the VLDB by doing something like this:

    vital_header.eofPtr += sizeof(item);

Since we don't check for overflow, and all of our offset-related
variables are signed 32-bit integers, this can cause some odd behavior
if we try to grow the database to be over 2 GiB in size.

To avoid this, change the two places in vlserver code that grow the
database to use a new function, grow_eofPtr(), which checks for 31-bit
overflow. If we are about to overflow, log a message and return an
error.

See the following for a specific example of our "odd behavior" when we
overflow the 2 GiB limit in the VLDB:

With 1 extent block, we can create 14509076 vlentries successfully. On
the 14509077th vlentry, we'll attempt to write the entry to offset
2147483560 (0x7FFFFFA8). Since a vlentry is 148 bytes long, we'll
write all the way through offset 2147483707 (0x8000003B), which is
over the 31-bit limit.

In the udisk subsystem, this results in writing to page numbers
2097151, and -2097152 (since our ubik pages are 1k, and going over the
31-bit limit causes us to treat offsets as negative). These pages
start at physical offsets 2147482688 (0x7FFFFC40) and -2147483584
(-0x7FFFFFC0) in our vldb.DB0 (where offset is page*1024+64).

Modifying each of these pages involves reading in the existing page
first, modifying the parts we are changing, and writing it back. This
works just fine for 2097151, but of course fails for -2097152. The
latter fails in DReadBuffer when eventually our pread() fails with
EINVAL, and causes ubik to log the message:

    Ubik: Error reading database file: errno=22

But when DReadBuffer fails, DReadBufferForWrite assumes this is due to
EOF, and just creates a new buffer for the given page (DNewBuffer).
So, the udisk_write() call ultimately succeeds.

When we go to flush the dirty data to disk when committing the
transaction, after we have successfully written the transaction log,
DFlush() fails for the -2097152 page when the pwrite() call eventually
fails with EINVAL, causing ubik to panic, logging the messages:

    Ubik PANIC:
    Writing Ubik DB modifications

When the vlserver gets restarted by bosserver, we then process the
transaction log, and perform the operations in the log before starting
up (ReplayLog). The log records the actual data we wrote, not split
into pages, and the log-replaying code writes directly to the db
usying uphys_write instead of udisk_write. So, because of this, the
write actually succeeds when replaying the log, since we just write
148 bytes to offset 2147483624 (0x7FFFFFE8), and no negative offsets
are used.

The vlserver will then be able to run, but will be unable to read that
newly-created vlentry, since it involves reading a ubik page beyond
the 31-bit boundary. That means trying to lookup that entry will fail
with i/o errors, and as well as any entry on the same hash chains as
the new entry (since the new entry will be added to the head of the
hash chain). Listing all entries in the database will also just show
an empty database, since our vital_header.eofPtr will be negative, and
we determine EOF by comparing our current blockindex to the value in
eofPtr.

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

6 months agovol: Fix format-truncation warning with gcc-10.1 07/14207/2
Cheyenne Wills [Mon, 11 May 2020 20:06:19 +0000]
vol: Fix format-truncation warning with gcc-10.1

Building with gcc-10.1 produces a warning (error if --enable-checking)
in vol-salvage.c

error: ‘%s’ directive output may be truncated writing up to 755 bytes
       into a region of size 255 [-Werror=format-truncation=]
  809 |     snprintf(inodeListPath, 255, "%s" OS_DIRSEP "salvage.inodes.%s.%d", tdir, name,

Use strdup/asprintf to allocate the buffer dynamically instead of using
a buffer with a hardcoded size.

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

6 months agoauth: Close fd on SetExtendedCellInfo write error 13/14213/2
Andrew Deason [Mon, 18 May 2020 17:09:38 +0000]
auth: Close fd on SetExtendedCellInfo write error

Currently, and since OpenAFS 1.0, if write() fails here, we leak the
file descriptor. A write() failure should be very unlikely, but close
the fd to make sure we avoid the leak.

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

6 months agoafs: Free rx/rxevent resources during shutdown 19/13719/4
Andrew Deason [Sun, 21 Jul 2019 23:55:49 +0000]
afs: Free rx/rxevent resources during shutdown

Call shutdown_rx() and shutdown_rxevent() near the end of our shutdown
sequence, in order to free various Rx resources and avoid memory
leaks.

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

6 months agoLINUX-5.7: replace __pagevec_lru_add with lru_cache_add_file 59/14159/8
Cheyenne Wills [Thu, 30 Apr 2020 16:31:17 +0000]
LINUX-5.7: replace __pagevec_lru_add with lru_cache_add_file

The Linux function __pagevec_lru_add is no longer exported in Linux
5.7-rc1 commit bde07cfc65da5fe6c63fe23f035f5ccc0ffd89e0
"mm/swap.c: not necessary to export __pagevec_lru_add()".

As a replacement, the Linux function lru_cache_add_file can be used for
adding a page to the lru cache.  The internal processing of
lru_cache_add_file manages its own internal pagevec and performs the
following:
     get_page(...)
     if(!pagevec_add(...))
        __pagevec_lru_add_file(...)

Introduce an autoconf test for lru_cache_add_file and replace the calls
associated with __pagevec_lru_add with lru_cache_add_file.

NOTE: see Linux commit a0b8cab3b9b2efadabdcff264c450ca515e2619c
"mm: remove lru parameter from __pagevec_lru_add and remove parts of
pagevec API" as a reference for this change.

The lru_cache_add_file was introduced in Linux 2.6.28, therefore this
change affects systems with Linux 2.6.28 kernels and later.

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

6 months agolibafs: Abstract the Linux lru cache interface 67/14167/5
Cheyenne Wills [Wed, 29 Apr 2020 22:26:02 +0000]
libafs: Abstract the Linux lru cache interface

Define static functions afs_lru_cache_init, afs_lru_cache_add and
afs_lru_cache_finalize to handle interfacing with Linux's lru
facilities.

This change's primary purpose is to isolate the preprocessor
conditionals associated with the details of the system lru interfaces to
just these functions and to simplify the areas that utilize lru caching
by removing the preprocessor conditionals.

As Linux's lru facilities change, additional conditional code will be
needed.

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

6 months agoafs: Drop GLOCK for RXAFS_GetCapabilities 81/14181/2
Andrew Deason [Sun, 3 May 2020 04:54:55 +0000]
afs: Drop GLOCK for RXAFS_GetCapabilities

We are hitting the net here; we certainly should not be holding
AFS_GLOCK while waiting for the server's response.

Found via FreeBSD WITNESS.

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

6 months agorxkad: Use krb5_enctype_keysize in tkt_DecodeTicket5 03/14203/5
Yadavendra Yadav [Wed, 29 Apr 2020 05:10:05 +0000]
rxkad: Use krb5_enctype_keysize in tkt_DecodeTicket5

Inside tkt_DecodeTicket5 (rxkad/ticket5.c) function, keysize is calculated
using krb5_enctype_keybits and then dividing number of bits by 8. For 3DES
number of keybits are 168, so keysize comes out to 21(168/8). However
actual keysize of 3DES key is 24. This keysize is passed to
_afsconf_GetRxkadKrb5Key where keysize comparison happens, since there is
keysize mismatch it returns AFSCONF_BADKEY.

To fix this issue get keysize from krb5_enctype_keysize function instead
of krb5_enctype_keybits. Thanks to John Janosik (jpjanosi@us.ibm.com)
for analyzing and fixing this issue.

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

6 months agorx: Avoid osi_NetSend during rx shutdown 18/13718/6
Andrew Deason [Sun, 21 Jul 2019 23:48:51 +0000]
rx: Avoid osi_NetSend during rx shutdown

Commit 8d939c08 (rx: avoid nat ping during shutdown) added a call
to shutdown_rx() inside the DARWIN shutdown sequence, before the rx
socket was closed. From the commit message, it sounds like this was
done to avoid NAT pings from calling osi_NetSend during the shutdown
sequence after the rx socket was closed; calling shutdown_rx() before
closing the socket would cause any connections we had to be destroyed
first, avoiding that.

The problem with this is that this means shutdown_rx() is called when
osi_StopNetIfPoller is called, which is much earlier than some other
portions of the shutdown sequence; some of which may hold references
to e.g. rx connections. If we try to, for instance, destroy an rx
connection after shutdown_rx() is called, we could panic.

An earlier version of that commit (gerrit PS1) just tried to insert a
check before the relevant osi_NetSend call, making us just skip the
osi_NetSend if the shutdown sequence had been started. So to avoid the
above issue, try to implement that approach instead. And instead of
doing it just for NAT pings, we can do it for almost all osi_NetSend
calls (besides those involved in the shutdown sequence itself), by
checking this in rxi_NetSend. Also return an error (ESHUTDOWN) if we
skip the osi_NetSend call, so we're not completely silent about doing
so.

This means we also remove the call to shutdown_rx() inside DARWIN's
osi_StopNetIfPoller(). This allows us to interact with Rx objects
during more of the shutdown process in cross-platform code.

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

6 months agoAdd more 'fall through' switch comments 25/14125/16
Cheyenne Wills [Fri, 3 Apr 2020 21:00:42 +0000]
Add more 'fall through' switch comments

Commit a455452d (LINUX 5.3: Add comments for fallthrough switch cases)
added the special /* fall through */ comment to various switch/case
blocks, in order to avoid implicit-fallthrough warnings from causing
the build to fail when building the Linux kernel module.

In this commit, add additional /* fall through */ comments to the rest
of the tree where falling through is intentional. Add a "break;" in one
place in dumptool.c where falling through seems like a mistake, and flag
certain functions as AFS_NORETURN to avoid needing to explicitly break
or fallthrough.

Check for the availability of the -Wimplicit-fallthrough compiler flag
and use it when --enable-checking is set, to prevent additional cases
from creeping into the tree.

Note: the -Wimplicit-fallthrough compiler flag was added in gcc 7.

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

6 months agosalvaged: Fix "-parallel all<number>" parsing 01/14201/5
Kailas Zadbuke [Fri, 8 May 2020 03:55:39 +0000]
salvaged: Fix "-parallel all<number>" parsing

In salavageserver -parallel option takes "all<number>" argument.
However the code does not parse the numeric part correctly. Due
to this, only single instance of salvageserver process was running
even if we provide the larger number with "all" argument.

With this fix, numeric part of "all" argument will be parsed
correctly and will start required number of salvageserver instances.

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

6 months agocf: Use common macro to test compiler flags 32/14132/7
Cheyenne Wills [Sun, 5 Apr 2020 21:51:17 +0000]
cf: Use common macro to test compiler flags

Use the AX_APPEND_COMPILE_FLAGS macro to test and set compiler
specific flags.

Remove the OPENAFS_GCC_SUPPORTS_MARCH check entirely (and the
associated P5PLUS_KOPTS), since nothing has used it for quite some
time.

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

6 months agoubik: Avoid unlinking garbage during recovery 53/14153/3
Andrew Deason [Mon, 20 Apr 2020 18:03:15 +0000]
ubik: Avoid unlinking garbage during recovery

In urecovery_Interact, if any of our operations fail around
calling DISK_GetFile, we will jump to FetchEndCall and eventually
unlink 'pbuffer'. But if we failed before opening our .DB0.TMP file,
the contents of 'pbuffer' will not be initialized yet.

During most iterations of the recovery loop, the contents of 'pbuffer'
will be filled in from previous loops, and it should always stay the
same, so it's not a big problem. But if this is the first iteration of
the loop, the contents of 'pbuffer' may be stack garbage.

Solve this in two ways. To make sure we don't use garbage contents in
'pbuffer', memset the whole thing to zeroes at the beginning of
urecovery_Interact(). And then to make sure we're not reusing
'pbuffer' contents from previous iterations of the loop, also clear
the first character to NUL each time we arrive at this area of the
recovery code. And avoid unlinking anything if pbuffer starts with a
NUL.

Commit 44e80643 (ubik: Avoid unlinking garbage) fixes the same issue,
but only fixed it in the SDISK_SendFile codepath in remote.c.

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

6 months agoUse autoconf-archive m4 from src/external 35/14135/5
Andrew Deason [Sun, 5 Apr 2020 03:35:07 +0000]
Use autoconf-archive m4 from src/external

Switch to using the m4 macros from autoconf-archive in our
src/external mechanism, instead of manually-copied versions in src/cf.
The src/external copy of ax_gcc_func_attribute.m4 is identical to the
existing copy in src/cf, so that should incur no changes. There are
also a few new macros pulled in, but they are currently unused.

Increase our AC_PREREQ in configure.ac to 2.64, to match the AC_PREREQ
in some of the new files.

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

6 months agoImport of code from autoconf-archive 38/14138/3
Autoconf Archive Maintainers [Tue, 7 Apr 2020 15:23:16 +0000]
Import of code from autoconf-archive

This commit updates the code imported from autoconf-archive to
24358c8c5ca679949ef522964d94e4d1cd1f941a (v2019.01.06)

New files are:
m4/ax_append_compile_flags.m4
m4/ax_append_flag.m4
m4/ax_check_compile_flag.m4
m4/ax_gcc_func_attribute.m4
m4/ax_require_defined.m4

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

6 months agoAdd autoconf-archive to src/external 33/14133/4
Andrew Deason [Sun, 5 Apr 2020 03:28:21 +0000]
Add autoconf-archive to src/external

Add autoconf-archive to the src/external mechanism, so we can more
easily import and update the AX_* m4 macros we pull in from
autoconf-archive. Commits are imported from
<git://git.savannah.gnu.org/autoconf-archive.git>.

We already have a copy of ax_gcc_func_attribute.m4 in the tree, so
include that in the list of files. While we're here, also include a
few more macros for checking compiler flags, which will be used in
subsequent commits.

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

6 months agoUpdate NEWS for OpenAFS 1.9.0 73/13673/9
Michael Meffie [Fri, 5 Jul 2019 13:28:50 +0000]
Update NEWS for OpenAFS 1.9.0

Add change descriptions for commits not in a stable release.

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

6 months agoSynchronize NEWS with 1.8.5 03/14103/2
Benjamin Kaduk [Fri, 20 Mar 2020 16:17:13 +0000]
Synchronize NEWS with 1.8.5

Pull in all the updates to NEWS that occurred on the 1.8.x branch
in preparation for adding entries for 1.9.0.

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

7 months agorx: Use _IsLast to check for last call in queue 58/14158/2
Andrew Deason [Sun, 26 Apr 2020 22:26:02 +0000]
rx: Use _IsLast to check for last call in queue

Ever since commits 170dbb3c (rx: Use opr queues) and d9fc4890 (rx: Fix
test for end of call queue for LWP), rx_GetCall checks if the current
call is the last one on rx_incomingCallQueue by doing this:

    opr_queue_IsEnd(&rx_incomingCallQueue, cursor)

But opr_queue_IsEnd checks if the given pointer is the _end_ of the
last; that is, if it's the end-of-list sentinel, not an item on the
actual list. Testing for the last item in a list is what
opr_queue_IsLast is for. This is the same convention that the old Rx
queues used, but 170dbb3c just accidentally replaced queue_IsLast with
opr_queue_IsEnd (instead of opr_queue_IsLast), and d9fc4890 copied the
mistake.

So because this is inside an opr_queue_Scan loop, opr_queue_IsEnd will
never be true, so we'll never enter this block of code (unless we are
the "fcfs" thread). This means that an incoming Rx call can get stuck
in the incoming call queue, if all of the following are true:

 - The incoming call consists of more than 1 packet of incoming data.

 - The incoming call "waits" when it comes in (that is, there are no
   free threads or the service is over quota).

 - The "fcfs" thread doesn't scan the incoming call queue (because it
   is idle when the call comes in, but the relevant service is over
   quota).

To fix this, just use opr_queue_IsLast here instead of
opr_queue_IsEnd.

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

7 months agotests: Give more leeway in rx/event-t 60/14160/2
Andrew Deason [Sat, 25 Apr 2020 23:21:10 +0000]
tests: Give more leeway in rx/event-t

Currently, the rx/event-t tests schedule a bunch of events up to 3
seconds in the future, and then we sleep for 3 seconds to give them a
chance to run. Since we're cutting it so close, this can rarely result
in a few events not being run (observed occasionally on FreeBSD 12.1,
where we failed to run about 3 events out of 10000).

To avoid this, just sleep for 4 seconds instead of 3. Also print out a
little more info regarding the number of fired/cancelled events, so we
can see the event count when it's wrong.

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

7 months agoafs: fix afs_linux_mmap fstrace entry 68/14168/2
Mark Vitale [Thu, 23 Apr 2020 21:49:20 +0000]
afs: fix afs_linux_mmap fstrace entry

The format string for CM_TRACE_GMAP takes 4 substitutions, but
afs_linux_mmap only supplies 3.  This results in malformed output from
fstrace:

Type mismatch, using raw print.
Gn_map vp 0x%lx addr 0x%lx len 0x%x off 0x%x (afs / zcm)raw op
701087775, time 715.322573, pid 9644
p0:0xc0a66ec0 p1:0x8b81a000 p2:131072

Repair the recording of CM_TRACE_GMAP.

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

7 months agotests: Skip SIGBUS test on FreeBSD 45/14145/3
Andrew Deason [Mon, 13 Apr 2020 03:28:29 +0000]
tests: Skip SIGBUS test on FreeBSD

Currently, 'softsig-helper -buserror' causes a SIGBUS on most
platforms, but can result in SIGSEGV on FreeBSD by default (at least
on 11.3-RELEASE). Skip the test on FreeBSD, until we can provide a
more reliable way to generate SIGBUS.

Note that when the sysctl machdep.prot_fault_translation is set to 1,
'softsig-helper -buserror' generates a SIGBUS instead of SIGSEGV,
suggesting that generating a SIGBUS here is the old 'compat' behavior.
When machdep.prot_fault_translation is 0 (the default), the code path
in the FreeBSD kernel that dictates whether to send a SIGBUS or
SIGSEGV in this situation depends on some autodetection heuristics,
and so may produce different results depending on FreeBSD releases or
even compiler settings (due to detection of ABI based on some ELF
notes in the relevant binary).

For some details on this sysctl, see
<https://www.freebsd.org/news/status/report-2019-07-2019-09.html#Signals-delivered-on-unhandled-Page-Faults>
or the FreeBSD source code. In 11.3-RELEASE, the decision to issue a
SIGBUS or SIGSEGV can be found around sys/amd64/amd64/trap.c:355.

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

7 months agoFBSD: Avoid holding AFS_GLOCK during vinvalbuf 70/13970/5
Andrew Deason [Wed, 27 Nov 2019 05:39:24 +0000]
FBSD: Avoid holding AFS_GLOCK during vinvalbuf

Currently we call vinvalbuf(9) in a few places while holding
AFS_GLOCK, but AFS_GLOCK is a non-sleepable lock (struct mtx), and
vinvalbuf can sleep. This can trigger a panic in some rare conditions,
with the message:

    Sleeping thread (tid 100179, pid 95481) owns a non-sleepable lock

To avoid this, drop AFS_GLOCK around a few places that call
vinvalbuf().

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

7 months agoafs: Fix ifdef indenting in afs_vcache.c 77/13877/5
Andrew Deason [Mon, 16 Sep 2019 04:00:26 +0000]
afs: Fix ifdef indenting in afs_vcache.c

Change-Id: Ib566156184cb3f64a0983babd5d9f7883c84cc85
Reviewed-on: https://gerrit.openafs.org/13877
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agoFBSD: Remove MA_* abstractions 43/13843/6
Andrew Deason [Sun, 8 Sep 2019 21:10:40 +0000]
FBSD: Remove MA_* abstractions

In FBSD/osi_vnops.c, we have a few abstractions (e.g. MA_VOP_UNLOCK)
that used to expand to different things for older FreeBSD versions.
Currently, they always expand to the same thing, so just remove the
abstractions.

While we are changing these calls, also change one instance of
MA_VOP_LOCK to vn_lock (instead of VOP_LOCK), since we're not usually
supposed to call VOP_LOCK directly, according to the VOP_LOCK(9)
manpage. The MA_VOP_LOCK call was added in commit bd707fb7
(freebsd-almost-working-client-20020216), seemingly by mistake.

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

7 months agoFBSD: Build vnode_if.h before libafs objs 83/13983/3
Tim Creech [Sat, 14 Dec 2019 03:24:57 +0000]
FBSD: Build vnode_if.h before libafs objs

Currently, if we are building with -j2 or higher, we can easily fail
to build some libafs objects because vnode_if.h does not exist yet.
vnode_if.h is generated by the FreeBSD build, but none of our objects
depend on it, so during parallel builds it may not be available by the
time we build, for example, src/external/heimdal/hcrypto/sha256.c.

This results in build errors that can look like this:

    --- sha256-kernel.o ---
cc -I. -I.. -I../nfs [...]/src/external/heimdal/hcrypto/sha256.c
    In file included from [...]/src/external/heimdal/hcrypto/sha256.c:34:
    In file included from [...]/src/crypto/hcrypto/kernel/config.h:30:
    In file included from [...]/src/afs/sysincludes.h:354:
    /usr/src/sys/sys/vnode.h:588:10: fatal error: 'vnode_if.h' file not found
    #include "vnode_if.h"
             ^~~~~~~~~~~~
    1 error generated.
    *** [sha256-kernel.o] Error code 1

    make[4]: stopped in [...]/src/libafs/MODLOAD
    1 error

To avoid this, make all of our libafs objects depends on vnode_if.h.

[adeason@dson.org: Expanded commit message.]

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

7 months agotests: Run perl via 'env' 44/14144/2
Andrew Deason [Mon, 13 Apr 2020 01:16:55 +0000]
tests: Run perl via 'env'

The 'perl' binary may not be /usr/bin/perl, depending on the system.
For example, on modern FreeBSD it tends to be /usr/local/bin/perl
instead.

To avoid relying on perl to be in a specific location, just run via
/usr/bin/env instead, so we pick up perl from $PATH instead.

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