LINK_MAX was removed in r327598. When we don't have a LINK_MAX, just
use its value from before it was removed (32767).
Change-Id: Id66a2ba8b7085b392def1d17eace22c7f742e1a4
Reviewed-on: https://gerrit.openafs.org/13860
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
syscall_register/syscall_deregister were effectively removed in
r329647. Use syscall_helper_register/syscall_helper_unregister
instead, which have existed since r205321 in FreeBSD 9.
Change-Id: I2d5e3101024a44c18395d7eb95c644df6005e0aa
Reviewed-on: https://gerrit.openafs.org/13858
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
FreeBSD 12 (r328417) removed the deprecated compatibility macros
MALLOC and FREE. Convert our users to just use the normal malloc and
free, so we can build.
FreeBSD 12 (r334545) also changed malloc() into a macro, which breaks
our own malloc macro in our hcrypto config.h. To fix this, just undef
malloc, if it's already a macro.
Change-Id: I5c683e3834710a60cc78476cbaa7203218b11fe0
Reviewed-on: https://gerrit.openafs.org/13856
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
FreeBSD 12 changed how network interfaces and network addresses are
linked together; we're supposed to use CK_STAILQ_FOREACH to traverse
them now, instead of TAILQ_FOREACH. To try to keep this change
simpler, introduce a new macro, AFS_FBSD_NET_FOREACH, which picks the
right macro to use.
Based on a commit by tcreech@tcreech.com.
Change-Id: Iab0f93701dd60dcf4237a7fbbf461019bceaeb38
Reviewed-on: https://gerrit.openafs.org/13999
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When traversing the list of network interfaces, or the list of
addresses for a network interface, we're supposed to lock the relevant
resource with IFNET_RLOCK, if_addr_rlock, or IN_IFADDR_RLOCK. Add
these locks around our code that examines network interfaces, to
avoid issues if the interface or address list changes while we're
traversing them.
While we're doing this, move around some "AFS_DARWIN_ENV ||
AFS_FBSD_ENV" ifdefs, since these were getting a bit hard to read.
This commit adds some duplicated code, but the result should be easier
to follow.
Also for FreeBSD 12, we must be in NET_EPOCH_ENTER when calling
ifa_ifwithnet/rx_ifaddr_withnet (it panics if we don't, with
INVARIANTS). Add the needed NET_EPOCH_ENTER/EXIT calls, but do so a
bit higher up the call stack, since the returned structures are
potentially no longer valid after we NET_EPOCH_EXIT. Since this means
we're calling these in a few places in libafs, create a couple of rx
abstractions (RX_NET_EPOCH_ENTER) to handle the relevant ifdefs.
[adeason@dson.org: Various adjustments to locking calls; splitting up
DARWIN/FBSD ifdefs.]
Change-Id: I65d63b99b6f6ef3254325cce9338be27ef78478c
Reviewed-on: https://gerrit.openafs.org/13998
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Since the original IBM code import, rx statistics for counting incoming
packet types have inadvertently omitted RX_PACKET_TYPE_VERSION packets.
This results in rxdebug -rxstats always reporting 0 for the number of
version packets read.
A similar bug causes a debugging facility in rxi_ReceivePacket to emit
"*UNKNOWN*" instead of "version" for version packets.
Correct all versions of the offending logic.
Change-Id: I9e713eb595b75ef06a347a1c05edb9efffd0b366
Reviewed-on: https://gerrit.openafs.org/14519
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
A handful of printf's requested more args than they were given. The
missing args are now provided. (via cppcheck)
Change-Id: I3d2bfd1b68a3518ee4c8a65f02446a2bae85d926
Reviewed-on: https://gerrit.openafs.org/13155
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Some platforms use the GNU target triplet as a prefix to the toolchain
utilities (e.g. x86_64-pc-linux-gnu-as) to allow the use of alternative
toolchains, cross-compiling, etc.
The Gentoo Linux distribution has a mode of building packages
(-native-symlinks) where the toolchain utilities only exist as their
prefixed names (e.g. 'as' does not exist, but 'x86_64_pc-linux-gnu-as'
does). This results in configure failing to locate the tools when using
AC_CHECK_PROGS. (Gentoo uses the --host and --build configure
parameters to specify the prefix names for the tools).
Replace AC_CHECK_PROGS with AC_CHECK_TOOL for the toolchain related
commands 'as' and 'ld'.
AC_CHECK_TOOL works like AC_CHECK_PROGS but it will also look for
the program with a prefix (specified by using configure's --host
parameter).
Note: libtool.m4 runs AC_CHECK_TOOL for ar.
Change-Id: I8005c765d213b7d1d6292a7dd80f10a3d0e2ec68
Reviewed-on: https://gerrit.openafs.org/14544
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
For kaprocs, size of 'caller.userID.name' is defined by a different macro
than size of 'name'. They can become out of sync, so restricting to
size of dest.
For scout and afsmon-win, the if statement determined that the string
was longer than the dest buffer. So we are using the size of the buffer
as the max length to setup for truncation.
(via cppcheck)
Change-Id: I38a2bff1d59d17ea02e136c35cd5b132a75a8ed8
Reviewed-on: https://gerrit.openafs.org/13163
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This adds checks for some invocations of localtime() to avoid possible
NULL dereference. (via facebook-infer)
Change-Id: I2b779d8f60c032563eb4ee3cebe20b14afbb0fa3
Reviewed-on: https://gerrit.openafs.org/13206
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This is primarily a sanity check (identified by clang-tidy).
Change-Id: I92d05fdfed0e32c0e39cc2f8ce412b613c0a38fc
Reviewed-on: https://gerrit.openafs.org/13333
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Systems under memory pressure may fail to realloc(). If so, the pointer
to the old memory is lost, but not released. This code catches the
pointer before hand to ensure the memory isn't leaked. (via cppcheck)
Change-Id: I4c5a11c1daf4e78f7ffde71af0175d9106f6c3cd
Reviewed-on: https://gerrit.openafs.org/13156
Reviewed-by: Joe Gorse <jhgorse@gmail.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Provide statistical information via the solaris kstat framework. Data
can be examined with the kstat tool or the kstat userspace api.
The kstat module is called openafs. Three kstat names are provided. The
"param" name provides cache manager parameters as given by the cmdebug
-cache program.
# kstat -m openafs -n param
The "cache" name provides cache manager statistics as given by the
xstats plus some additional cache related stats. The "cache" name also
provides the libafs kernel module version string and the current local
cellname.
# kstat -m openafs -n cache
The "rx" name provides general rx statistics as given by rxdebug -rxstat.
# kstat -m openafs -n rx
Change-Id: Ic07e3b58fa5c79145f12f8519a6f7fce0d91138b
Reviewed-on: https://gerrit.openafs.org/13170
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, the AFS_MOUNT_AFS #define is used to mean two completely
different things:
- The string "afs", corresponding to the first argument to mount(2) on
many platforms and some related calls inside libafs (e.g.
getnewvnode() on FBSD).
- An integer identifying the AFS filesystem (e.g. gfsadd() on AIX).
Depending on the platform and the build context (UKERNEL vs KERNEL),
AFS_MOUNT_AFS gets defined to one of those two things. This is very
confusing, and has led to mistakes in the past, such as those fixed in
commit 446457a1 (afs: Set AFS_VFSFSID to a numerical value).
To avoid such confusion, get rid of AFS_MOUNT_AFS completely, and
replace it with two new symbols:
- AFS_MOUNT_STR, the string "afs".
- AFS_FSNO, the integer given to gfsadd() et al.
When AFS_MOUNT_AFS is split this way, AFS_MOUNT_STR then is always
defined to the same value, so remove it from the param.h files for our
platforms. Instead, define it in afs.h for libafs use, and in
afsd_kernel.c (the only place outside of src/afs that uses it).
Also remove the logic for conditionally defining MOUNT_AFS from the
param.h files, moving the logic to the same locations as
AFS_MOUNT_STR.
Note that this commit removes the numeric definition for AFS_MOUNT_AFS
in param.sgi_65.h (aka AFS_FSNO). We never actually used this value,
since AFS_FSNO is not used on IRIX; instead, we tend to use the
'afs_fstype' global instead of a constant number.
Change-Id: I6cbf051dc938cd1c456cbe236c0afe99a3c3dd87
Reviewed-on: https://gerrit.openafs.org/14323
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Since commit 91713206 (Remove LINUX24 from src/afs),
AFS_PARISC_LINUX24_ENV is never defined. Remove references to it.
Change-Id: I854701f26ec86b9b9fb99dc57c36f04f78a09517
Reviewed-on: https://gerrit.openafs.org/14472
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Linux 5.11 removed the TIF_IA32 thread flag with commit:
x86: Reclaim TIF_IA32 and TIF_X32 (8d71d2bf6efec)
The flag TIF_IA32 was being used by openafs to determine if the task was
handling a syscall request from a 32 bit process. Building against a
Linux 5.11 kernel results in a build failure as TIF_IA32 is undefined.
The function 'in_compat_syscall' was introduced in Linux 4.6 as
the preferred method to determine if a syscall needed to handle a
compatible call (e.g. 32bit application).
To resolve the build problem, use 'in_compat_syscall' if present (Linux
4.6 and later) to determine if the syscall needs to handle a
compatibility mode call.
Add autoconf check for in_compat_syscall.
Notes about in_compat_syscall:
In Linux 4.6 'in_compat_syscall' was defined for all architectures with
a generic return of 'is_compat_task', but allows architecture specific
overriding implementations (x86 and sparc).
At 4.6 (and later), the function 'is_compat_task' is defined only for
the following architectures to return:
Arch Returns
======= ==============================
arm64 test_thread_flag(TIF_32BIT);
mips test_thread_flag(TIF_32BIT_ADDR)
parisc test_ti_thread_flag(task_thread_info(t), TIF_32BIT)
powerpc is_32bit_task()
s390 test_thread_flag(TIF_31BIT)
sparc test_thread_flag(TIF_32BIT)
If the Linux kernel is not built with compat mode, is_compat_task and
in_compat_syscall is set to always return 0
Linux commit that introduced in_compat_syscall:
compat: add in_compat_syscall to ask whether we're in a compat syscall
(5180e3e24fd3e8e7)
Change-Id: I59deebfe5d8cddaf845b15ef69e65a684a961280
Reviewed-on: https://gerrit.openafs.org/14499
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Refactor the preprocessor checks for determining the method to test for
32bit compatibility (64bit kernel performing work for a 32bit task) into
a common inline function, 'afs_in_compat_syscall' that is defined in
LINUX/osi_machdep.h. Update osi_ioctl.c and afs_syscall.c to use
afs_in_compat_syscall.
Add include afs/sysincludes into osi_machdep.h to ensure linux/compat.h
is pulled for the functions called in afs_in_compat_syscall.
Change-Id: I6610cc19fedd909de8e8941ded05ed1608e52403
Reviewed-on: https://gerrit.openafs.org/14500
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit 8b6ae289 (LINUX: Avoid lookup ENOENT on fatal signals) added a
configure test for fatal_signal_pending(). However, this check fails
incorrectly ever since Linux 4.11, because fatal_signal_pending() was moved
from linux/sched.h to linux/sched/signal.h in Linux commit 2a1f062a
(sched/headers: Move signal wakeup [...]). Fix this by including
linux/sched/signal.h if we have it during the configure test.
A false negative on this configure test doesn't break the build, but
it disables one of our safeguards preventing incorrect negative
dentries at runtime. The function fatal_signal_pending() hasn't
changed in quite some time (except for what header it lives in); it
was introduced in Linux 2.6.25 via Linux commit f776d12d (Add
fatal_signal_pending). So to try to avoid this mistake again in the
future, make it so a missing fatal_signal_pending() breaks the build
if we're on Linux 2.6.25+.
Change-Id: Id0b91b2f24e2ea87c9c900076ab7ab1fcab3d304
Reviewed-on: https://gerrit.openafs.org/14508
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Clean up the indentation of preprocessor statements
Remove commented out code.
Change-Id: I37fec6f15a8972651ef05aa00580a2628e0a1a46
Reviewed-on: https://gerrit.openafs.org/14471
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Clean up the indentation of preprocessor statements, add #endif comments
where helpful.
Clean up whitespace in code indentation.
Change-Id: I5e6eb3d8ad2688f2b5a56b760d1c1f031f6ca9ec
Reviewed-on: https://gerrit.openafs.org/14470
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
rx_prototypes.h has an extern definition for rxk_ListenerProc. That
function was removed in commit e261238470ed28ee7c1068d914de171b34033e09
'SOLARIS: Perform daemon syscalls as kernel threads'
Remove the extern definition/reference in rx_prototypes.h
Change-Id: I9f845f24f993f5a5cfb353e594ecdf3ec6de73ab
Reviewed-on: https://gerrit.openafs.org/14038
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Clean up the indentation of preprocessor statements, add #endif comments
where helpful.
Clean up whitespace in code indentation.
Change-Id: Id7eeeabfea52c99f783e23468cfc89ce9ed8eae5
Reviewed-on: https://gerrit.openafs.org/14469
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Running clang's static analysis revealed a possible divide by zero
condition.
There is a random chance of the divide by zero.
- it has to be in the first pass of the main loop testing events
(counter = 0)
- 90% chance path : if (counter < (NUMEVENTS -1) &&
random() % 10 == 0) -- needs to be false
- 25% chance path: if (random() % 4 == 0) -- needs to be true
if the above conditions are met, the statement
int victim = random() % counter
is a divide by zero.
Add a check to ensure the counter is greater than zero. Add a comment
to document that only events prior to the current event are randomly
selected.
Change-Id: I4b4e73fa324842bb504bcc952079af15aea8a6a3
Reviewed-on: https://gerrit.openafs.org/14501
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The rx_nextCid global has been an unsigned type since
http://gerrit.openafs.org/11106 (which was actually merged before
the refactoring of overflow check to avoid signed integer overflow)
and thus there is no need to avoid signed overflow. The per-connection
cid has been unsigned since the IBM import.
The natural unsigned behavior on overflow of wrapping is the desired
behvaior here, so just remove the extra logic and always increment.
Change-Id: I2d9fd24082b762eb871199da3ac1cc0983764585
Reviewed-on: https://gerrit.openafs.org/14496
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
The overflow handling in update_nextCid() produces a rx_nextCid
value of 0x80000001 which itself is out of the valid range. When
used to construct the first call of a new connection the connection
id for the call becomes 0x80000002, and all subsequent connections
also trigger the overflow handling and thus also receive connection
id 0x80000002.
If the same connection id is used for multiple connections from
the same endpoint the accepting rx peer will be very confused.
When authenticated connections are used, the CHALLENGE/RESPONSE
will fail because of a mismatch in the connection's callNumber
array.
If an initiator makes only a single connection to a given rx peer,
that connection would succeed, but once multiple connections are
initiated all communication from a broken initiator to any rx peer
will fail.
The incorrect overflow calculation was introduced by
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core").
This change corrects the overflow value to become
1 << RX_CIDSHIFT
Change-Id: If36e3aa581d557cc0f4d2d478f84a6593224c3cc
Reviewed-on: https://gerrit.openafs.org/14492
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core") introduced the use of RAND_bytes()
to generate the initial 'rx_nextCid' but failed to remove the
rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT;
assignment inherited from IBM/Transarc.
At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation
overflows the value CID range. This triggers broken overflow
logic in update_nextCid().
Change-Id: Ib7283def1ded9792d394133a3969a6d86f3a6123
Reviewed-on: https://gerrit.openafs.org/14491
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Since the original IBM code import, the 'vos partinfo' error message
blames the wrong command, 'vos listpart':
$ vos partinfo afs01.sinenomine.net
<unknown>: Could not get afs tokens, running unauthenticated.
Could not fetch the list of partitions from the server
Possible communication failure
Error in vos listpart command.
Possible communication failure
Correct the error message to specify 'vos partinfo' instead.
Change-Id: I966dee8c679db89c7ed5ce21d31ebc7424803cf2
Reviewed-on: https://gerrit.openafs.org/14489
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
While salvaging a RW volume, salvager may segfault if it encounters an
orphaned directory with a parent vnode that does not exist. For
example, if the large vnode index contains a maximum vnode of 2901, any
parent vnode encountered that is larger than 2901 will result in an
out-of-bounds reference to our vnode essence array, leading to a
segfault or undefined behavior.
Modify the logic to check for out-of-bounds parent vnodes, and log them
rather than segfaulting.
Change-Id: I49f53935830fbb428fe0bff04c33248d3806a4b2
Reviewed-on: https://gerrit.openafs.org/14385
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The GetDE RPC has been commented out from afscbint.xg effectively
since it was introduced, but we still define the SRXAFSCB_GetDE server
stub for it.
This is useless, but also potentially dangerous, since the stub
routine just returns success, without populating the output arguments.
One of the output arguments is a string, and so if this RPC is
actually run, the rxgen-generated server code will try to xdr_string()
that string. Since we never set it to anything, this will result in
xdr_string trying to dereference a NULL pointer.
None of this actually happens currently, since the GetDE RPC is
commented out. But to avoid the above situation if it's ever
uncommented, remove the useless SRXAFSCB_GetDE function.
Change-Id: I6ef478ee69a8de1ac14baa86aa82489181d67452
Reviewed-on: https://gerrit.openafs.org/14488
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit 339167ef (Remove dead code) meant to remove the '#ifdef notdef'
block in here, but we accidentally also removed the subsequent '#ifdef
PC'.
This file may not be very important, since WINNT still builds with
this mistake, but an unbalanced #ifdef is potentially super confusing,
so fix it.
Change-Id: I100792830e1bed0af08bcb81a34bb185b2c6358a
Reviewed-on: https://gerrit.openafs.org/14487
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Each server process can log a couple of different warnings about the
server keys found on disk:
- If afsconf_GetLatestKey() returns success (indicating a single-DES
key is present), we call LogDesWarning().
- If afsconf_CountKeys() returns 0 (indicating there are no keys at
all on disk), we log a warning that all authenticated access will
fail.
Currently, the code to do these checks and log the relevant warning is
duplicated across the startup code for nearly every server process. To
avoid this duplication, and to make sure the checks aren't
accidentally skipped for anyone, move these checks to
afsconf_BuildServerSecurityObjects, which every server process calls.
We must add an additional parameter to
afsconf_BuildServerSecurityObjects to handle the different logging
mechanism these servers use, but afsconf_BuildServerSecurityObjects is
declared in a public header (cellconfig.h), and is exported in a
public library (libafsauthent). So to avoid changing a public symbol,
introduce a new variant of the function, called
afsconf_BuildServerSecurityObjects_int. Declare this in a new internal
header, authcon.h.
We don't have easily-usable logging functions for upserver and butc,
so just don't log the warnings for those. For ubik servers, don't
update ubik_SetServerSecurityProcs to use the new function; the
initial call to afsconf_BuildServerSecurityObjects_int in the server's
startup code will cover logging the warning on startup.
Change-Id: I5d5fceefdaf907f96db9f1c0d21ceb6957299a59
Reviewed-on: https://gerrit.openafs.org/10831
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Split out the connection-matching logic in rxi_FindConnection into a
new function called rxi_ConnectionMatch, so we can use it in other
functions in future commits.
This commit should have no visible impact; it is just code
reorganization.
Change-Id: Ibacec68d268977a8a2a3aca172653fc088334da6
Reviewed-on: https://gerrit.openafs.org/13603
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
rxi_SplitJumboPacket doesn't use its 'host', 'port', or 'first'
arguments, and rxi_ReceiveDataPacket only uses its 'host' and 'port'
arguments to pass to rxi_SplitJumboPacket.
Remove these unused parameters from both functions. While we're
changing rxi_SplitJumboPacket anyway, move the declaration for
rxi_SplitJumboPacket to rx_internal.h, so it's no longer in a public
header.
This commit should have no visible impact; it is just code
reorganization.
Change-Id: I16a7f613957d8cd2d415f65fa083e11d8a13edc8
Reviewed-on: https://gerrit.openafs.org/13602
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
We currently never open our receive window to more than 32 packets. If
we received a DATA packet for an unrecognized call with a seq of 33 or
more, the packet is almost certainly from a previously-running call
that we were restarted during.
As described in commit 7b204946 (rx: Avoid lastReceiveTime update for
invalid ACKs) and commit "rx: Avoid new server calls for non-DATA
packets", clients can get confused when we respond to calls in these
situations, so drop the packets instead.
Change-Id: I5b3a699bf245375e92ac97a24ad3638cbb3b8f3c
Reviewed-on: https://gerrit.openafs.org/13876
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit e86eb73e (obsd-vattrs-20040125) introduced an XBSD-specific
check to detect some unchanged attributes. But the #ifdef for XBSD for
the va_uid section was added in the middle of an HPUX-specific block
by mistake.
Move this #ifdef one level higher, so it's actually used on BSD
platforms.
Change-Id: I606f87f21d6c4830ed8bcf50abd6fb5807868ff5
Reviewed-on: https://gerrit.openafs.org/14473
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Normally, a client starts a new Rx call by sending DATA packets for
that call to a server, and rxi_ReceiveServerCall on the server creates
a new call struct for that call (since we don't recognize it as an
existing call).
Under certain circumstances, it's possible for a server to see a
non-DATA packet as the first packet for a call, and currently
rxi_ReceiveServerCall will create a new server call for any packet
type. The call cannot actually proceed until the server receives data
from the client (and goes through the challenge/response auth
handshake, if needed), but usually this is harmless, since the
existence of any packets for a particular call channel indicate that
the client is trying to run such a call. The server will respond to
the client with ACKs to indicate that it is missing the needed DATA
packet(s), and the client will send them and the call can proceed.
However, if a call is in the middle of running when the server is
restarted, the client may be sending ACKs for a pre-existing call that
the server doesn't know about. In this case, the server generates ACKs
that indicate the server has not received any DATA packets, which may
appear to violate the protocol, depending on the prior state of the
call (e.g. the server appears to try to move the window backwards).
Clients should be able to detect this and kill the call, but many do
not. For many OpenAFS releases before commit 7b204946 (rx: Avoid
lastReceiveTime update for invalid ACKs), the client will get confused
in this situation and will keep the call open forever, never making
progress.
There isn't any benefit to creating a new server call in these
situations, so just ignore non-DATA packets for unrecognized calls, to
avoid stalled calls from such clients. Those clients will not get a
response from the server, and so the call will eventually die from the
normal Rx call timeout.
Change-Id: I565625ba8b6901f9b745124a8816a9ba816c0264
Reviewed-on: https://gerrit.openafs.org/13758
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, we ignore ACK packets in a few cases:
- If the ACK appears to move the window backwards (if firstPacket is
smaller than call->tfirst).
- If the ACK appears to have been received out of order (if
previousPacket is smaller than call->tprev).
- If the ACK packet appears truncated.
In all of these cases, we ignore the ACK packet completely in our ACK
processing code (rxi_ReceiveAckPacket), but we still process the
packet at higher levels (rxi_ReceivePacket). Notably, this means we
update call->lastReceiveTime after rxi_ReceiveAckPacket returns, even
for ACK packets we haven't really looked at.
Normally this does not cause any noticeable problems, because such
packets should either never be encountered, or only consist of a small
number of packets that are mixed in with valid packets.
However, if our peer is a server, and it is restarted in the middle of
a call, our peer may exclusively send us packets that fall into the
above categories. (This does not happen if our peer is a client,
because clients just ignore packets for calls they do not recognize.)
For example:
Consider a call where a client is sending data to a server, and the
server restarts after the client has sent a DATA packet with sequence
number 1000. The server may then start responding to the client with ACKs
with firstPacket set to 1, since the restarted server has no knowledge
of the call's state.
In this case, a firstPacket of 1 is well below where our window was,
so all of the ACKs from the server are ignored. But we keep updating
call->lastReceiveTime for all of these packets, and so the call stays
alive forever until an idle-dead or hard-dead timeout activates (if
any are set).
As another example, consider the case where a client is sending data
to a server, and the server receives a full window of packets (say, 16
packets), has not yet passed any data to the application yet, and the
server restarts. The restarted server then starts responding to the
client with ACKs with firstPacket set to 1, and previousPacket set to
0. We also ignore all of the ACKs from the server in this case,
because even though firstPacket looks sane, it looks like
previousPacket has gone backwards. We still update
call->lastReceiveTime for each ignored ACK we get, keeping the call
alive.
Before commit 4e71409f (Rx: Reject out of order ACK packets) was
introduced in 1.6.0, neither of these issues could occur. That commit
introduced the issue specifically if previousPacket goes backwards;
that is, if the server restarts before firstPacket moves forwards.
Commit 8d359e6d (rx: Remove duplicate out of order ACK check) in 1.8.0
introduced the issue when 'firstPacket' goes backwards, since
previously the FIRSTACKOFFSET-based check caused us to ignore those
packets without updating call->lastReceiveTime. That is, if the server
restarts after firstPacket moves forwards.
In this commit, we still ignore packets in the above cases, but we
also avoid updating lastReceiveTime when we update such packets, to
make sure that we do not keep a call alive solely from receiving these
invalid packets.
Alternatively, we could change our logic to immediately abort calls
where firstPacket moves backwards (since this violates the Rx
protocol), or to not ignore some packets where previousPacket goes
backwards (since these calls may be recoverable). And we could also
skip updating lastReceiveTime for invalid packets of other types. But
for now, this commit just avoids updating lastReceiveTime for invalid
ACK packets, in order to just try to restore our behavior before
1.6.0, while still retaining the benefits of ignoring out-of-order
ACKs. Further changes in this area can potentially be handled
separately by future commits.
Also increment the spuriousPacketsRead counter for packets that we
ignore in this way (which we used to do for some packets before commit
8d359e6d), so we are not entirely silent about ignoring them.
Written in collaboration with mvitale@sinenomine.net.
Change-Id: Ibf11bcb2417d481ab80cf4104f2862d1d6502bf4
Reviewed-on: https://gerrit.openafs.org/13875
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Take some of our existing logic for ignoring invalid ACK packets and
split it out into a separate function, ack_is_valid. This just makes
it easier to add more complex logic in here and write longer comments
explaining the decisions.
Note that the bug mentioned regarding the previousPacket field was
introduced in IBM AFS 3.5, and was fixed in OpenAFS in commit bbf92017
(rx: rxi_ReceiveDataPacket do not set rprev on drop), included in
OpenAFS 1.6.23.
This commit incurs no functional change; it is just code
reorganization.
Change-Id: Idd569c6bc0c475e700935cf86780a04ab24102f4
Reviewed-on: https://gerrit.openafs.org/13874
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
When AFS_RXERRQ_ENV is defined, we currently end up doing something
like this for our sendmsg abstractions:
if (sendmsg(...) < 0) {
while (rxi_HandleSocketError(sock))
;
return error;
}
return success;
This means that when sendmsg() returns an error, we process the socket
error queue before returning an error.
The problem with this is that when we receive an ICMP error on our
socket, it creates a pending socket error that is returned for any
operation on the socket. So, if we receive an ICMP error after trying
to contact any peer, sendmsg() could return an error when trying to
send for any other peer. Even though there is no issue preventing us
from sending the packet, we'll fail to actually send the packet
because sendmsg() returned an error. This effectively causes an extra
outgoing packet drop, possibly delaying the related RPC.
To avoid this, change Rx to retry the sendmsg call when it returns an
error, since the error may be due to an unrelated ICMP error.
To avoid needing to implement this retry loop in multiple places, move
around our sendmsg code for AFS_RXERRQ_ENV, so that the higher-level
function rxi_NetSend performs the retry and checks for socket errors
(instead of the lower-level rxi_Sendmsg or osi_NetSend). Also change
our functions to process socket errors to be more consistent between
kernel and userspace: now we always have rxi_HandleSocketErrors, which
runs a loop around the platform-specific osi_HandleSocketError.
With this commit, osi_HandleSocketError is now required to be
implemented when AFS_RXERRQ_ENV is defined. We hadn't been
implementing this for UKERNEL, so just turn off AFS_RXERRQ_ENV for
UKERNEL.
Thanks to mbarbosa@sinenomine.net for discovering and providing
information about the relevant issue.
Change-Id: Iccceddcd2d28992ed7a00dc308816a0cb1a0195f
Reviewed-on: https://gerrit.openafs.org/14424
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, our pthread version of rxi_Sendmsg uses 'errno' in some
logic if sendmsg fails, but we do so after calling functions that
might alter errno (e.g. fflush).
To make sure we get the correct errno value, save the value of errno
right after sendmsg returns an error. Reorganize this function a bit
to help make the logic easier to follow.
Change-Id: I6bf284bd75edb5404bb6771bb99a9381b0f8654d
Reviewed-on: https://gerrit.openafs.org/14423
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Add the readdir/fidreaddir sub-commands to afsio dump AFS3 directory
objects. This command dumps the raw directory object to stdout. Pipe
the output to a program, such as the afsdump_dirlist program (from the
CMU dumpscan tool kit), to parse the directory object.
Example usage:
afsio readdir -dir /afs/mycell/mypath/somedir | afsdump_dirlist
Change-Id: Ief181b432cdea6a11bbe61e781686ade2795faad
Reviewed-on: https://gerrit.openafs.org/12381
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In order to avoid future bit-rot, always build vol-bless. Also add it
to the clean rule. However, continue to leave it undistributed and
uninstalled by default.
Change-Id: I3d2dc94c28a7feeb20167223655e97538e807ce6
Reviewed-on: https://gerrit.openafs.org/14464
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
A comment in rx_packet.h referred to the size of struct rx_ackpacket,
but the actual structure is spelled with a majuscule 'P'.
Change-Id: Iaf57f098b2e818fe0d492a89347a0a14bc3eb392
Reviewed-on: https://gerrit.openafs.org/14468
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Our LWP version of rxi_Sendmsg can allocate an fd_set, but we don't
free the fd_set if sendmsg() returns certain errors afterwards.
To make sure we go through the same cleanup code for the different
possible error code paths, reorganize the function to go through a
'goto error'-style destructor. This also makes our return codes a bit
more consistent; we should always return -errno now for errors.
Change-Id: I5eaeb7f4ea1d76acc3bd9c52dc258f53f59f631e
Reviewed-on: https://gerrit.openafs.org/14422
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In commit 9ebff4c6 (OPENAFS-SA-2018-001 audit: support butc types),
several new butc-related audit data types were added. In the
AIX-specific audmakebuf() function, the case for the AUD_TSTT type is
missing the actual "case" clause in the code, causing AUD_TSTT types
to be treated as invalid (and so falling through to the
"AFS_Aud_EINVAL" case).
Add the "case" for AUD_TSTT, so it's treated properly on AIX. Note
that the non-AIX printbuf() already handled this properly, so no
changes are needed there.
Change-Id: Ic46c18b503bacb0901ff0a60534f6c45ce3c9a75
Reviewed-on: https://gerrit.openafs.org/14466
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
No functional change is incurred by this commit.
Change-Id: If84ba946d43d67eb6c253462f5826f9a45a2df46
Reviewed-on: https://gerrit.openafs.org/14463
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The vol-bless utility is not built by default and so is subject to
bit-rot. Thus commit 170dbb3ce301329ff127bb23fb588db31439ae8d 'rx: Use
opr queues' overlooked vol-bless.c when adding includes for users of
struct rx_queue.
Add the required #include <rx/rx_queue.h> so vol-bless builds again.
Note to maintainers: this change is only required for 1.8.x and later;
vol-bless builds fine in 1.6.x and earlier releases.
Change-Id: Ia0bb78e3e7dd74b2f65ac07707aced2c81aaa5d9
Reviewed-on: https://gerrit.openafs.org/14462
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
