openafs.git
5 years agolibafs: reset all the volumes with fs flushall
Michael Meffie [Fri, 12 Jun 2015 00:28:43 +0000]
libafs: reset all the volumes with fs flushall

Fix a logic bug in fs flushall in which only the first volume in each
hash chain is reset (invalidated).  Instead, reset all the volumes in
the volume hash.

This bug was introduced in commit 4197bbecd9d0b2ff0b8eaec75a0df9a64f713cf0
(libafs: fs flushall for unix cm)

Also, when flushing a single volume with fs flushvolume, don't bother
searching all the hash chains, instead start on the hash chain
containing the volume being flushed.

Change-Id: I7be67fdb310b4845d02dc916f4400f83cc649cb8
Reviewed-on: http://gerrit.openafs.org/11892
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agopagsh: do not call set[ug]id()
Benjamin Kaduk [Mon, 9 Feb 2015 17:09:32 +0000]
pagsh: do not call set[ug]id()

Supposedly calling setuid(getuid()) and setgid(getgid()) would
help pick up a new group list on some systems, in the depths
of history.  In the absence of reason to believe this is still
the case, drop the calls to avoid scary warnings about unchecked
return values.

Change-Id: I39e87a27fb52f5a6868b867c9325d4a5fa93ef58
Reviewed-on: http://gerrit.openafs.org/11759
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoAvoid unsafe scanf("%s")
Benjamin Kaduk [Mon, 9 Feb 2015 15:38:04 +0000]
Avoid unsafe scanf("%s")

Reading user input into a fixed-length buffer just to check the
first character is silly and an easy buffer overrun.  gcc on
Ubuntu 13.03 warns about the unchecked return value for scanf(),
but scanf("%s") is guaranteed to either succeed or get EOF/EINTR/etc..

In any case, we don't need to use scanf() at all, here -- reuse an
idiom from BSD cp(1) and loop around getchar to read the user's
response, eliminating the fixed-length buffer entirely.  A separate
initial loop is needed to skip leading whitespace, which is done
implicitly by scanf().

Change-Id: Ic5ed65e80146aa3d08a4b03c213f748ef088156b
Reviewed-on: http://gerrit.openafs.org/11758
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoafs: Do not supply bogus poll vnodeops for FBSD
Benjamin Kaduk [Wed, 27 May 2015 20:13:13 +0000]
afs: Do not supply bogus poll vnodeops for FBSD

We currently provide one which just always returns 1, but the
kernel provides a vop_nopoll which conceptually is the same thing.
That one, however, provides some feature checks and fails when
consumers ask for fancy features that are not portable.

Change-Id: Iba03904aac2883e18a1abdd4f09289b6c6f907c0
Reviewed-on: http://gerrit.openafs.org/11882
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoIgnore return values more harder
Benjamin Kaduk [Fri, 6 Feb 2015 19:15:11 +0000]
Ignore return values more harder

Building on Ubuntu 14.04 with gcc 4.8.2-19ubuntu1, we encounter
fatal warnings about unchecked return values in uss, which is
now always built, as of 00a33b26d74aa067086ddc340efb82184715857f.

Change-Id: I997dcb683e33902c2765121c70bdcf21e9d5e892
Reviewed-on: http://gerrit.openafs.org/11757
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoLinux: mmap: Apply recursion check only to recursion cases
Marc Dionne [Wed, 22 Apr 2015 18:06:12 +0000]
Linux: mmap: Apply recursion check only to recursion cases

The CPageWrite flag was originally added to prevent a scenario
where a thread doing "writepage" would realize that the cache
was too full and that some of its contents need to be written
back to the server.  Before writing back it would ask the OS to
flush any dirty VM associated with the vcache entries that are
to be written, to make sure the data is not stale.  This flush
could itself trigger writeback, leading to deadly recursion.
One such scenario is a process doing mmap writes to a file larger
than the cache.

With some kernel versions and some callers of writepage, this
can cause the mapping to be marked as being in an error state,
leading to EIO errors passed back to user space.

Make the recursion check more specific to only bail when the
calling thread is one that was originally seen writing.  A list
of current writers is maintained instead of a single state flag.

This lets other threads (like the flusher thread) go on with
writeback to the same file, and limits the WRITEPAGE_ACTIVATE
return case to call sites that can deal with it.

In testing this helps avoid EIO errors when writing large
chunks of data through mmap.

Thanks to Yadav Yadavendra for extensive analysis and testing.

Change-Id: Ic3136d7050c62e3ffac5e52441171f322b60fe86
Reviewed-on: http://gerrit.openafs.org/11124
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoopr: Add new softsig implementation
Simon Wilkinson [Fri, 23 Mar 2012 21:26:14 +0000]
opr: Add new softsig implementation

Signals and pthreaded applications are a poor match. OpenAFS has had
the softsig system (currently in src/util/softsig.c) in an attempt to
alleviate some of these problems. However, that implementation itself
has a number of problems. It uses signal functions that are unsafe in
pthreaded applications, and uses pthread_kill within its signal
handlers. Over the years it has been responsible for a number of
portability bugs.

The old implementation continues to receive signals in the main thread
of the application. However, the handler code is run within a seperate
signal handler thread. When the main thread receives a signal a stub
handler is invoked, which simply pthread_kill()s the signal handler
thread.

The new implementation simplifies things by only receiving signals in
the handler thread. It uses only pthread-compatible signal functions,
and invokes no code from within async signal handlers.

A complete test suite is supplied.

Change-Id: I4bac68c2f853f1e7578b54ddced3833a97dd3f82
Reviewed-on: http://gerrit.openafs.org/6947
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoafsio: switch BreakUpPath to strdup
Benjamin Kaduk [Wed, 20 May 2015 14:57:53 +0000]
afsio: switch BreakUpPath to strdup

The current version of BreakUpPath is slightly broken, since
commit 4e68282e26b0c4569d25d076d54274f0da47a691 -- it has two
output parameters but takes only one length parameter for the
size of the output buffers passed in.  The callers ended up using
the shorter of the buffer lengths in question, so there is not
a risk of a buffer overrun, but long paths would not be properly
handled.

There is not really any need to pass in a length at all, since
what is going on is conceptually strdup, and there is no real
need to use strlcpy at all.  Make the change from strlcpy to
str(n)dup, and adjust callers to free the outputs as appropriate.

While here, convert writeFile() to use goto and a cleanup handler
to avoid leaks.

Change-Id: Ib742cb73a6d70aa863c8d30423416887b977677b
Reviewed-on: http://gerrit.openafs.org/11874
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoAdd defines for recent darwin sysctl constants
Daria Brashear [Thu, 21 May 2015 20:34:09 +0000]
Add defines for recent darwin sysctl constants

These were accidentally omitted from commit
ab9bb6363ca95f658764fbb9fb68ec88f89a5b3f.

Change-Id: Ic3374484eb79fe44a4032def1484c9ed733f9422
Reviewed-on: http://gerrit.openafs.org/11875
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoLinux 4.1: Don't define or use ->write directly
Marc Dionne [Mon, 20 Apr 2015 13:41:53 +0000]
Linux 4.1: Don't define or use ->write directly

We no longer have to define a ->write operation, and we can't
expect the underlying disk cache filesystem to have one.  Use
the new __vfs_read/write helpers that will select the operation
to use based on what's available for that particular filesystem.

Change-Id: Iab923235308ff57348ffc2dc6d718dd64040656b
Reviewed-on: http://gerrit.openafs.org/11849
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoLinux 4.1: No need for do_sync_read
Marc Dionne [Mon, 20 Apr 2015 13:37:40 +0000]
Linux 4.1: No need for do_sync_read

Make the test here a bit more specific. do_sync_read no longer
exists, but we don't use it for new kernels.  Trying to define it
here in terms of generic_file_read is not helpful as that doesn't
exist anymore.

Change-Id: Iffb059716165436c3439e66db15002cdec5dfc16
Reviewed-on: http://gerrit.openafs.org/11848
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agokauth: fix clock skew detection
Benjamin Kaduk [Wed, 22 Apr 2015 17:43:43 +0000]
kauth: fix clock skew detection

Commit 5b3c1042969daec38ccb260e61d665eda0c713ea changed/removed some
uses of abs() on unsigned time values. While the previous use of abs()
was indeed incorrect, the result wasn't necessarily much better, even
though it built with recent compilers, since it only checked for skew
in one direction.

Define and use a  macro to correctly evaluate the conditionals in 64-bit
precision, avoiding C's integer promotion rules which prefer unsigned types
(Date) to signed types of the same width (time_t on 32-bit systems).

Change-Id: Ifcbe59e73942a52a8635cb0f43cce94fdeea85a3
Reviewed-on: http://gerrit.openafs.org/11850
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoafsd: Update list of supported flags
Perry Ruiter [Wed, 22 Apr 2015 16:58:48 +0000]
afsd: Update list of supported flags

afsd.c starts with a block comment listing the flags supported by the
afsd command.  As the code has evolved this list has not been kept up
to date.  Bring the list up to date.  Some obsolete options no longer
have any backing code.  These are marked OBSOLETE.  Some obsolete
options have code that says they are now deprecated.  These are
marked IGNORED.

Additionally fix a typo in backuptree's help text.

Change-Id: I90ddf4db826c891bf1daf6959f94feee17d35f78
Reviewed-on: http://gerrit.openafs.org/11857
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agolibafs: remove extraneous solaris headers from afs_util.c
Michael Meffie [Thu, 30 Apr 2015 13:47:11 +0000]
libafs: remove extraneous solaris headers from afs_util.c

Remove several solaris specific headers from afs_util.c which are no
longer needed.

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

5 years agoosx: update afssettings for yosemite
Daria Brashear [Thu, 16 Apr 2015 17:12:05 +0000]
osx: update afssettings for yosemite

handle deprecated functions

Change-Id: I437ec88b7909c38af247f44d58599da8810a72f2
Reviewed-on: http://gerrit.openafs.org/11836
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoAllocate pathname buffers dynamically
Jeffrey Hutzelman [Tue, 18 Jun 2013 01:08:14 +0000]
Allocate pathname buffers dynamically

This change reworks numerous places which formerly used potentially
large on-stack buffers (of size AFSDIR_PATH_MAX) for constructing or
storing pathnames.  Instead, these buffers are now allocated from the
heap, either by using asprintf() to build a pathname in a correctly
sized buffer or, where necessary, using malloc() to allocate a buffer
of size AFSDIR_PATH_MAX.

A few occurrances of AFSDIR_PATH_MAX-sized buffers are not changed;
these are generally either globals or are contained within another
data structure that is already allocated on the heap.

[kaduk@mit.edu convert to cleanup-handler memory management where
appropriate]

Change-Id: Ib1986187a1c467e867d50280aaf1d8a86d9108c8
Reviewed-on: http://gerrit.openafs.org/9985
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agovol: use ffs from opr instead of inline
Benjamin Kaduk [Wed, 14 Jan 2015 20:32:47 +0000]
vol: use ffs from opr instead of inline

volume.c defined its own ffs() macro if AFS_HAVE_FFS was not
defined.  Now that ffs() is in opr, just use it from there always.

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

5 years agoRemove Linux 2.4 compat from RedHat packaging
Benjamin Kaduk [Mon, 13 Apr 2015 16:05:12 +0000]
Remove Linux 2.4 compat from RedHat packaging

You can't package what you can't build.

Change-Id: Ife3a46dfa1fee72b36d0f1fb21d82928aa8d83b6
Reviewed-on: http://gerrit.openafs.org/11833
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove linux24 conditionals from mcas/Makefile.osi
Benjamin Kaduk [Wed, 18 Mar 2015 17:36:26 +0000]
Remove linux24 conditionals from mcas/Makefile.osi

Linux 2.4 has been desupported by OpenAFS.

Change-Id: I7803d718ca9d2760a799f1ac2c438f8e6df8b9b9
Reviewed-on: http://gerrit.openafs.org/11806
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove stale MakefileProto.LINUX.in conditionals
Benjamin Kaduk [Wed, 18 Mar 2015 17:34:49 +0000]
Remove stale MakefileProto.LINUX.in conditionals

Linux 2.4 and older are no longer supported; there's no need to
keep the noise in this file.

Change-Id: Ia1a968e0cdc1180e66bdedd0aa0638eadfd897fb
Reviewed-on: http://gerrit.openafs.org/11805
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove LINUX24 from src/rx
Benjamin Kaduk [Wed, 18 Mar 2015 17:23:43 +0000]
Remove LINUX24 from src/rx

These files are no longer used.

Change-Id: Iebf85590e18c2542663ebdd279b126a3ab058213
Reviewed-on: http://gerrit.openafs.org/11803
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove LINUX24 from src/afs
Benjamin Kaduk [Wed, 18 Mar 2015 17:23:16 +0000]
Remove LINUX24 from src/afs

These files are no longer used.

Change-Id: I4a7e0cc8c308399004c999b3769c77388794cfdd
Reviewed-on: http://gerrit.openafs.org/11802
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove linux22 and linux24 param files
Benjamin Kaduk [Wed, 18 Mar 2015 17:20:07 +0000]
Remove linux22 and linux24 param files

They are no longer used.

Change-Id: I1337bf0e1239336e7ae39f88f484cb8237002302
Reviewed-on: http://gerrit.openafs.org/11801
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoRemove osconf conditionals for linux24
Benjamin Kaduk [Wed, 18 Mar 2015 17:17:59 +0000]
Remove osconf conditionals for linux24

They are no longer triggerable now that linux 2.4 is desupported,
so make the code easier to read.

Change-Id: I77b48d30db66b635cfdc06e977f9884dd2825713
Reviewed-on: http://gerrit.openafs.org/11800
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoMark Linux 2.4 as unsupported
Benjamin Kaduk [Wed, 18 Mar 2015 17:11:44 +0000]
Mark Linux 2.4 as unsupported

The Linux 2.4 series (and older) will not be supported platforms
for OpenAFS 1.8 and later.  Detect these systems at configure time
and direct users of those systems to the OpenAFS 1.6 series of releases.

These systems are believed to not be in common use with OpenAFS,
and retaining support for the LinuxThreads threading implementation
they require presents a maintenance burden that the project is
not equipped to deliver.  The project will be able to move forward
more quickly by desupporting these systems.

Code conditional on these old systems can be removed in subsequent
commits.

Change-Id: I679fc2390b35851f3b0457a846047c812bc03dba
Reviewed-on: http://gerrit.openafs.org/11799
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Daria Brashear <shadow@your-file-system.com>

5 years agoaklog: swap order of roken and hcrypto
Ben Kaduk [Thu, 12 Feb 2015 21:01:28 +0000]
aklog: swap order of roken and hcrypto

hcrypto depends on roken, so roken must come after it.

Change-Id: Ic63de1f9095555a6c3e83f2f6d2f9d024ad00006
Reviewed-on: http://gerrit.openafs.org/11743
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agovos: remaddrs sub-command
Michael Meffie [Mon, 17 Nov 2014 16:23:38 +0000]
vos: remaddrs sub-command

Introduce the vos remaddrs sub-command for removing multi-homed server
entries from the vldb.  The remaddrs sub-command completes the listaddrs
and setaddrs command suite and allows vos changeaddr to be deprecated
completely.

Change-Id: I98e92e776a153591a617a5b04037c3b6139d4732
Reviewed-on: http://gerrit.openafs.org/11606
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoDo not redeclare mutexes for darwin
Benjamin Kaduk [Wed, 18 Mar 2015 14:35:33 +0000]
Do not redeclare mutexes for darwin

Partially revert commit e2e93aa8920c0b1bfc672a555a59eb4e15dbeaae,
which added local declarations for des_init_mutex, des_random_mutex,
and rxkad_random_mutex to a number of files in libadmin, apparently
to fix the build on macos 10.3.  That OS is long EoL-ed, and
more recent versions of OS X include toolchains that do not
need these extra declarations.  In particular, the extra declarations
can be harmful when these files start to pull in more symbols
from our libraries (e.g., libafscp), since the details of the
linking process can cause that to generate duplicate symbol errors.

There is no longer any need to have local declarations of these
symbols for OS X, so just remove them.

Change-Id: Ie152387b4bd16b470054821fc8ddf852e1a4285c
Reviewed-on: http://gerrit.openafs.org/11798
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoaklog: Correct size used for strlcpy()
Nathan Dobson [Fri, 20 Mar 2015 22:32:22 +0000]
aklog: Correct size used for strlcpy()

When copying into the 'cell' array, use the size of cell, not
the size of some other array that is copied into a few lines previously.

Change-Id: Ib8b523901dd8008038c5a95a7c315b899cff8cee
Reviewed-on: http://gerrit.openafs.org/11807
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agopioctl.c: restore required result variable
Mark Vitale [Mon, 9 Feb 2015 23:16:16 +0000]
pioctl.c: restore required result variable

Commit b9fb9c62a6779aa997259ddf2a83a90b08e04d5f refactored lpioctl()
so that LINUX would have its own implementation. This also simplified
the other lpioctl() implementations by removing superfluous variable
'rval'.

Unfortunately, 'rval' was actually required for both DARWIN and SUN511.
On both of these platforms, the address of 'errcode' is passed
to the respective ioctl_*() routine so its value may be passed back
to lpioctl().   Therefore, 'errcode' must not also be used for the
return value from these functions;  doing so results in the return
value from the function overwriting the intended value of 'errcode' upon
return to lpioctl().

In the case of Solaris 11, ioctl_sun_afs_syscall() always returns zero
(as long as the ioctl device 'dev/afs' opened successfully).
So 'errcode' was always being set to zero, even if the pioctl had
actually failed.  For example, without this fix, 'fs listcells'
loops forever on Solaris 11, listing an infinite number of "cells",
because it will never "see" the EDOM that informs it of the last defined
cell.

Partially revert b9fb9c62a6779aa997259ddf2a83a90b08e04d5f by restoring
the 'rval' variable and logic for DARWIN and SUN511.

Change-Id: I4407af29d54813689cf8ccf2517bb2df4dd8eb25
Reviewed-on: http://gerrit.openafs.org/11734
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agobos, pts: emit error messages on stderr
Christof Hanke [Thu, 5 Feb 2015 11:07:50 +0000]
bos, pts: emit error messages on stderr

as one expects.

Change-Id: Icb67a05b61ddcef8def826768491b9a1952862e9
Reviewed-on: http://gerrit.openafs.org/11605
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoNamespace-clean some more heimdal symbols
Ben Kaduk [Thu, 12 Feb 2015 00:02:00 +0000]
Namespace-clean some more heimdal symbols

We get linker conflicts if we try to statically link against the
system libkrb5 when it is heimdal, from both hcrypto and rfc3961.

While here, add an include guard to hcrypto's config.h.

Change-Id: Ib5fcd9291b295415325a4ed230bd35d496961367
Reviewed-on: http://gerrit.openafs.org/11740
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoFix incorrect uses of abs()
Ben Kaduk [Fri, 13 Feb 2015 14:47:20 +0000]
Fix incorrect uses of abs()

abs(3) is a function of one variable of type int returning int.
labs(3) is a function of one variable of type long returning long.

labs(3) should be used when the input is of type long, as in
kaprocs.c.

Calling anything from the abs(3) family on a variable of unsigned
type is a bogus type pun, and a logical operation which is a no-op.
(Unsigned values are never negative and thus the absolute value
function is the identity over the entire range of values representable
in an unsigned type.)  Just remove the use of abs() for unsigned
values, as in kaprocs.c, krb_udp.c, and vldb_check.c

While in kaprocs.c, wrap a long line that was touched for the
conversion to labs(3), spell the argument to time(3) as NULL
instead of 0, remove unneeded parentheses, and correct the spelling
of "reserved".

Change-Id: I0897b250fd885a1230d1622015eec9afe3450b46
Reviewed-on: http://gerrit.openafs.org/11745
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoRemove spurious NULL checks
Ben Kaduk [Wed, 11 Feb 2015 22:47:10 +0000]
Remove spurious NULL checks

clang 3.5 is more aggressive about these checks than the previous
FreeBSD system compiler, so new warnings (which became errors)
appeared on FreeBSD 11-CURRENT.

In afs_dcache.c, checking &tdc->f for NULL-ness has no effect.
The struct fcache f member of struct dcache is an ordinary structure
element; its address will be the value of tdc plus the offset of
f within struct dcache, which will not be NULL even if tdc is NULL.

In ubik_db_if.c, udbHandle is a file-scope global and thus has
allocated storage; the address of a member variable will never
be NULL.  The 0 it was compared against was spelled RX_SECIDX_NULL,
which shows the intended check, which is for the value of the
uh_scIndex member variable, not its address.

In afscp_server.c, srv->conns can never be NULL since conns is a member
variable of struct afscp_server (of array type, containing pointers
to struct rx_connection).  Comparing the array member variable against
NULL is comparing the address of the array, which is never NULL since
it is not allocated separately from struct afscp_server.

In fssync-debug.c, state.vop->partName is never NULL because
common_volop_prolog always allocates for state.vop, and the
partName member variable of struct fssync_state is of array type,
and thus is not separately allocated from the containing structure.

Change-Id: I03e1332d8a3320f1a4d303b444985648a207116e
Reviewed-on: http://gerrit.openafs.org/11739
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoUpdate CellServDB to 20150119 snapshot
Stephan Wiesand [Thu, 26 Feb 2015 09:13:50 +0000]
Update CellServDB to 20150119 snapshot

Update all remaining copies of CellServDB in the tree, and make the
Red Hat packaging use it by default too.

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

5 years agovlserver: do not perform ChangeAddr on mh entries, except for removal
Michael Meffie [Tue, 16 Dec 2014 21:13:01 +0000]
vlserver: do not perform ChangeAddr on mh entries, except for removal

Fix a long standing bug in the ChangeAddr RPC which damages the vldb,

When vos changeaddr is run with -oldaddr and -newaddr, and the -oldaddr
is present in an multi-homed entry, instead of changing the address in
the mh entry, the server slot is "downgraded" to a single homed entry
and the mh entry is orphaned in the vldb.

Instead, if the -oldaddr is in a multi-home entry, refuse to change the
address with a VL entry not found error and log the event.

Multi-homed addresses can be changed manually using the vos setaddrs
command which calls the RegisterAddrs() RPC.

Change-Id: I20ba3e7fa5ffdb1b1abd2e2a716d8e4bb6594542
Reviewed-on: http://gerrit.openafs.org/11639
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoubik: DISK_UpdateInterfaceAddr == server restart
Jeffrey Altman [Wed, 11 Feb 2015 06:25:04 +0000]
ubik: DISK_UpdateInterfaceAddr == server restart

If a DISK_UpdateInterfaceAddr RPC is received the server that sent
it restarted.  Force the urecovery code to verify the server state.

Change-Id: I465863dc3a52d844b56d576bd55229435556cfd6
Reviewed-on: http://gerrit.openafs.org/11738
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoubik: SDISK_Begin no quorum, wrong db, no transaction
Jeffrey Altman [Thu, 22 Jan 2015 06:14:28 +0000]
ubik: SDISK_Begin no quorum, wrong db, no transaction

When processing an DISK_Begin RPC verify that there is an active quorum
and that the local database is current.  Otherwise, fail the RPC with
a UNOQUORUM error.

The returned error must be UNOQUORUM instead of USYNC becase the returned
error code will be returned by the coordinator's ContactQuorum_iterate()
to the client that triggered the write transaction.  Most ubik clients
will only retry if the error is UNOQUORUM.

FIXES 131997

Change-Id: Icaa30e6aca82e7e7d33e9171a4f023970aba61df
Reviewed-on: http://gerrit.openafs.org/11689
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoLinux 4: struct address_space no longer has backing_dev_info
Anders Kaseorg [Mon, 23 Feb 2015 05:13:05 +0000]
Linux 4: struct address_space no longer has backing_dev_info

The backing_dev_info is only stored in the super_block now.

Change-Id: I57e147100bd47a8d1f5e97224ceb3322ea102a48
Reviewed-on: http://gerrit.openafs.org/11756
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoTreat Linux 4 (and greater) as Linux 2.6/3
Anders Kaseorg [Mon, 23 Feb 2015 04:43:49 +0000]
Treat Linux 4 (and greater) as Linux 2.6/3

In an age where Linux version numbers are determined by Google+ polls,
it’s clear that they aren’t going to be very useful for marking major
API compatibility boundaries like they were in the days of 2.2/2.4.

Change-Id: I56e0e88eb178573c3eb280d5a5a01d8b8a20a363
Reviewed-on: http://gerrit.openafs.org/11755
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoDocument --enable-linux-d_splice_alias-extra-iput
Stephan Wiesand [Tue, 17 Feb 2015 14:34:33 +0000]
Document --enable-linux-d_splice_alias-extra-iput

Even though we hope no one will actually ever need to use it, explain
this configure switch in the same place as the others.

Change-Id: Ib59f963b9000c3e66dc84c7b18eb220f0e108bd5
Reviewed-on: http://gerrit.openafs.org/11749
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agovos: preserve cloneId and backupId when restoring
Michael Meffie [Mon, 29 Sep 2014 16:14:24 +0000]
vos: preserve cloneId and backupId when restoring

Preserve the volume clone and backup ids in the volume header when
restoring over an existing volume, instead of always setting the clone
and backup ids to zero.

For example, before this change, restoring over a volume resets the
ROnly and Backup ids reported in the volume header section of vos
examine.

    $ vos examine xyzzy
    xyzzy                          536871023 RW          3 K  On-line
        myhost /vicepa
        RWrite  536871023 ROnly  536871024 Backup  536871025
     ...
     RWrite: 536871023     ROnly: 536871024     Backup: 536871025
        number of sites -> 2
           server myhost partition /vicepa RW Site
           server myhost partition /vicepa RO Site

    $ cat /tmp/xyzzy.dump | vos restore myhost a xyzzy -overwrite incremental
    Restoring volume xyzzy Id 536871023 on server myhost partition /vicepa .. done
    Restored volume xyzzy on myhost /vicepa

    $ vos examine xyzzy
    xyzzy                          536871023 RW          3 K  On-line
        myhost /vicepa
        RWrite  536871023 ROnly          0 Backup          0
     ...
     RWrite: 536871023     ROnly: 536871024     Backup: 536871025
        number of sites -> 2
           server myhost partition /vicepa RW Site
           server myhost partition /vicepa RO Site

Change-Id: If7ffcf84a983046c10d9d215d672a6a1ba1f9400
Reviewed-on: http://gerrit.openafs.org/11516
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoHandle backupDate of zero
Benjamin Kaduk [Wed, 10 Dec 2014 19:07:14 +0000]
Handle backupDate of zero

In older versions of OpenAFS (prior to 2001), the backupDate was
never set.  Try to provide somewhat more reasonable behavior in
this case, by using a different date in that case.

Change-Id: Id74ce003c6a2317b06e78ba64d6891229c16421a
Reviewed-on: http://gerrit.openafs.org/11627
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agolibafscp: Remove comment with dead code
Andrew Deason [Thu, 30 Jan 2014 19:38:01 +0000]
libafscp: Remove comment with dead code

You're not supposed to write the length of the submitted data on the
split rx stream for a StoreData operation; the fileserver knows how
much data to read from the "Length" parameter of the StoreData RPC.

For a FetchData, putting the data length over the split rx stream is
required, since we can't get the "OUT" arguments before reading the
file data. But for a StoreData, this is unnecessary, since the length
is right there in the arguments.

So just get rid of this commented-out code; it's clearly wrong and
this commit explains why.

Change-Id: Idde0f9079e90da75d71a142f4a9f36a84ce79776
Reviewed-on: http://gerrit.openafs.org/10786
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agorx: Set lastBusy on RX_CALL_TIMEOUT
Andrew Deason [Thu, 30 Jan 2014 06:02:24 +0000]
rx: Set lastBusy on RX_CALL_TIMEOUT

Currently, if a server RPC hangs forever, the client call will error
out with RX_CALL_TIMEOUT (if idle/dead timeouts are configured). If we
later try to make a new call on that conn, the server will respond
with BUSY packets, and we'll have to wait until we RX_CALL_TIMEOUT
again. After that we'll set lastBusy and avoid the call channel, but
that extra delay with the BUSY packets is avoidable.

So, avoid this extra delay by setting lastBusy when we kill a call
with RX_CALL_TIMEOUT, so a future rx_NewCall will avoid the call
channel. It makes sense to set lastBusy here, since the call channel
is more likely to be busy than the other call channels.

Change-Id: Iadf77f52ae418491e3108a4b0b5388361f2424aa
Reviewed-on: http://gerrit.openafs.org/10785
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agorx: Remove RX_CALL_BUSY
Andrew Deason [Thu, 30 Jan 2014 06:40:57 +0000]
rx: Remove RX_CALL_BUSY

Commit 23d6287f7f494383891a497038e8c0e870e824bf introduced the
behavior where a client can immediately retry a call if it receives a
"busy" packet from the server (meaning, the call channel is already in
use). This happened via Rx returning the error code RX_CALL_BUSY, and
the caller was supposed to immediately retry the call, so Rx could
reissue the RPC on a different call channel.

However, this behavior makes it more likely for the server to process
an RPC that the client thinks has not been processed. Say the client
issues an RPC, the server replies with a "busy" packet, and the client
resends the original packet before it sees the "busy" packet. In
this case, the server will get the resent packet for the RPC request
and process it, but the client will think the call has failed (and
presumably will retry the call on a new channel). For calls that are
non-idempotent (e.g. MakeDir), this can result in incorrect errors
(e.g. EEXIST) as well as incorrect cache state in the client.

There may be some ways to mitigate at least some of the problems here,
but this kind of "instant" retry behavior is often not really that
helpful. Calls that take a very long time to run on the server are
very rare (and usually indicate some other problem), while the
occasional short-lived "busy" packet is relatively common (sometimes
the server just hasn't cleaned up the call by the time we issue a new
call). So just get rid of the retrying behavior to ensure we don't
continue to encounter any problems like this.

To get rid of this behavior, we remove the RX_CALL_BUSY code, and all
code dealing with processing it. This means removing the RX_CALL_BUSY
handling from the client, as well as removing
rx_SetBusyChannelError(). This effectively reverts most of
23d6287f7f494383891a497038e8c0e870e824bf, and a few other commits
related to RX_CALL_BUSY.

With this change, if all we get from the server are BUSY packets when
we try to issue an RPC, the call will eventually error out with
RX_CALL_TIMEOUT (or hang forever, if no timeouts are configured). This
can be thought of intuitively as similar to "idle dead" behavior,
since we are just waiting for the server to proceed with processing
the call. So, if "idle dead" is configured, we still timeout after the
"idle dead" timeout. And if no idle or hard dead timeout is
configured, we will hang forever; just like if the server started
processing the call but then hangs forever.

Note that not all of 23d6287f7f494383891a497038e8c0e870e824bf is
reverted. Namely, the logic to have rx_NewCall try to pick the "least
busy" channel is retained.

Thanks to Simon Wilkinson for bringing up and discussing this issue in
this thread:
<http://thread.gmane.org/gmane.comp.file-systems.openafs.devel/10931>
<https://lists.openafs.org/pipermail/openafs-devel/2013-April/019297.html>

Change-Id: I272e51f252356aa14bc4b8a3b7c594700deb432c
Reviewed-on: http://gerrit.openafs.org/10784
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agorx: Remove RX_CALL_IDLE
Andrew Deason [Thu, 30 Jan 2014 06:39:39 +0000]
rx: Remove RX_CALL_IDLE

After change Ie0497d24f1bf4ad7d30ab59061f96c3298f47d17, RX_CALL_IDLE
is not generated by Rx anymore; "idle dead" timeouts just cause
RX_CALL_TIMEOUT errors. Any code dealing with it is thus now dead code
(this value was deliberately never sent over the wire), so remove the
dead code.

Change-Id: I2b38327f77ffc8168712b83506afa1da3eea1224
Reviewed-on: http://gerrit.openafs.org/10783
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agorx: Remove idleDeadDetection
Andrew Deason [Thu, 30 Jan 2014 06:36:22 +0000]
rx: Remove idleDeadDetection

After change Ie0497d24f1bf4ad7d30ab59061f96c3298f47d17,
testing for idleDeadDetection is equivalent to testing if idleDeadTime
is non-zero. The idleDeadDetection field is thus redundant, so remove
it.

Change-Id: Id11f2829167f4de1505cee286dcc7c56b431a5a6
Reviewed-on: http://gerrit.openafs.org/10782
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agorx: Rely on remote startWait idleness for idleDead
Andrew Deason [Mon, 27 Jan 2014 06:36:14 +0000]
rx: Rely on remote startWait idleness for idleDead

This commit removes the functionality introduced in
c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1 (which is also modified by a
few later commits), as well as
05f3a0d1e0359f604cc6162708f3f381eabcd1d7. Instead we modify the
startWait check in rxi_CheckCall to apply to both "reading" and
"writing" to enforce "idle dead" timeouts.

Why do this? First, let's start out with the following:

If an Rx call gets permanently "stuck", what happens? What should
happen?

Here, "stuck" means that either the server or client hangs while
processing the call. The server or client is waiting for something to
complete before it issues the next rx_Read() or rx_Write() call. In
various situations over the years, this has happened because the
server or client is waiting for a lock, waiting for local disk I/O to
complete, or waiting for some other arbitrary event to occur.

Currently, what happens with such a "hanging" call is a little
complex, and has several different results in different situations.
The behavior of a call in this "stuck" situation is handled by the
"idle dead" timeout of an Rx call/connection. This timeout is enforced
in rxi_CheckCall, in two different conditionals (if an "idle dead"
timeout is configured):

    if (call->startWait && ((call->startWait + idleDeadTime) < now) &&
        (call->flags & RX_CALL_READER_WAIT)) {
        if (call->state == RX_STATE_ACTIVE) {
            cerror = RX_CALL_TIMEOUT;
            goto mtuout;
        }
    }

and

    if (call->lastSendData && ((call->lastSendData + idleDeadTime) < now)) {
        if (call->state == RX_STATE_ACTIVE) {
            cerror = conn->service ? conn->service->idleDeadErr : RX_CALL_IDLE;
            idle_timeout = 1;
            goto mtuout;
        }
    }

The first of these handles the case where we are waiting to rx_Read()
from a call for too long (the other side of the call needs to give us
more data). The second handles the case where we are waiting to
rx_Write() for too long (the other side of the call needs to read some
of the data we sent previously).

This second case was added by commit
c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1, but it has the general
problem that this check does not check if anyone is actually trying to
write to the call, and just tries to keep track of the last time we
wrote to the call. So, we may have written some data to the call
successfully, and then we went off to do something else. We can then
kill the call later for taking too long to write to, even though
nobody is trying to write to it. This results in a few problems:

 (1) When the fileserver is writing to the client, it may need to wait
     for various locks and it may need to wait for local disk I/O to
     complete. If this takes too long for any reason, the fileserver
     will kill the call (currently with VNOSERVICE), but the thread
     for servicing the call will still keep running until whatever the
     fileserver was waiting for finishes.

 (2) lastSendData is set whenever we send any ACK besides an
     RX_ACK_PING_RESPONSE (as of commit
     658d2f47281306dfd46c5eddcecaeadc3e3e7fa9). If we are the server,
     and we send any such ACK (in particular, RX_ACK_REQUESTED is
     common), the "idle dead" timer starts. This means the server can
     easily kill a call for idleness even if the server has never sent
     the client anything, and even if the server is still actively
     reading from the client.

 (3) When a client tries to issue an RPC for the server, the "idle
     dead" timeout effectively becomes a hard dead timeout, since we
     will write the RPC arguments to the Rx stream, and then wait for
     the server to respond with the output arguments. During this
     time, our 'lastSendData' is the last time we sent our arguments
     to the server, and so the call must finish before
     'call->lastSendData + idleDeadTime' is in the past.

In addition to this "idle dead" processing, commit
05f3a0d1e0359f604cc6162708f3f381eabcd1d7 appears to attempt to provide
"idle dead"-like behavior by disabling Rx keepalives at certain points
(when we're waiting for disk I/O), controlled by the application
process (currently only the fileserver). The idea is that if
keepalives are disabled, the server will just appear unreachable to
the client, and so if disk I/O takes too long, the client will just
kill the call because it looks like the server is gone. However, this
also has some problems:

 (A) Clients send their own keepalives, and the server will still
     respond to them. So, the server will not appear to be
     inaccessible anyway. But even if it did work:

 (B) This approach only accounts for delays in disk I/O, and not
     anywhere else (we could hang for a wide variety of reasons). It
     also requires the fileserver to decide when it's okay for a call
     to be killed due to "idle dead" and when it's not, which
     currently seems to be decided somewhat arbitrarily.

 (C) This doesn't really let the client dictate its own "idle dead"
     timeout for idleness specifically; it just looks like the server
     went away.

 (D) The fileserver would appear to be unreachable in this situation,
     but it's not actually unreachable. This can be confusing to
     clients, since distinguishing between a server that is completely
     down vs just taking too long is an important distinction.

 (E) As noted in (1) above, the fileserver thread will still keep
     waiting for whatever it has been waiting for, even though the
     call has been killed and is thus useless.

So instead of all of this stuff, just modify the rxi_CheckCall "idle
dead" check to depend on the call->startWait parameter instead. This
parameter will be set whenever anyone is waiting for something to
proceed in the call, whether that is waiting to read data or write
data. This should make "idle dead" processing much simpler, as it is
reduced to effectively: if we've been waiting for longer than N
seconds, kill the call.

This involves ripping out much of the code related to lastSendData and
rx_KeepAlive*. This means removing the call->lastSendData field and
the rx_SetServerIdleDeadErr function, since those were only used for
the behavior in c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1. This also
means removing rx_KeepAliveOn and rx_KeepAliveOff, since those were
only used for the behavior in
05f3a0d1e0359f604cc6162708f3f381eabcd1d7. This commit also removes the
only known use of the VNOSERVICE error code, so add some comments
saying what this code was used for (especially since it is quite
different from other V* error codes).

Note that the behavior in (1) could actually be desirable in some
situations. In environments that have clients without "idle dead"
functionality, and those clients cannot be upgraded or reconfigured,
this commit means those clients may hang forever if the server hangs
forever. Some sites may want the fileserver to be able to kill such
hanging calls, so the client will not hang (even if it doesn't free up
the fileserver thread). However, such behavior should really be a
special case for such sites, and not be the default behavior (or only
behavior) for all sites. The fileserver should just be concerned with
maintaining its own threads and availability, and clients should
manage their own timeouts and handle hanging servers.

Thanks to Markus Koeberl, who originally brought attention to some of
the problematic behavior here, and helped investigate what was going
on in the fileserver.

Change-Id: Ie0497d24f1bf4ad7d30ab59061f96c3298f47d17
Reviewed-on: http://gerrit.openafs.org/10773
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoWindows: Fake status info on EACCES
Jeffrey Altman [Tue, 10 Feb 2015 07:36:03 +0000]
Windows: Fake status info on EACCES

When enumerating a directory if status info for an entry cannot be
obtained, fake it.  Do not return STATUS_ACCESS_DENIED to the redirector
as that will be interpreted as the directory not being listable.

Change-Id: I488f5d8d244c363135e00e156a685cd56fd060c8
Reviewed-on: http://gerrit.openafs.org/11736
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoWindows: foo.backup -> foo.backup too many symlinks
Jeffrey Altman [Fri, 23 Jan 2015 00:48:32 +0000]
Windows: foo.backup -> foo.backup too many symlinks

In the case where an explicit mount point to a .backup volume is
resolved from a .backup volume the cache manager refuses to evaluate
the mount point target.  This is meant to address unwanted recursion
in the directory tree searches.

Change the error code to ERROR_TOO_MANY_SYMLINKS and propagate that
error to the AFS redirector.  That will result in the application
receiving STATUS_ACCESS_DENIED instead of
STATUS_REPARSE_POINT_NOT_RESOLVED.

The STATUS_REPARSE_POINT_NOT_RESOLVED error causes cmd.exe and
powershell.exe to terminate recursive directory searches.

Change-Id: I5dfdd835e8696b823af45a8e5c33a5ca6320cf31
Reviewed-on: http://gerrit.openafs.org/11693
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoIgnore return values harder
Jeffrey Hutzelman [Sun, 16 Jun 2013 20:28:22 +0000]
Ignore return values harder

In various places where we intentionally ignore the return values of system
calls and standard library routines, this changes the way in which we do so,
to avoid compiler warnings when building on Ubuntu 12.10, with gcc 4.7.2 and
eglibc 2.15-0ubuntu20.1.

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

5 years agorx: Zero unitialized uio structs
Andrew Deason [Wed, 4 Feb 2015 16:25:38 +0000]
rx: Zero unitialized uio structs

We use some uio structures that were allocated on the stack, but we
only initialize them by initializing individual fields. On some
platforms (Solaris is one known example, but probably not the only
one), there are additional fields we do not initialize. Since we
cannot be certain of what any additional fields there may be, just
zero the whole thing.

This is basically the same change as
I0eae0b49a70aee19f3a9ec118b03cfb3a6bd03a3, but in the rx subtree.

Change-Id: I400144143bb1f47409eccb931daacc8a5058e074
Reviewed-on: http://gerrit.openafs.org/11711
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoDeorbit AIX-specific QuickStartGuide bits
Benjamin Kaduk [Wed, 5 Nov 2014 19:26:36 +0000]
Deorbit AIX-specific QuickStartGuide bits

Although there are still servers deployed on AIX systems,
there may not be any clients in use, and it is unlikely that
there will be new deployments which require this documentation.

Change-Id: Id6554e120cb01c5d4de5c7de67e74e802b7ea217
Reviewed-on: http://gerrit.openafs.org/11592
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoDeorbit HP-UX-specific QuickStartGuide bits
Benjamin Kaduk [Wed, 5 Nov 2014 19:26:36 +0000]
Deorbit HP-UX-specific QuickStartGuide bits

Get the rest of them all at once.

Change-Id: Idb33746d43a4a1a9f41e21d7f6d81360ecdd952e
Reviewed-on: http://gerrit.openafs.org/11591
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoLINUX: ensure mvid is set on root vnodes
Daria Brashear [Wed, 14 Jan 2015 15:22:25 +0000]
LINUX: ensure mvid is set on root vnodes

it shoudn't happen that we aren't setting mvid on root vnodes,
so assert so we notice if the invariant is violated

Change-Id: I32c8aa4dced8751d11817d74508b87ff44261837
Reviewed-on: http://gerrit.openafs.org/11669
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoafs: refactor afs_linux_dentry_revalidate
Jeffrey Altman [Fri, 23 Jan 2015 00:36:59 +0000]
afs: refactor afs_linux_dentry_revalidate

No functional change.   Separate the

  if (locked && vcp->mvstat == 1) { ... }

conditional into

  if (locked) {
    if (vcp->mvstat == 1) { ... }
  }

in preparation for another change.

Change-Id: I1fe42ed7771882ce365d9359a4e6187c283592a8
Reviewed-on: http://gerrit.openafs.org/11692
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agobozo: do not exit when the client config already exists
Michael Meffie [Wed, 21 Jan 2015 19:58:35 +0000]
bozo: do not exit when the client config already exists

The bosserver creates symlinks for the client CSDB and ThisCell config
files during initialization.  Avoid exiting if the client CSDB or
ThisCell configuration already exists, otherwise the bosserver cannot be
restarted with bos restart.

This fixes an error introduced with commit
720363fa9bf7cfbebdc485104b74ca6bac1895f6, Fix unchecked return values.

Change-Id: Ie6ecf126d1ed663f161c26da2a8c4d568369d99d
Reviewed-on: http://gerrit.openafs.org/11684
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agodoc: backup manpage fix
Perry Ruiter [Tue, 20 Jan 2015 03:35:41 +0000]
doc: backup manpage fix

While reviewing gerrit 11678 I noticed the -n flag was
duplicated.  Remove the duplicate flag.

Change-Id: I4a63a50199e1564a0b0394445e9dc1569bb08a0c
Reviewed-on: http://gerrit.openafs.org/11688
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoafs: Zero uninitialized uio structs
Andrew Deason [Fri, 30 Jan 2015 19:29:57 +0000]
afs: Zero uninitialized uio structs

In several places in the code, we allocate a 'struct uio' on the
stack, or allocate one from non-zeroed memory. In most of these
places, we initialize the structure by assigning individual fields to
certain values. However, this leaves any remaining fields assigned to
random garbage, if there are any additional fields in the struct uio
that we don't know about.

One such platform is Solaris, which has a field called uio_extflg,
which exists in Solaris 11, Solaris 10, and possibly further back.
One of the flags defined for this field in Solaris 11 is UIO_XUIO,
which indicates that the structure is actually an xuio_t, which is
larger than a normal uio_t and contains additional fields. So when we
allocate a uio on the stack without initializing it, it can randomly
appear to be an xuio_t, depending on what garbage was on the stack at
the time. An xuio_t is a kind of extensible structure, which is used
for things like async I/O or DMA, that kind of thing.

One of the places we make use of such a uio_t is in afs_ustrategy,
which we go through for cache reads and writes on most Unix platforms
(but not Linux). When handling a read (reading from the disk cache
into a mapped page), a copy of our stack-allocated uio eventually gets
passed to VOP_READ. So VOP_READ for the cache filesystem will randomly
interpret our uio_t as an xuio_t.

In many scenarios, this (amazingly) does not cause any problems, since
generally, Solaris code will not notice if something is flagged as an
xuio_t, unless it is specifically written to handle specific xuio_t
types. ZFS is one of the apparent few filesystem implementations that
can handle xuio_t's, and will detect and specially handle a
UIOTYPE_ZEROCOPY xuio_t differently than a regular uio_t.

If ZFS gets a UIOTYPE_ZEROCOPY xuio_t, it appears to ignore the uio
buffers passed in, and supplies its own buffers from its cache. This
means that our VOP_READ request will return success, and act like it
serviced the read just fine. However, the actual buffer that we passed
in will remain untouched, and so we will return the page to the VFS
filled with garbage data.

The way this typically manifests is that seemingly random pages will
contain random data. This seems to happen very rarely, though it may
not always be obvious what is going on when this occurs.

It is also worth noting that the above description on Solaris only
happens with Solaris 11 and newer, and only with a ZFS disk cache.
Anything older than Solaris 11 does not have the xuio_t framework
(though other uio_extflg values can cause performance degradations),
and all known non-ZFS local disk filesystems do not interpret special
xuio_t structures (networked filesystems might have xuio_t handling,
but they shouldn't be used for a cache).

Bugs similar to this may also exist on other Unix clients, but at
least this specific scenario should not occur on Linux (since we don't
use afs_ustrategy), and newer Darwin (since we get a uio allocated for
us).

To fix this, zero out the entire uio structure before we use it, for
all instances where we allocate a uio from the stack or from
non-zeroed memory. Also zero out the accompanying iovec in many
places, just to be safe. Some of these may not actually need to be
zeroed (since we do actually initialize the whole thing, or a platform
doesn't have any additional unknown uio fields), but it seems
worthwhile to err on the side of caution.

Thanks to Oracle for their assistance on this issue, and thanks to the
organization experiencing this issue for their patience and
persistence.

Change-Id: I0eae0b49a70aee19f3a9ec118b03cfb3a6bd03a3
Reviewed-on: http://gerrit.openafs.org/11705
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoSOLARIS: Avoid uninitialized caller_context_t
Andrew Deason [Fri, 30 Jan 2015 19:08:19 +0000]
SOLARIS: Avoid uninitialized caller_context_t

Currently we pass a caller_context_t* to some of Solaris' VFS
functions (VOP_SETATTR, VOP_READ, VOP_WRITE, VOP_RWLOCK,
VOP_RWUNLOCK), but the pointer we pass is to uninitialized memory.

This code was added in commit 51d76681, and this particular argument
is mentioned in
<https://lists.openafs.org/pipermail/openafs-info/2004-March/012657.html>,
where the author doesn't really know what the argument is for.

Over 10 years later, it's still not obvious what this argument does,
since I cannot find any documentation for it. However, browsing
publicly-available Illumos/OpenSolaris source suggests this is used
for things like non-blocking operations for network filesystems, and
is only interpreted by certain filesystems in certain codepaths.

In any case, it's clear that we're not supposed to be passing in an
uninitialized structure, since the struct has actual members that are
sometimes interpreted by lower levels. Other callers in
Illumos/OpenSolaris source seem to just pass NULL here if they don't
need any special behavior. So, just pass NULL.

I am not aware of any issues caused by passing in this uninitialized
struct, and browsing Illumos source and discussing the issue with
Oracle engineers suggest there would currently not be any issues with
the cache filesystems we would be using.

However, it's always possible that issues could arise from this in the
future, or there are issues we don't know about. Any such issues would
almost certainly appear to be non-deterministic and be a nightmare to
track down. So just pass NULL, to avoid the potential issues.

Change-Id: I41babe520530ba886d1877de99eb1644c1b9f699
Reviewed-on: http://gerrit.openafs.org/11704
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agouse V_creationDate in DumpHeader for R/O volumes
Hans-Werner Paulsen [Wed, 17 Sep 2014 07:41:16 +0000]
use V_creationDate in DumpHeader for R/O volumes

This patch modifies a patch committed as 1e6fb1b7b7, the dumpTimes.to is now
set to creationDate for R/O volumes. The old value copyDate is wrong, if the
R/O volumes is re-cloned. This does not happen with "vos dump -clone", but
may happen with dumping a R/O volume directly: "vos dump <R/O volume>".

Change-Id: Ia3ae7e1ae4a22aa47f0f28fac45077ff6789e720
Reviewed-on: http://gerrit.openafs.org/11468
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoOpenBSD: Clean up use of LK_CANRECURSE in call to lockmgr()
Antoine Verheijen [Wed, 28 Jan 2015 02:49:04 +0000]
OpenBSD: Clean up use of LK_CANRECURSE in call to lockmgr()

The LK_CANRECURSE and LK_RECURSEFAIL flags in the call to lockmgr()
are mutually exclusive. Previous version of OpenBSD didn't really
check well for this but more recent versions look for the conflict
and take a kernel panic when they're both set.

The OpenBSD kernel module currently just blindly sets the
LK_CANRECURSE flag in its call to lockmgr(). This patch changes
that behaviour so that it checks to make sure that the LK_RECURSEFAIL
flags is not set before it actually applies the LK_CANRECURSE flag.
That removes the kernel panics that have started to arise.

This behaviour is more consistent with other OpenBSD code that makes
use of the LK_CANRECURSE flag.

Change-Id: Ie435559f4b88195136e09c6184543861f06257da
Reviewed-on: http://gerrit.openafs.org/11699
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoOpenBSD: Remove obsolete parameter in call to osi_VM_FlushVCache()
Antoine Verheijen [Wed, 28 Jan 2015 02:44:56 +0000]
OpenBSD: Remove obsolete parameter in call to osi_VM_FlushVCache()

The second parameter in the call to osi_VM_FlushVCache() in the kernel
module is obsolete and has been removed. However, one call in the
OpenBSD module still contains that parameter in its call. This patch
removes it, eliminating the compile error.

Change-Id: Ia3f79c74e86b8038301459e1adbf17a58056e8b1
Reviewed-on: http://gerrit.openafs.org/11698
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoLinux: d_splice_alias may drop inode reference on error
Marc Dionne [Thu, 18 Dec 2014 13:43:22 +0000]
Linux: d_splice_alias may drop inode reference on error

d_splice_alias now drops the inode reference on error, so we
need to grab an extra one to make sure that the inode doesn't
go away, and release it when done if there was no error.

For kernels that may not drop the reference, provide an
additional iput() within an ifdef.  This could be hooked up
to a configure option to allow building a module for a kernel
that is known not to drop the reference on error.  That hook
is not provided here.  Affected kernels should be the early
3.17 ones (3.17 - 3.17.2); 3.16 and older kernels should not
return errors here.

[kaduk@mit.edu add configure option to control behavior, which
is mandatory on non-buildbot linux systems]

Change-Id: Id1786ac2227b4d8e0ae801fe59c15a0ecd975bed
Reviewed-on: http://gerrit.openafs.org/11643
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoIRIX: remove mention of unsupported sgiefs from Makefile.in
Chas Williams (CONTRACTOR) [Mon, 15 Dec 2014 16:04:06 +0000]
IRIX: remove mention of unsupported sgiefs from Makefile.in

Change-Id: Ib3594fa5c75df2c10d2692801ed64d657ece5d19
Reviewed-on: http://gerrit.openafs.org/11635
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agoIRIX: Move src/sgistuff to platform/IRIX
Chas Williams (CONTRACTOR) [Mon, 15 Dec 2014 15:58:02 +0000]
IRIX: Move src/sgistuff to platform/IRIX

Change-Id: Ie7e17859c346e472af1d07adf2c359250f71d653
Reviewed-on: http://gerrit.openafs.org/11634
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoDeorbit IRIX-specific QuickStartGuide bits
Benjamin Kaduk [Wed, 5 Nov 2014 19:26:36 +0000]
Deorbit IRIX-specific QuickStartGuide bits

Get the rest of them all at once.

Change-Id: Ife9920f00ec8eea953929a76a30f86d958d55f9c
Reviewed-on: http://gerrit.openafs.org/11590
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoAdd auditing to GetXStats
Benjamin Kaduk [Thu, 4 Dec 2014 21:52:37 +0000]
Add auditing to GetXStats

This will record the caller as well as the fact that we received
a GetXStats call.

Change-Id: I101b9fcea37e26e031efa4a8cf74df8351866dcf
Reviewed-on: http://gerrit.openafs.org/11620
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoAFSVolClone: remove calls to AssignVolumeName
Hans-Werner Paulsen [Tue, 26 Aug 2014 14:44:51 +0000]
AFSVolClone: remove calls to AssignVolumeName

The calls in AFSVolClone to AssignVolumeName are unnecessary, because
the volume name is overwritten few lines later with strcpy.

Change-Id: If5031271b9ade08ae248703c8a72f3a083fd4fce
Reviewed-on: http://gerrit.openafs.org/11432
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoBuild system: MT_LIBS includes XLIBS
Simon Wilkinson [Wed, 9 Jan 2013 09:52:53 +0000]
Build system: MT_LIBS includes XLIBS

The MT_LIBS library list already includes XLIBS, so there's no need
to specify both on a link line.

Change-Id: I8594b1b6e1a16af741b40822cbce49e846b26f49
Reviewed-on: http://gerrit.openafs.org/8904
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoAdd asserts to VLock* functions
Andrew Deason [Fri, 23 Apr 2010 22:51:28 +0000]
Add asserts to VLock* functions

Make sure we don't continue on if we have unbalanced locks and
unlocks. Having a negative refcount is a serious internal error, and
they are difficult to fix unless we assert right away.

Change-Id: Ib9b5b3f209635e0365df96c79ea8bf49c765008b
Reviewed-on: http://gerrit.openafs.org/2594
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoDAFS: Free header on partially-attached vol salv
Andrew Deason [Thu, 4 Oct 2012 19:15:34 +0000]
DAFS: Free header on partially-attached vol salv

When we VRequestSalvage_r a volume, normally the header is freed when
the volume goes offline. This happens when we VOfflineForSalvage_r,
either via VCheckSalvage when nUsers drops to 0, or in
VRequestSalvage_r itself if nUsers is already 0. We cannot free the
header under normal circumstances, since someone else may have a ref
on vp, which implies that the vol header object is okay to use.

However, for VOL_SALVAGE_NO_OFFLINE, we skip all of that. For
VOL_SALVAGE_NO_OFFLINE, the volume has only been partially attached,
so it does not go through the full offlining process, so we don't ever
hit the normal VPutVolume_r handlers etc. So, in the current code, we
don't free the header. But our nUsers drops to 0 anyway, and when
nUsers is 0, our header is supposed to be on the LRU (if we have one).
"oops"

Rectify this by freeing the volume header when VOL_SALVAGE_NO_OFFLINE
is set. Add some comments to try to be very clear about what's going
on.

Note that similar behavior was removed in commit
4552dc552687267fce3c7a6a9c7f4a1e9395c8e5 via a similar flag called
VOL_SALVAGE_INVALIDATE_HEADER. I believe now that this is the same
scenario that VOL_SALVAGE_INVALIDATE_HEADER was trying to solve.
However, VOL_SALVAGE_INVALIDATE_HEADER was not always used correctly,
and its purpose was not really adequately explained, which contributed
to the idea that its very existence was buggy.

Previously, when VOL_SALVAGE_INVALIDATE_HEADER existed, it was used
incorrectly in the VRequestSalvage_r calls in GetVolume,
VForceOffline_r, and VAllocBitmapEntry_r. All of these call sites
could have a vp with other references held on it, and so invalidating
the header there can cause segfaults when the header is freed. So
ideally, commit 4552dc552687267fce3c7a6a9c7f4a1e9395c8e5 would have
just removed the flag from those call sites.

This change effectively restores the behavior that
VOL_SALVAGE_INVALIDATE_HEADER provided. But no new flags are gained,
since this behavior is what we want for the VOL_SALVAGE_NO_OFFLINE
flag. This is not a coincidence; for the 'normal' case, we will free
the header whenever we offline the volume. But for the 'do not
offline' case, obviously that will never happen, so we need to do it
separately. So, these two flags are really the same thing.

Change-Id: Ia369850a33c0e781a3ab2f22017b8559410ff8bf
Reviewed-on: http://gerrit.openafs.org/8204
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoihandle: Add a comment on IH_OPEN/IH_REALLYCLOSE
Andrew Deason [Thu, 4 Apr 2013 19:39:41 +0000]
ihandle: Add a comment on IH_OPEN/IH_REALLYCLOSE

Currently, it's not really 'safe' in ihandle to issue an IH_OPEN
against an IHandle_t when an IH_REALLYCLOSE is running at the same
time. The reasons for this are explained a bit in ticket 131530 and
related commits, but briefly:

Say IH_OPEN runs, and drops IH_LOCK to open a new fd on disk. Then
IH_REALLYCLOSE runs and closes all fds, or marks them as needing
close. The running IH_OPEN then acquires IH_LOCK again and puts the
newly-opened fd onto the per-IH list of fds. We now have an fd that
effectively "survives" across the IH_REALLYCLOSE; effectively
IH_REALLYCLOSE did not close all fds for the ih.

This is possibly fixable by maintaining some extra information in
IHandle_t's, but this is only a problem if we allow IH_OPEN calls to
happen simultaneously with IH_REALLYCLOSE calls. Ever since
ih_sync_thread was removed (or changed to not call IH_OPEN), there
should be no cases where this is possible. All instances of
IH_REALLYCLOSE happen during error recovery for a newly-created file,
or happen under a per-vnode write lock, or for volume metadata files
only happens when the ref count for a volume drops to zero when we're
offlining the volume.

So, do not bother trying to fix this, since doing so is currently a
waste of time and the resulting complexity could introduce bugs. But
in case someone ever tries to do something resulting in IH_OPEN calls
executing outside the normal threads of execution, add a comment
around the IH_REALLYCLOSE explanations to try and briefly explain that
this cannot currently be done.

Change-Id: I989806635f3b048b0c084480a4b02dc1902ba031
Reviewed-on: http://gerrit.openafs.org/9709
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoopr: implement the BSD ffs() functions
Benjamin Kaduk [Wed, 14 Jan 2015 20:05:35 +0000]
opr: implement the BSD ffs() functions

Provide opr implementations of ffs(), fls(), ffsll(), and flsll().
There is no need to provide the 'long' form, since int is 32 bits
and long long is 64 bits.

These functions return the index of the first (or last) bit set
in a given (long long) word, or zero if no bits are set.

Change-Id: I126000f8b650f41d67567a9af659e0805478af2d
Reviewed-on: http://gerrit.openafs.org/11671
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoafs: Remove unused constant DCSIZE
Benjamin Kaduk [Mon, 12 Jan 2015 22:48:25 +0000]
afs: Remove unused constant DCSIZE

The size of the dcache hash table is automatically determined
from the size of the vcache hash table size, since even before
the initial OpenAFS 1.0 release.  AFS 3.3 had constants
DCHASHSIZE and DVHASHSIZE which were used to size the respective
hash tables, but DCSIZE was unused even there.

Change-Id: I1f4e278eacb881b60a457fa9871225de7ce0f9f8
Reviewed-on: http://gerrit.openafs.org/11672
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agocacheout: Use authenticated secClass for VLDB
Andrew Deason [Tue, 16 Dec 2014 23:03:34 +0000]
cacheout: Use authenticated secClass for VLDB

Currently 'cacheout' will always utilize an unauthenticated connection
when talking to the VDLB, even if it uses an authenticated connection
when talking to fileservers. This is regardless of any tokens
retrieved or command-line parameters, etc.

Using an authenticated connection to the VLDB can be useful, since a
user may want to encrypt the VLDB communication, or require stronger
guarantees of data consistency. So, just use the same security class
information for our VLDB communication as for our fileserver
communication.

'scnull' is now not used anywhere after this commit, so get rid of it.

Change-Id: I1e8a440ea7427399a3b219246e4c3623a603c35e
Reviewed-on: http://gerrit.openafs.org/11637
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agofix byte ordering in check_sysid
Michael Meffie [Fri, 14 Nov 2014 21:57:53 +0000]
fix byte ordering in check_sysid

Several uuid fields as well as the ip addreses in the sysid file are in
network byte order.  Fix the check_sysid utility to decode these fields
properly.  In addition, print the server uuid in the common string
format used to display uuids, instead of by individual uuid fields.

Change-Id: I9688e9117490d0ef0eb6dd5af417222482322e0c
Reviewed-on: http://gerrit.openafs.org/11603
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agorx: rxi_SendPacketList remove duplicate conditional
Benjamin Kaduk [Sun, 14 Dec 2014 20:12:04 +0000]
rx: rxi_SendPacketList remove duplicate conditional

Presumably these checks were different at some point in the past.

Change-Id: I0fb8737404a3c4fa786ab7965b60d35328d0bf32
Reviewed-on: http://gerrit.openafs.org/11632
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agorx: Remove dead AFS_ADAPT_PMTU SUN5 code
Benjamin Kaduk [Sun, 14 Dec 2014 04:18:36 +0000]
rx: Remove dead AFS_ADAPT_PMTU SUN5 code

AFS_ADAPT_PMTU is only defined on linux26, so anything which is
conditional on both AFS_ADAPT_PMTU and AFS_SUN5_ENV being set is
dead code.

This seems to have been dead code since its introduction in
commit 1206e7538be86f073b21cd289266286b60a95d0a.

Change-Id: I9bb6ff40de87a7f2d8d953ef7583c6c2b090ab48
Reviewed-on: http://gerrit.openafs.org/11631
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agorx: Normalize use of some MTU-discovery fields
Andrew Deason [Thu, 13 Sep 2012 22:58:50 +0000]
rx: Normalize use of some MTU-discovery fields

When we store MTUs (peer->ifMTU, peer->natMTU, etc.), we store the
maximum transport unit usable by RX, i.e., excluding the IP and UDP
headers, but including the RX header.  Contrariwise, when we track the
size of packets we've sent (conn->lastPacketSize, peer->maxPacketSize),
we track logical packet lengths which exclude the RX header (and the IP
and UDP headers).  However, the consumers of lastPacketSize and
maxPacketSize were not always interpreting their values correctly as
excluding the RX (and other) headers.

Add comments to these fields in their respective structure definitions
to help make clear what they contain (and the difference between them).
Correct several checks which were using the wrong constant for
correcting between these two worldviews (and the wrong sign).  Modernize
the style of lines that are touched.

The lastPacketSize and maxPacketSize variables are only accessed from
five places: while sending packets, while processing acks, while sending
acks, while handling growMTU events, and in rxi_CheckCall().  They are
used to track the size of packets that have been successfully sent (and
thus, indirectly, to control the size of packets we send).  The
maxPacketSize is only set once we have received an ack from the peer for
a packet of that size, and lastPacketSize tracks the size of a
speculative packet larger than that size, until it is acked.

When sending packets, we check if the size of the packet we are sending
exceeds the recorded maxPacketSize, and if so, record that speculative
size in the lastPacketSize variable, along with the sequence number of
that packet in lastPacketSizeSeq.

Correspondingly, when processing acks, if the packet tracked in
lastPacketSizeSeq is being acked, we know that our speculative large
packet was successfully received, and can attempt to update the recorded
maxPacketSize for the peer.  This is done through an intermediate
variable, 'pktsize', which holds either the value of lastPacketSize or
lastPingSize, without adjustment for the size of any headers.

The ack processing has a bit of code to handle the case where
maxPacketSize has been reset to zero, initializing it to a small value
which should be expected to always work.  The intention seems to have
been to initialize maxPacketSize to the smallest permitted value (since
RX_MIN_PACKET_SIZE is amount of data available to RX in the smallest
permitted IP packet), but the old code was actually initializing
maxPacketSize from zero to something a bit larger than the minimum, by
RX_IPUDP_SIZE + RX_HEADER_SIZE.  This over-large initialization was
mostly harmless, see below.  After this potential initialization,
'pktsize' was incorrectly used to set a new ifMTU and natMTU for the
peer.  It correctly determined that a packet larger than the previous
maxPacketSize had been acked, but then set the peer's ifMTU and natMTU
to smaller values than the acked packet actually indicates.  (It is
careful to only increase the ifMTU, though.)  The actual peer->MTU is
*not* updated here, but will presumably trickle through eventually via
rxi_Resend() or similar.  It is possible that this code should be using
rxi_SetPeerMtu() or similar logic, but that might involve locking issues
which are outside the scope of this analysis.

The over-large initialization of maxPacketSize (from zero) was
fortuitously mostly harmless on systems using minimum-sized IP packets,
since a correspondingly wrong check was used to detect if a new MTU
invalidates this maxPacketSize, with the constants offsetting.
Likewise, the checks in rxi_SendAck() had the wrong constants, but they
offset to produce the correct boundary between small and large packets
while trying to grow the MTU.  Unfortunately, the old behavior in the
"small" case is not correct, and the grow MTU event would try to send a
packet with more padding than was intended.  In networks allowing
packets slightly larger than the minimum (but not much larger than the
minimum), the old code may have been unable to discover the true MTU.

In the main (MTU-related) logic of rxi_SendAck, a variable 'padbytes' is
set to a small increment of maxPacketSize in the "small" case, and a
larger increment of maxMTU in the "large" case.  There is a floor for
padbytes based on RX_MIN_PACKET_SIZE, which ended up being larger than
intended in the old code by approximately the size of the rx header.
(Some of the adjustments performed are rather opaque, so the motivations
are unclear.)

The more interesting places where accesses to lastPacketSize and
maxPacketSize happen are during the MTU grow events and in
rxi_CheckCall().

In rxi_CheckCall(), the packet size variables are only accessed if
the connection has the msgsizeRetryErr flag set, the call is not timed
out (whether for idleness or during active waiting), and the call has
actually received data.  In this case, we conclude that sending packets
failed and decrease the MTU.  The old code was quite broken in this
regard, with a reversed sense of conditional for whether a speculative
large packet was outstanding, and a rather large decrease in MTU size
of effectively 128 + RX_HEADER_SIZE + RX_IPUDP_SIZE = 212, when only
a decrease of 128 was intended.  The new code corrects the sense of
the conditional and sets the decrease in MTU to the intended value of 128.

With respect to MTU grow events, this change only touches
rxi_SetPeerMtu(), to correct the conditional on whether the MTU update
invalidates/overrides the cached maxPacketSize.  There is a window of
values which could cause the old code to incorrectly fail to invalidate
the cached maxPacketSize.  Values in this window could result in the old
code being stuck on a bad MTU guess, but should not cause an actual
failure to communicate.  That conditional zeroing of maxPacketSize is
the only access to the PacketSize variables in rxi_SetPeerMtu().
maxPacketSize is also checked in rxi_GrowMTUEvent(), but only against
zero to avoid sending RX_ACK_MTU packets needlessly, so it is unaffected
by the issue at hand.

In summary, in certain network conditions, the old code could fail
to find an optimum MTU size, but would always continue to operate.
The new code is more likely to find a better MTU size, and the old
and the new code should interoperate fine with both each other and
themselves.

[kaduk@mit.edu add a few missed cases; expound on analysis in commit message]

Change-Id: I7494892738d38ffe35bdf1dfd483dbf671cc799a
Reviewed-on: http://gerrit.openafs.org/8111
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoafs: Warn about afs_conn overcounts
Andrew Deason [Sun, 14 Sep 2014 19:24:17 +0000]
afs: Warn about afs_conn overcounts

Currently we panic if we detect an undercount on an afs_conn
structure, as this is a serious bug and can cause corruption and other
issues. But an overcount is never noticed, until the refCount
overflows and looks negative. Log a warning if the refCount gets
really high, so an administrator has a chance at noticing and
notifying a developer before the machine actually panics.

[kaduk@mit.edu use the %p format specifier, mandated by C89]

Change-Id: Ifc291fc10959e4e1c60115813d82a09e5a65ef75
Reviewed-on: http://gerrit.openafs.org/11465
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoafs: Refactor GetDSlot parameters
Andrew Deason [Tue, 30 Apr 2013 22:32:26 +0000]
afs: Refactor GetDSlot parameters

The 'indexvalid' and 'datavalid' parameters were really representing 3
different scenarios, not 2 different values with 2 possibilities each.
Change these to a single parameter, 'type', with 3 different values:
DSLOT_NEW, DSLOT_UNUSED, and DSLOT_VALID. Hopefully this will make the
relevant code paths easier to understand.

This should incur no functional change; it is just code
reorganization.

Change-Id: Iac921e74532de89121b461fa0f53ddb778735e0c
Reviewed-on: http://gerrit.openafs.org/9834
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoLINUX: Remove fix_bad_parent
Andrew Deason [Mon, 1 Dec 2014 16:11:38 +0000]
LINUX: Remove fix_bad_parent

For Linux, fix_bad_parent (and in 1.6 and earlier, check_bad_parent)
served the purpose of fixing mvid if it was "wrong", for volume-root
vcaches (mvstat == 2).

However, in modern Linux, we never really use mvid for root vcaches.
This would normally be used for looking up ".." entries in the root
dir, but Linux handles that for us.

Specifically, the only times an "mvstat == 2" mvid is used are:

 - afs_lookup(), where we specifically check for a ".." lookup. Linux
   cannot give us a lookup for "..", since Linux itself services ".."
   lookups through the dcache.

 - afs_readdir_move(), where we look for ".." entries. Linux does not
   use this function, since Linux reimplements afs_readdir() in
   afs_linux_readdir(), and so this function is never called.

Of course, mvid is used in many other locations, mostly for "mvstat ==
1" vcaches (mountpoints) and a few other special cases. But these are
the instances where mvid is relevant for root dirs.

So, since mvid is never really used for "mvstat == 2" vcaches on
Linux, don't bother trying to keep it up-to-date. Doing so is just
needless waste, and causes problems when there are bugs in
fix_bad_parent. The mvid field is still updated in cross-platform code
from time to time; removing that would be more complex and possibly
not worth the effort.

Change-Id: I5011ba069e5c8ed947ab6ff8d8dd393241d9c4bf
Reviewed-on: http://gerrit.openafs.org/11615
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoAdd AFSCONF_NOCELLNAME error code
Benjamin Kaduk [Wed, 10 Dec 2014 19:36:36 +0000]
Add AFSCONF_NOCELLNAME error code

Contrast with AFSCONF_NOCELL, which is for when no cell configuration
information is available at all (i.e., a struct afsconf_dir* was NULL) --
this code is used when there is some cell configuration available, but
that configuration does not include the cell name.

Replace the only existing use of AFSCONF_UNKNOWN with this more-informative
error code, leaving AFSCONF_UNKNOWN free for use in other situations.

Change-Id: I989756a960e5377545af43f8e9414d1f2d6476b4
Reviewed-on: http://gerrit.openafs.org/11628
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoLinux 3.19: struct nameidata becomes opaque
Marc Dionne [Mon, 5 Jan 2015 12:17:14 +0000]
Linux 3.19: struct nameidata becomes opaque

With kernel 3.19 struct nameidata becomes opaque.  As a result
we cannot rely on STRUCT_NAMEIDATA_HAS_PATH being true for
new kernels.

Rework the conditions here so that STRUCT_NAMEIDATA_HAS_PATH
is only tested when we're using a nameidata structure and
the result matters.

Also modify a configure test to use a nameidata pointer
instead of an actual structure.

Change-Id: I0d71fca44a67570ac3b86151c70f2969dc463f4f
Reviewed-on: http://gerrit.openafs.org/11648
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoLinux 3.19: Use mgs_iter in struct msghdr
Marc Dionne [Mon, 5 Jan 2015 12:13:37 +0000]
Linux 3.19: Use mgs_iter in struct msghdr

struct msghdr gets msg_iov replaced by msg_iter.  Add a configure
test and adjust the affected code.

Change-Id: I9b9e3987e55a10e48087b318d98a5a7bb17a4612
Reviewed-on: http://gerrit.openafs.org/11647
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoLinux 3.19: No more f_dentry
Marc Dionne [Mon, 5 Jan 2015 12:03:16 +0000]
Linux 3.19: No more f_dentry

Back in kernel 2.6 .20 struct file lost its f_dentry field
which was replaced by f_path.To ease transition f_dentry
was defined as f_dpath.dentry in the same header.This
define finally gets removed with kernel 3.19.

Keep using f_dentry in the code, but add a configure test
for the presence of f_path and the absence of the f_dentry
macro so we can add it if its missing.

Change - Id:I8e8a7e4d3ddd861018de50af1eb7315e730ad529

Change-Id: I4b05aa3d37f01e0e675c420cbf941d682c49c69c
Reviewed-on: http://gerrit.openafs.org/11646
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoLinux: d_alias becomes d_u.d_alias
Marc Dionne [Thu, 18 Dec 2014 12:13:46 +0000]
Linux: d_alias becomes d_u.d_alias

The fields in struct dentry are re-arranged so that d_alias
shares space wth d_rcu inside the d_u union.  Some references
need to change from d_alias to d_u.d_alias.

The kernel change was introduced for 3.19 but was also backported
to the 3.18 stable series in 3.18.1, so this commit is required
for 3.19 and current 3.18 kernels.

Change-Id: I711a5a3a89af6e0055381dfd4474ddca2868bb9c
Reviewed-on: http://gerrit.openafs.org/11642
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoptserver: Limit length on namelist, idlist
Andrew Deason [Tue, 12 Mar 2013 14:51:39 +0000]
ptserver: Limit length on namelist, idlist

namelist and idlist are used as IN parameters to ptserver RPCs that
can be issued by unauthenticated clients. Not having a length limit on
them means anyone can use up a ton of ptserver memory by just issuing
those RPCs with a very large length.

So, put a limit on them. PR_MAXLIST is a constant that already exists,
but is small enough to potentially limit real use, so define a new
OpenAFS-internal value for this purpose.

prlist and prentries are returned from the ptserver to clients, so
also limit them in the same way.

Change-Id: Iaf45639bbae401093354adbfb4daa172fe97ede1
Reviewed-on: http://gerrit.openafs.org/9588
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agouss: always build uss
Chas Williams (CONTRACTOR) [Mon, 5 Jan 2015 15:41:53 +0000]
uss: always build uss

Revert change Ibab1dd189e7fbc41ca01e7ef7479421c056999f5 since uss
should always be safe to build now that its parser symbols are private.

Change-Id: I65fd2008b037dd36a2c7d3ef8817d4d7dda689d7
Reviewed-on: http://gerrit.openafs.org/11653
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agouss: Avoid -i (inplace) with sed
Chas Williams (CONTRACTOR) [Tue, 6 Jan 2015 22:58:05 +0000]
uss: Avoid -i (inplace) with sed

Not all sed versions support inplace editing, so do things ourselves.
Also use the sed version found by configure for consistency.

Change-Id: I6194b8dd6b7abf88d0b0fa36ba871e0ba092ce1e
Reviewed-on: http://gerrit.openafs.org/11655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoLinux: Move code to reset the root to afs/LINUX
Marc Dionne [Thu, 18 Dec 2014 11:57:22 +0000]
Linux: Move code to reset the root to afs/LINUX

Move the Linux specific bit of code to reset the root to
afs/LINUX platform specific files.  Things that play with
the Linux vfs internals should not be exposed here.

No functional change, but this helps cleanup some ifdef
mess.

Change-Id: Ia27fca3d8052ead45783cb2332c04fe6e99e5d9f
Reviewed-on: http://gerrit.openafs.org/11641
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>

5 years agoFix unchecked return values
Jeffrey Hutzelman [Sun, 16 Jun 2013 19:28:03 +0000]
Fix unchecked return values

This change fixes numerous places where the return values of various
system calls and standard library routines are not checked.  In
particular, this fixes occurrances called out when building on Ubuntu
12.10, with gcc 4.7.2 and eglibc 2.15-0ubuntu20.1, when the possible
failure is one we actually do (or should) care about.  This change
does not consider calls where the failure is one we deliberately
choose to ignore.

Change-Id: Id526f5dd7ee48be2604b77a3f00ea1e51b08c21d
Reviewed-on: http://gerrit.openafs.org/9979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

5 years agovol: rename volUpdateCounter macro
Michael Meffie [Mon, 21 Jul 2014 21:41:32 +0000]
vol: rename volUpdateCounter macro

Change the volUpdateCounter volume macro name to be
consistent with the volume header name.

Change-Id: I55f55f2c084135e9598c194ed9081fce800ddfe9
Reviewed-on: http://gerrit.openafs.org/11318
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

5 years agoRemove traces of Debian packaging
Michael Laß [Mon, 8 Dec 2014 07:34:26 +0000]
Remove traces of Debian packaging

In e34e0d1 the Debian packaging was removed. Some traces are still left, so
remove those as well.

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

5 years agodafs: avoid asserting on dafs VSALVAGING error code
Michael Meffie [Thu, 19 Dec 2013 14:49:33 +0000]
dafs: avoid asserting on dafs VSALVAGING error code

DAFS introduced the VSALVAGING error code which is returned when a vnode
cannot be put and a volume has been scheduled to be salvaged.

Update the afsfileprocs to not assert on VSALVAGING, as well as the
VSALVAGE error code.

For example, VPutVnode() and VVnodeWriteToRead() may call
VRequestSalvage_r() which will set the error code to VSALVAGING when a
salvage is requested.

This was noticed during a code inspection.

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

5 years agobozo: Constify bozo_Log 'format' argument
Andrew Deason [Mon, 10 Feb 2014 22:23:07 +0000]
bozo: Constify bozo_Log 'format' argument

We clearly do not need to modify the format string; declare it const.
This makes the signature of bozo_Log identical to FSLog, which can
make it easier to use these functions interchangeably.

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

5 years agofssync-debug: close test connection
Mark Vitale [Wed, 20 Nov 2013 20:05:21 +0000]
fssync-debug: close test connection

A valid fssync-debug query <volid> command issued against
a DAFS fileserver will produce the following error messages in FileLog:

SYNC_getCom:  error receiving command
FSYNC_com:  read failed; dropping connection (cnt=1)

Routine dafs_prolog() issues a tentative FSYNC_VOL_LISTVOLUMES operation
to test for the presence of a DAFS fileserver.  If DAFS is detected,
we then call dafssync-debug for the original requested operation.
However, the FSYNC connection for the tentative LISTVOLUMES operation
is never closed. This results in the errors when the command completes.

Close the test connection.

Change-Id: I3c987289408407ba38cd184b7518e72ee1ae9cfc
Reviewed-on: http://gerrit.openafs.org/10476
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

5 years agoAttempt to clean up tvolser dependencies
Benjamin Kaduk [Tue, 12 Aug 2014 19:13:46 +0000]
Attempt to clean up tvolser dependencies

The volserver only needs vl_errors.c to be locally generated, not
vlserver.h; in fact, the only consumers of vlserver.h in src/volser/
consume it via afs/vlserver.h.

Instead of reaching over to ../volser for the generated volerr.c,
generate our own local copy, as well as the volser.h generated from
the same error table -- volser.h is included with double-quotes from
the volser sources.

Add the appropriate dependencies on volser.h, and remove the unneeded
dependencies on vlserver.h

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