GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning. With --checking-enabled, this error is causing
testpt.c to fail during compile.
Change the buffer size from 16 bytes to PR_MAXNAMELEN+1 and use snprintf
instead of sprintf. Generate an error message and exit if snprintf
truncates the string.
Reviewed-on: https://gerrit.openafs.org/13663 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a57cc54dfb6789a86ee735360ee44209c1a901a)
Change-Id: I2f8012e7fb4384f3ad877d2c9beb5f00b03716b8
Reviewed-on: https://gerrit.openafs.org/13730 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Tue, 25 Jun 2019 21:39:40 +0000 (15:39 -0600)]
ptserver: Incorrect variable used to print error msg
In testpt.c the variable cdir is used to print the name of the temporary
dir. However at this point in the code cdir is NULL and the variable
tmp_conf_dir contains the actual name that should be used in the error
message.
Flagged as an error when --enable-checking is on and using GCC 9.
Reviewed-on: https://gerrit.openafs.org/13662 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f938f5f248a3cb3f7ac871f5ef45a0e2d043706b)
Change-Id: I1b993ddc2545f90736811e2eb85ba4b3bae6e657
Reviewed-on: https://gerrit.openafs.org/13728 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Fri, 12 Jul 2019 04:07:35 +0000 (21:07 -0700)]
aklog: require opt-in to enable single-DES in libkrb5
Since the introduction of rxkad-k5 in response to OPENAFS-SA-2013-003,
it is not strictly necessary to configure libkrb5 to allow weak crypto
in order to obtain an AFS token. A sufficient amount of time has passed
since then that it is safe to assume that the default behavior is the
more-secure one, and require opt-in for the insecure behavior.
To indicate that the use of single-DES is quite risky, add the
"-insecure_des" argument to both klog and aklog, to gate the
preexisting calls that enable weak crypto/single-DES.
These calls, and the -insecure_des option, may be removed entirely
in a future commit.
Reviewed-on: https://gerrit.openafs.org/13689 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit eaae6eba8ca10ba7a5a20ee0d1b5f91bc2bac6c6)
Change-Id: I197042e12567fa0fed1b6584e85c3f0a520efa4c
Reviewed-on: https://gerrit.openafs.org/13791 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
GCC 7 is producing new warnings due to better compile time analysis.
With --enable-checking v5der.c is failing with 2 errors due to possible
format-truncation in some snprintf calls. The format strings are being
used to format a date and time values from a tm structure.
The actual warnings/errors are being triggered from arithmetic being
performed on the year and month members of the structure. The resulting
values should not exceed the format lengths, but the compilers are still
flagging the statements.
v5der.c is part of the heimdal package that is pulled into the openafs
source tree. v5der.c is not compiled directly but is #included in
ticket5.c
Update ticket5.c to change the severity of the format-truncation
diagnostic to a warning if using GCC 7 (or higher).
Note: since v5der.c is pulled from an external source (heimdal), any
changes to update v5der.c directly would need to be performed upstream.
Reviewed-on: https://gerrit.openafs.org/13661 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 98ca332c4a5ac9e5687fb4fe21b350134bc74d1b)
Change-Id: I1a808060b302549887e529e74bc3805d9431c499
Reviewed-on: https://gerrit.openafs.org/13727 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Stephan Wiesand [Fri, 6 Sep 2019 11:35:02 +0000 (13:35 +0200)]
ptserver: Increase length limit of namelist, idlist, prlist, prentries
An implementation limit of those lists was introduced in commit a0ffea098d8c5c5b46c6bf86a12d28d6e7096685 to prevent using unlimited
amounts of memory in ptserver and the client. Subsequent reports
indicate that the chosen limits are small enough to restrict
functionality currently in use at some sites where membership lists
exceed the current limit. Since this is just an implementation-
defined limit and can freely change from release to release, increase
the threshold by an order of magnitude to preserve functionality for
existing deployments while still retaining some protection against
attacker-controlled excessive memory allocation.
Reviewed-on: https://gerrit.openafs.org/13838 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d1e90b82ebb2685cbac3ecb3fd99136328b35357)
Change-Id: Ifa229179ad6d2962a8d49df6abd1add94fad7259
Reviewed-on: https://gerrit.openafs.org/13844 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 27 Aug 2019 01:33:58 +0000 (20:33 -0500)]
WINNT: Link tbutc against mtafsutil.lib
tbutc uses pthreads, not LWP, so link it against mtafsutil.lib (a
pthread library), and not afsutil.lib (an LWP library).
Reviewed-on: https://gerrit.openafs.org/13822 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7a76f4dc00984d42b0535a8edbedee034ada896f)
Change-Id: I133fff53d1974658ed1fe95e48abd9779a346a4f
Reviewed-on: https://gerrit.openafs.org/13852 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 27 Aug 2019 00:34:19 +0000 (19:34 -0500)]
rx: Export rx_GetCallStatus
Commit 59d3a8b8 (vos: restore status information to 'vos status')
added the function rx_GetCallStatus to Rx, and used it in the
volserver, but didn't add the function to our .sym and .exp files,
causing a linker error on at least WINNT.
Add the function to the relevant .sym/.exp files, so we can link on
all platforms.
Change-Id: I859ac6d04d8a21eb6f8b4ba3f3720ca318e91334
Reviewed-on: https://gerrit.openafs.org/13820 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c3716b3d7e32f47b084657e163b029e9f1756fa4)
Reviewed-on: https://gerrit.openafs.org/13851 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 23:14:48 +0000 (18:14 -0500)]
WINNT: Link butc against audit
Since commit c43169fd (OPENAFS-SA-2018-001 Add auditing to butc server
RPC implementations), butc references symbols from audit. So add audit
to our libraries to link against, so we can link butc on WINNT.
Reviewed-on: https://gerrit.openafs.org/13818 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e4b689e8c7cb39b72854dd38b6a92134591c8bca)
Change-Id: Ib27755730178afbbd85e3aad265c1f956b3785ef
Reviewed-on: https://gerrit.openafs.org/13850 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 5 Nov 2019 16:50:01 +0000 (10:50 -0600)]
afs: Avoid giving wrong 'tf' to afs_InitVolSlot
Commit 75e3a589 (libafs: afs_InitVolSlot function) split out a bit of
our code that initializes a struct volume into the afs_InitVolSlot
function. However, it caused us to almost always pass a non-NULL 'tf'
to afs_InitVolSlot, even if the target volume was not found.
That is, before that commit, our code roughly did this:
The reason for the extra 'j != 0' check after the loop is to see if we
hit the end of the volume hash chain, or if we actually found a
matching 'tf' in the loop.
And after that commit, the code did this:
for (...; j != 0; j = tf->next) {
...;
if (j != 0) {
tf = &staticVolume;
if (tf->volume == volid)
break;
}
}
if (tf) {
use_tf_data();
} else {
use_blank_data();
}
The check for 'j != 0' was moved to inside the for loop, but 'j' is
always nonzero in the loop (otherwise, the for() would exit the loop).
This means that if we didn't find a matching 'tf' in the loop, our
'tf' would be non-NULL anyway, and so we'd initialize our volume slot
from just the last entry in the hash chain.
This means that for volumes that are not found in the VolumeItems
file, our struct volume will probably be initialized with arbitrary
data from another volume, instead of being initialized to the normal
defaults (the 'else' clause in afs_InitVolSlot).
This means that the 'dotdot' entry for the volume may be wrong, and so
we may report the wrong parent dir for the root of a volume. However,
the 'dotdot' entry should be fixed when the volume root is accessed
via a mountpoint, so any such issue should be temporary. And of
course, on some platforms (LINUX) we don't ever use the 'dotdot'
information for a volume, and even on other platforms, often resolving
the '..' entry is handled by other means (e.g. shells often calculate
it themselves). But some 'pwd' calculations and other '..' corner
cases may be affected.
To fix this, change the relevant loop so that we only set 'tf' to
non-NULL when we actually find a matching entry.
Reviewed-on: https://gerrit.openafs.org/13933 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a9078c6bbf51720a5eacf7e6ba21443e5103eee)
Change-Id: Ib1e7519db8f844872c4b88b54978f358ff7b299e
Reviewed-on: https://gerrit.openafs.org/13937 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Tue, 17 Sep 2019 19:14:44 +0000 (15:14 -0400)]
viced: consistently enforce host thread quota for ICBS(3)
From time to time, the fileserver may issue potentially long-running
RXAFSCB_* RPCs back to a host (client). If these are holding h_Lock_r
(host->lock) while running, they may cause other service threads for the
same host (client) to block.
In order to prevent a given host from tying up too many service threads
in this way, the fileserver enforces a quota limiting how many threads
can be waiting for h_Lock_r on a particular host while waiting for one
of the following RPCs to complete:
- RXAFSCB_TellMeABoutYourself (TMAY)
- RXAFSCB_WhoAreYou
- RXAFSCB_ProbeUuid
- RXAFSCB_InitCallBackState (ICBS)
- RXAFSCB_InitCallBackState3 (ICBS3)
Note: Although some of these RPCs are relatively lightweight, they may
still experience network delays.
This quota is enforced by calling h_threadquota() in h_Lookup_r and
h_GetHost_r. The quota check is enabled for a given host by turning on
host->hostFlags HWHO_INPROGRESS for the duration of the RXAFSCB_* RPC.
The quota check is only needed, and should only be enabled, when the RPC
is issued while h_Lock_r is held.
However, there are a few paths to ICBS(3) where h_Lock_r is held but
HWHO_INPROGRESS is not set. A delay in those paths may allow a host to
consume an unlimited number of fileserver threads. One such path
observed in a field report was SRXAFS_FetchStatus -> CallPreamble ->
BreakDelayedCallBacks_r -> RXAFSCB_ICBS3.
Instead, enable host thread quotas for all remaining unregulated ICBS(3)
RPCs.
Reviewed-on: https://gerrit.openafs.org/13873 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit aefc4c4f46e13f59b4cbe043e1a2a6f4ed99e076)
Change-Id: If3883a152078bba9995e0c8a13ab31788db6347f
Reviewed-on: https://gerrit.openafs.org/13893 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 21:08:31 +0000 (16:08 -0500)]
kauth: Move COUNT_REQ to beginning of block
Commit b604ee7a (OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry
information leak) added a memset in kamListEntry before COUNT_REQ, but
COUNT_REQ declares a local variable. This breaks the WINNT build,
because we must declare variables at the beginning of a block.
To fix this, just swap the two lines.
Reviewed-on: https://gerrit.openafs.org/13815 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b9b5385e6a04dcacd180f33e39495c7909fe4df3)
Change-Id: Id9c1fd67e4614f8f433415486e107ecb4bd0d708
Reviewed-on: https://gerrit.openafs.org/13849 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 18:13:28 +0000 (13:13 -0500)]
WINNT: Build bubasics before audit
Commit 9ebff4c6 (OPENAFS-SA-2018-001 audit: support butc types) made
src/audit require the butc.h header, and updated Makefile.in to
reflect this. However, this dir is also built on WINNT, and the
NTMakefile was not updated to reflect this dependency. As a result, we
might fail to build src/audit on WINNT, since butc.h may not exist
yet, and we get an error like:
cl [...] /c audit.c
audit.c
cl : Command line warning D9025 : overriding '/W4' with '/W3'
audit.c(27) : fatal error C1083: Cannot open include file: 'afs/butc.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.EXE' : return code '0x2'
To fix this, move 'bubasics' to be made before 'audit' in NTMakefile,
so butc.h is available when we build 'audit'.
Reviewed-on: https://gerrit.openafs.org/13813 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9eeb3ec09f5421ceab2be415a193bb3a3c44925f)
Change-Id: If36de5664ea0eb7208810c224d30092f0a4d1745
Reviewed-on: https://gerrit.openafs.org/13848 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 8 Jul 2019 19:49:23 +0000 (14:49 -0500)]
afs: Avoid panics in afs_InvalidateAllSegments
Currently, afs_InvalidateAllSegments panics when afs_GetValidDSlot
fails. We panic in these cases because afs_InvalidateAllSegments
cannot simply return an error to its callers; we must invalidate all
segments for the given vcache, or we risk serving incorrect data to
userspace as explained in the comments.
Instead of panicing, though, we could simply sleep and retry the
operation until it succeeds. Implement this, retrying every 10
seconds, and logging a message every hour that we're stuck (in case
we're stuck for a long time).
When we retry the operation, do so in a background request, to avoid a
somewhat common situation on Linux where we always get I/O errors from
the cache when the calling process has a SIGKILL pending. Create a new
background op for this, BOP_INVALIDATE_SEGMENTS.
With this, the relevant vcache will be effectively unusable for the
entire time we're stuck in this situation (avc->lock will be
write-locked), but this is at least better than panicing the whole
machine.
Reviewed-on: https://gerrit.openafs.org/13677 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 3be5880d1d2a0aef6600047ed43d602949cd5f4d)
Change-Id: Iba1cde70a4d5e919fedfe27d0540878113a369e4
Reviewed-on: https://gerrit.openafs.org/13847 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void). Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.
Reviewed-on: https://gerrit.openafs.org/13726 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d6262c3f391e4176bec207fd0e8d4d6091a7f4e2)
Change-Id: I4544c37591bb68ff6bbe345192490bb79c843fc5
Reviewed-on: https://gerrit.openafs.org/13749 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sun, 3 Feb 2019 01:52:26 +0000 (19:52 -0600)]
libadmin: appease clang -Wsometimes-uninitialized
clang thinks that 'time' can be used uninitialized:
bos.c:1472:9: error: variable 'time' is used uninitialized whenever 'if' condition is
false [-Werror,-Wsometimes-uninitialized]
if (as->parms[TIME].items) {
^~~~~~~~~~~~~~~~~~~~~
bos.c:1478:57: note: uninitialized use occurs here
if (!bos_ExecutableRestartTimeSet(bos_server, type, time, &st)) {
^~~~
bos.c:1472:5: note: remove the 'if' if its condition is always true
if (as->parms[TIME].items) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
bos.c:1445:5: note: variable 'time' is declared here
bos_RestartTime_t time;
^
but in this command description, the TIME argument is required.
Add a never-triggered error exit to appease the compiler when
--enable-checking is activated.
Reviewed-on: https://gerrit.openafs.org/13476 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 453060c27a5d33d3c27128d169298f9d66d06f1a)
Change-Id: Iac80d4ec7c2a33dcb470de2daedf693c20b96b00
Reviewed-on: https://gerrit.openafs.org/13745 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sun, 3 Feb 2019 01:48:20 +0000 (19:48 -0600)]
uss: signed/unsigned char fallout
When char is signed, assigning 255 to a variable of type char changes
the value, which causes clang to emit a warning and fail the
--enable-checking build.
Reviewed-on: https://gerrit.openafs.org/13475 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7c15e6efe62fb3fe1970c56331df09b257abf6d9)
Change-Id: I3dd374582b57e46460ea80ead75913948c2d2262
Reviewed-on: https://gerrit.openafs.org/13744 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:10:29 +0000 (17:10 -0600)]
dumpscan: appease gcc8 -Wformat-overflow
gcc does not benefit from our external knowledge that tm_year is
tightly bounded, and thinks it could still be in the range
[-2147481748, 2147483647], which would overflow our string buffer.
The function in question does not have error handling in place, so
rather than adding some or trying to assert the proper bounds, just
use a slightly larger buffer for safety.
Reviewed-on: https://gerrit.openafs.org/13472 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8f03ff3bdd8eb9f4557cdb7054aee9b8ea432160)
Change-Id: I05c8d998c6d40118a1bde923e346cddbdfa4192b
Reviewed-on: https://gerrit.openafs.org/13741 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:02:08 +0000 (17:02 -0600)]
scout: band-aid -Wformat-truncation
gcc8 gets pretty confused about the bounds on these things (presumably
due to our alignment options) and thinks this could potentially be a huge
string. Check for truncation to appease the compiler, instead of trying
to ensure that the buffer is big enough.
Reviewed-on: https://gerrit.openafs.org/13470 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit df8534909fdc1fa8417aa788c0fa71c5dbe7eb30)
Change-Id: Idf3a2f32ba4630a7d11b2c0664c6dd9b694eb7db
Reviewed-on: https://gerrit.openafs.org/13739 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 20:43:04 +0000 (14:43 -0600)]
vlserver: use large enough buffer for rxinfo string
The "[dotted-quad] rxkad:name.inst@cell" construct can be as large as
(3*4+3)+7+3*64+2+1 == 217 characters (including trailing NUL); size
our buffer accordingly to avoid the risk of truncation.
Reviewed-on: https://gerrit.openafs.org/13466 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 584b0f2b6b4391c0c879352bb1786c0f267666c9)
Change-Id: Ia11e685ec17f34a9a8fdc42d392b8a2677f63696
Reviewed-on: https://gerrit.openafs.org/13735 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sun, 27 Oct 2019 18:25:33 +0000 (11:25 -0700)]
Configure --without-ctf-tools to fix kmod builds when ctfutils are installed
In theory having the CTF information present might be usable at some point in
the future, but the benefits are unclear at present, and we would need to
expend some engineering effort to get a usable cc-wrapper available for the
purposes of the module builds.
Currently, SVOTE_Debug/SVOTE_DebugOld examine some ubik internal state
without any locks, because the speed of these functions is more
important than accuracy.
However, one of the pieces of data we examine is ubik_currentTrans,
which we dereference to get ubik_currentTrans->type. ubik_currentTrans
could be set to NULL while this code is running, so there is a small
chance of this code causing a segfault, if SVOTE_Debug() is running
when the current transaction ends.
We only ever initialize ubik_currentTrans as a write transation (via
SDISK_Begin), so this check is pointless anyway. Accordingly, skip the
type check, and always assume that any active transaction is a write
transaction. This means we only ever access ubik_currentTrans once,
avoiding any risk of the value changing between accesses (and we no
longer need to dereference it, anyway).
Note that, since ubik_currentTrans is not marked as 'volatile', some C
compilers, with certain options, can and do assume that its value will
not change between accesses, and thus only fetch the pointer value once.
This avoids the risk of NULL dereference (and thus, crash, if pointer
stores/loads are atomic), but the value pointed to by ubik_currentTrans->type
would be incorrect when the transaction ends during the execution of
SVOTE_Debug().
Reviewed-on: https://gerrit.openafs.org/13915 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6ec46ba7773089e1549d27a0d345afeca65c9472)
Change-Id: I634ddb27e7a8dbe5c9d1dacdc83070efa470b50b
Reviewed-on: https://gerrit.openafs.org/13918 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
This is done for any input or output arguments, but only for types we
need to free afterwards (arrays, usually). We do not do this for
simple types, like single flat structs. In the above example, we do
this for the arrays FidsArray, StatArray, and CBArray, but 'Sync' is
not initialized to anything.
If some server RPC handlers never set a value for an output argument,
this means we'll send uninitialized stack memory to our peer.
Currently this can happen in, for example,
MRXSTATS_RetrieveProcessRPCStats if 'rxi_monitor_processStats' is
unset (specifically, the 'clock_sec' and 'clock_usec' arguments are
never set when rx_enableProcessRPCStats() has not been called).
To make sure we cannot send uninitialized data to our peer, change
rxgen to instead 'memset(&arg, 0, sizeof(arg));' for every single
parameter. Using memset in this way just makes this a little simpler
inside rxgen, since all we need to do this is the name of the
argument.
With this commit, the rxgen-generated code for the above example now
looks like this:
When the server routine for implementing the RPC results a non-zero
value into z_result, the call will be aborted. However, before we
abort the call, we still call the xdr_* routines with XDR_ENCODE for
all of our output arguments. If the call has not already been aborted
for other reasons, we'll serialize the output argument data into the
Rx call. If we push more data than can fit in a single Rx packet for
the call, then we'll also send that data to the client. Many server
routines for implementing RPCs do not initialize the memory inside
their output arguments during certain errors, and so the memory may be
leaked to the peer.
To avoid this, just jump to the 'fail' label when a nonzero 'z_result'
is returned. This means we skip sending the output argument data to
the peer, but we still free any argument data that needs freeing, and
record the stats for the call (if needed). This makes the above
example now look like this:
Andrew Deason [Wed, 17 Oct 2018 21:35:36 +0000 (16:35 -0500)]
Remove one more automake VERSION reference
The configure summary was still referencing the old automake-specific
VERSION var. Use the autoconf PACKAGE_VERSION var instead, so this
actually shows our version.
Reviewed-on: https://gerrit.openafs.org/13360 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0f65b40b24599d58cf30bfd47fae83ab54e1416a)
Change-Id: I5bd9399acc6e4c6dd19b94198354b600f35bee15
Reviewed-on: https://gerrit.openafs.org/13790 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 11 Oct 2018 05:18:17 +0000 (00:18 -0500)]
Remove automake autoconf vars
Commit 4706854f (autoconf: updates and cleanup) removed our invocation
of AM_INIT_AUTOMAKE, which defines the output variables PACKAGE and
VERSION. Several files in our build system are still referencing
@PACKAGE@ and @VERSION@, though, leaving them un-substituted. This
most easily is seen as the AFSVersion version string remaining as
"@VERSION@" when the tree is built without git, but it also affects
some packaging in the tree.
Remove references to @VERSION@ and @PACKAGE@, replacing them with
their autoconf equivalents @PACKAGE_VERSION@ and @PACKAGE_TARNAME@.
Reviewed-on: https://gerrit.openafs.org/13357 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2f2c2ce62aa17ecac3651d64c1168af926f7458b)
Change-Id: If2b98b8930bc687170f53f852417fb9374bf6c60
Reviewed-on: https://gerrit.openafs.org/13789 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 9 Aug 2019 20:25:03 +0000 (14:25 -0600)]
LINUX 5.3.0: Use send_sig instead of force_sig
Linux 5.3.0 commit 3cf5d076fb4d48979f382bc9452765bf8b79e740 "signal
Remove task parameter from force_sig" (part of siginfo-linus branch)
changes the parameters for the Linux kernel function force_sig. See LKML
thread starting at https://lkml.org/lkml/2019/5/22/1351
According to the LKML discussion and the above commit message force_sig
is only safe to deliver a synchronous signal to the current task. To
send a signal to another task, we're supposed to use send_sig instead,
which has been available since at least linux 2.6.12-rc12.
Currently, rx_knet calls force_sig to kill the rxk_ListenerTask. With
the Linux 5.3.0 kernel, this module fails to compile due to the above
noted changes.
Replace the force_sig call with send_sig. In order to use send_sig, the
rxk_listener thread must allow SIGKILL and during shutdown (umount)
SIGKILL must be unblocked for the rxk_listener thread.
Note that SIGKILL is initially blocked on rxk_listener and is only
unblocked when shutting down the thread. Having the signal blocked is
sufficient to prevent unwanted signals from reaching the rxk_listener
thread during normal operation.
Reviewed-on: https://gerrit.openafs.org/13753 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2b7af1243f46496c0b5973b3fa2a6396243f7613)
Change-Id: I6eb44311fbcc63adb6ebeb85a8e076922befd645
Reviewed-on: https://gerrit.openafs.org/13788 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Thu, 8 Aug 2019 22:53:13 +0000 (16:53 -0600)]
LINUX 5.3.0: Check for 'recurse' arg in keyring_search
Linux 5.3.0 commit dcf49dbc8077e278ddd1bc7298abc781496e8a08 "keys: Add a
'recurse' flag for keyring searches" adds a new parameter to
Linux kernel keyring_search function.
Update the call to keyring_search to include the recurse parameter if
available. Setting the parameter to true (1) maintains the current
search behavior.
Change-Id: I038117d1bccdf619a42132fba7d8d61b3ce3c14b
Reviewed-on: https://gerrit.openafs.org/13752 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-on: https://gerrit.openafs.org/13787 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 17 Aug 2019 13:51:12 +0000 (06:51 -0700)]
Use correct variable substitutions in automake's absence
Pull in patches from upstream that use autoconf-defined variables
since the automake ones aren't getting defined anymore.
Without these, we'd have some strange user-facing behavior like:
kaduk@amnesiac:~$ fs version
@PACKAGE@ 1.8.4~pre1-1-debian
Benjamin Kaduk [Sat, 17 Aug 2019 00:39:24 +0000 (17:39 -0700)]
Require opt-in for krb5 weak crypto usage
Pull in upstream's patch (from the master branch) that requires a
command-line flag to be used in order to activate the weak-crypto APIs
from libkrb5. This is a step towards the eventual removal of that code
entirely.
GCC 9 with --enable-checking produces a new warning/error in
afs_utilAdmin.c associated with a strcpy with the potential of an
overlap. The index used is signed which triggers the new warning. The
source and target of the strcpy are contained within the same higher
level structure.
Change the variable 'index' from signed to unsigned to resolve the
warning/error. Change the variable 'total' in the same structure to
unsigned to be consistent with it's usage with 'index'.
Reviewed-on: https://gerrit.openafs.org/13660 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 79dffe29c8a0ec55c4231a18077efdfa7c1edf53)
Change-Id: I19a192ecea86314851e6889274eb030c5caff8cb
Reviewed-on: https://gerrit.openafs.org/13724 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 30 Oct 2018 20:41:22 +0000 (15:41 -0500)]
aklog: Avoid misleading AFSCELL message
Currently, if the AFSCELL environment variable is set, aklog (and
other libauth-using utilities) print out a message when
afsconf_GetLocalCell is called:
Note: Operation is performed on cell env.example.com
However, this message is also printed (with the AFSCELL cell) when
aklog is given the -cell command-line argument, even though aklog
actually uses the cell given on the command line. For example:
$ AFSCELL=env.example.com aklog -cell cli.example.com -d
Note: Operation is performed on cell env.example.com
Authenticating to cell cli.example.com (server srv1.example.com).
[...]
libauth will normally not print the "Operation" message if we're not
using the default cell, but it determines this by checking if someone
called afsconf_GetCellInfo before calling afsconf_GetLocalCell. And
currently, aklog calls afsconf_GetLocalCell before
afsconf_GetCellInfo, so the message gets printed because libauth has
no way of knowing that we're actually using a different cell.
klog gets around this by making an additional ignored call to
afsconf_GetCellInfo before afsconf_GetLocalCell, but we can fix this
in aklog by just changing the order of the calls. So, just call
afsconf_GetCellInfo first; if we're using the local cell, we can just
give a NULL cell parameter, instead of looking up the local cellname
first.
Reviewed-on: https://gerrit.openafs.org/13371 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 877d9d79a32b9e81911cb567f844b11c693229f0)
Change-Id: I67350be8c25fb93975442175a64098123503b40c
Reviewed-on: https://gerrit.openafs.org/13676 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 25 Mar 2019 21:33:39 +0000 (16:33 -0500)]
afs: Avoid non-dir ENOENT errors in afs_lookup
Historically, there have been many subsystems in libafs that can
generate ENOENT errors for a variety of reasons. In addition to the
expected case where we lookup a name that doesn't exist, other
scenarios have caused ENOENT error codes to be generated, such as:
internal inconsistencies, I/O errors, or even abort codes from the
network.
When one of these scenarios cause an ENOENT error code in one of those
situations during afs_lookup() when the target name does actually
exist, it can be confusing to a user, or even result in incorrect
application behavior. On Linux in particular, ENOENT results from a
lookup are cached in negative dcache entries, and so can cause future
lookups for the same name to yield ENOENT errors.
Various commits have tried to avoid this abuse of the ENOENT error
code, such as 2aa4cb04 (afs: Stop abusing ENOENT). But we cannot
prevent receiving ENOENT abort codes from the network, and mistakes in
the future may cause more scenarios incorrectly yielding ENOENTs.
However, in afs_lookup, we do know that legitimate ENOENT errors can
only occur in one situation: when we have a valid directory blob, and the
afs_dir_Lookup() operation itself returns an ENOENT error for the
target name. For all other areas of afs_lookup(), we know that an
ENOENT error is not legitimate, since we may not be sure if the target
name exists or not.
So to proactively avoid incorrect ENOENT results, prevent afs_lookup
from returning ENOENT, except in the specific code path where
afs_dir_Lookup is called.
Reviewed-on: https://gerrit.openafs.org/13537 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 5f48367f2bd5bf1c0e689c79508177b649b9113b)
Change-Id: I2698c26d7b75146d92e1763d49dce135ad66f672
Reviewed-on: https://gerrit.openafs.org/13692 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Thu, 23 May 2019 02:50:00 +0000 (22:50 -0400)]
auth: make PGetTokens2 work with 3-char cellnames
PGetTokens2 accepts two different types of input:
- an integer 'iterator' to request the nth token set for a user
- a string cellname to request the user's token set for that cell
Unfortunately, it distinguishes between these by assuming if the input
length is sizeof(afs_int32) (4 bytes), it must be an integer. This
assumption is incorrect if the cellname is three (3) characters long
plus a nul terminator.
The result is that the cellname string is interpreted as a very large
"n"; the subsequent search for the user's "very-large-nth-token" fails,
making it appear that the user has no valid token for this cell.
Improve on this heuristic by double-checking any putative integer input.
If it is actually a 3-character string, then process the input as a
cellname instead.
Andrew Deason [Sat, 3 Nov 2018 06:04:43 +0000 (01:04 -0500)]
ptserver: Check for -restricted in SPR_Delete
Currently, all prdb write operations, except for SPR_Delete, will fail
with PRPERM if called by a non-system:administrators caller while
restricted mode is active. SPR_Delete is missing this check, and so
is not affected by the -restricted option.
Fix this by inserting the same check for -restricted as all other code
paths that check for -restricted.
Reviewed-on: https://gerrit.openafs.org/13374 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2e556c0f23ae439c804352cf51fcf30878b03c7a)
Change-Id: I9a31cf4e6490aa13dc0c239d2660fc146553ee75
Reviewed-on: https://gerrit.openafs.org/13688 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Sat, 3 Nov 2018 05:58:58 +0000 (00:58 -0500)]
ptserver: Fix AccessOK -restricted for SYSADMINID
According to the documentation, as well as other code paths that check
for -restricted, the -restricted option does not affect members of
system:administrators. Currently, though, AccessOK only bypasses the
-restricted check if the caller is SYSADMINID itself (i.e. localauth).
Fix AccessOK to only do the -restricted checks if the caller is not in
system:administrators, to match the documentation as well as other
ptserver operations.
Reviewed-on: https://gerrit.openafs.org/13373 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3a8fa4ecd65d5d743fdc573c9f0f261aee2063b6)
Change-Id: I786830efab229a50a521daf3efc624e949475030
Reviewed-on: https://gerrit.openafs.org/13687 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 30 Oct 2018 19:29:24 +0000 (14:29 -0500)]
ptserver: Fix AccessOK -restricted for addToGroup
The function AccessOK is used by all of ptserver RPC handlers that
need to do an authorization check, and the last two arguments are set
as such:
- When adding a member to a group, 'mem' is PRP_ADD_MEM and 'any' is
PRP_ADD_ANY
- When removing a member from a group, 'mem' is PRP_REMOVE_MEM and
'any' is 0
- When modifying an entry (setFieldsEntry) or modifying some global
database fields, 'mem' and 'any' are both set to 0
- When reading an entry and not modifying it, 'mem' and/or 'any' are
set to other values (depending on if we're checking membership,
examining the entry itself, etc)
Commit 93ece98c (ptserver-restricted-mode-20050415) added a check to
AccessOK to make it return false for -restricted mode when we are
adding a member to a group, or when 'mem' and 'any' are both 0. This
didn't catch the case when we are removing a member from a group,
though, when 'mem' is PRP_REMOVE_MEM.
It looks like commit a614a8d9 (ptutils-restricted-accessok-20081025)
tried to fix this by adding a check for PRP_REMOVE_MEM, but it also
required 'any' to be set to 0 for the conditional to succeed. This is
true when removing a member from a group, but when adding a member to
a group, 'any' is PRP_ADD_ANY, and so this check fails.
This means that currently, when restricted mode is turned on,
non-admins can still run addToGroup and setFieldsEntry successfully.
Fix this by checking for PRP_ADD_MEM/PRP_REMOVE_MEM separately from
checking if 'mem'/'any' are set to 0. Break up this conditional into
separate if() statements with comments to try to make the checks
more clear.
Reviewed-on: https://gerrit.openafs.org/13370 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dfc78d533ef64c8d6daf134e2a0f67c5c16f7369)
Change-Id: I7f53570b42e2700a33dd5e72a31f6f7f8b876e79
Reviewed-on: https://gerrit.openafs.org/13686 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Thu, 23 May 2019 03:03:11 +0000 (23:03 -0400)]
auth: eliminate pointless retries in ktc_ListTokensEx
ktc_ListTokensEx is an iterator to provide the names of each cell for
which a user has a token set. It does this by looking for the 1 through
nth token set for a given user. However, as currently implemented,
it always continues searching up to the 100x safety limit even when
there are no more token sets for the user.
Instead, return immediately when VIOC_GETTOK2 returns EDOM (no more
tokens for this user).
Mark Vitale [Thu, 25 Oct 2018 14:27:41 +0000 (10:27 -0400)]
viced: correct option parsing for -vlru*, -novbc
Commit a5effd9f1011aa319fdf432c67aec604053b8656 "viced: Use libcmd for
command line options" modernized the option parsing for (da)fileserver,
but introduced a few errors for the following options:
Cheyenne Wills [Tue, 25 Jun 2019 16:40:53 +0000 (10:40 -0600)]
util: serverLog using memory after free
clang's scan-build detected a "use of memory after it is freed"
condition.
The function OpenLogFile frees the variable ourName before creating a
duplicate of the name passed to it. However there is a call that uses
ourName as the parameter: OpenLogFile(ourName). This results in freeing
ourName then doing a strdup of the same memory location.
Test the passed parameter and if it's the same as ourName already skip
the free and strdup.
khm [Tue, 25 Jun 2019 19:51:21 +0000 (12:51 -0700)]
add dkms dependency in Red Hat unit file
Currently, there is no explicit relationship between OpenAFS and dkms.
If dkms needs to rebuild the kernel module, OpenAFS will fail to mount
because modprobe will not load the module. This change specifies that
OpenAFS should run after dkms if dkms is present.
Reviewed-on: https://gerrit.openafs.org/13654 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fbe2a03aa69bc19768302685d902a25e4d6e157a)
Mark Vitale [Thu, 23 May 2019 02:52:10 +0000 (22:52 -0400)]
pioctl: limit fruitless token searches
getNthCell searches the afs_users table for the nth token set belonging to a
given user. However, it is impossible for a user to have more than one
token set per cell. If the caller specifies a number greater than the
total number of cells this cache manager knows about, we know the search
will be fruitless.
Instead, return early in this case, avoiding both the lock and the
search.
Reviewed-on: https://gerrit.openafs.org/13597 Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fc7e1700fe84f623fb9163466d24226df00b1a2c)
Change-Id: Idfda263af173a7ca081fcea3eef0ec4a63e66eda
Reviewed-on: https://gerrit.openafs.org/13639 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Pat Riehecky [Fri, 1 Jun 2018 21:33:37 +0000 (16:33 -0500)]
Fix static expressions in conditionals
The conditions in these if statements are always true (or always false).
Remove the check in cmdebug.c, as it is unnecessary, and fix the check
in vlclient.c to actually check for a valid voltype. (via cppcheck)
Reviewed-on: https://gerrit.openafs.org/13158 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5cd5cd9fa8754a5af346fa6a392363b046316c75)
Change-Id: Ie3a2d6bfc99d1b5adf0524afc29dac30b655d04d
Reviewed-on: https://gerrit.openafs.org/13638 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 17 May 2019 01:01:17 +0000 (20:01 -0500)]
Use the ppc64le_linuxXX sysname for ppc64le builds
Commit 191e18eb (Open ppc64le_linux sysname space) added the
ppc64le_linux26 sysname, but it still must be manually specified when
running on ppc64le. Use the ppc64le_linux26 by default on ppc64le, so
we can compile without needing to specify an explicit sysname.
Reviewed-on: https://gerrit.openafs.org/13593 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4b6a4ff31a4197504bbcf2d4c14c24dee672d40e)
Change-Id: Icf8f8b42c499dc42bf5d637dae5ad3e261e68512
Reviewed-on: https://gerrit.openafs.org/13637 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
In afs_linux_readdir, if we detect an error code from BlobScan,
currently we 'break' out of the current while() loop. But right after
this loop, we reset 'code' to 0, ignoring the error we just got from
BlobScan, and acting like we just reached the end of the directory.
This means that if BlobScan could not process the given directory at
all, we'll just fail to iterate through some of the entries in the
given directory, and not report an error.
To fix this, process errors from BlobScan like we do for
afs_dir_GetVerifiedBlob, and return an error code and log a message
about the corrupted dir.
Reviewed-on: https://gerrit.openafs.org/13430 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 63f015d05293cd853dbd44e5115e6b378644dfb6)
Change-Id: Ia25bcfdb70cdb1dd1a7ce0efb84ef76beb78b247
Reviewed-on: https://gerrit.openafs.org/13591 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 17 Jan 2019 05:46:34 +0000 (23:46 -0600)]
afs: Throw EIO in DRead on empty dir blob
DRead currently returns ENOENT if we try to read a page beyond the end
of the given dir blob. We do this to indicate we've hit EOF, but we do
this even if the dir blob is completely empty (which is not a valid
dir blob).
If a dir blob in the cache is truncated due to cache corruption
issues, that means we'll indicate a normal EOF condition in that
directory for most code paths. If someone is trying to list the
directory's entries, for instance, we'll just return that there are no
entries in the dir, even though the dir itself is just invalid.
To avoid this for at least some cases, return an EIO error instead if
the dir blob is completely empty.
Reviewed-on: https://gerrit.openafs.org/13429 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 86d04ea70fd2e99606b1d1b5b68d980d92e7a3cd)
Change-Id: I067aae1f949051169225a3cc0bdba35ad76a4ec2
Reviewed-on: https://gerrit.openafs.org/13590 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 16 May 2019 21:12:47 +0000 (16:12 -0500)]
Do not define AFS_SYSCALL for ppc64le_linux26
AFS_SYSCALL is defined to the syscall number we can use for a certain
platform (for pioctls and other AFS-specific kernel calls). On many
modern platforms, such as Linux, we don't use direct syscalls anymore,
instead routing our AFS-specific syscalls through an ioctl, and
AFS_SYSCALL is just used as a fallback for compatibility for older
OpenAFS releases that might still be using the syscall.
For new platforms, we have no need for this compatibility code path,
since there is no existing code we might need to be compatible with.
We should avoid defining AFS_SYSCALL for those, so we can avoid
manually-issuing syscalls in more cases. The ppc64le_linux26 platform
is a very new platform (introduced in 191e18eb "Open ppc64le_linux
sysname space"), and so should not have AFS_SYSCALL defined.
So, remove AFS_SYSCALL from ppc64le_linux26's param.h.
Reviewed-on: https://gerrit.openafs.org/13592 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 46563f929a851032d785634763963808d6e2bfeb)
Change-Id: Ib161b50a9156d3790134de4e1a8e66a1356e0fb6
Reviewed-on: https://gerrit.openafs.org/13636 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
redhat: RHEL8 add elfutils-devel as build dependency for kernel module
Building the kernel modules under RHEL8 produces the following error
message:
Makefile:952: *** "Cannot generate ORC metadata for
CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or
elfutils-libelf-devel". Stop.
Add elfutils-devel to the BuildRequires in the rpm spec when building
rhel >= 8
Add elfutils-devel to the BuildRequires in the rpm spec that
openafs-kmodtool produces
FIXES 134900
Reviewed-on: https://gerrit.openafs.org/13560 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 13817774518ada28f5fe68e0d00ef5dd00b67b55)
Change-Id: If4f453e6c459a2865626d4fd71bb47030e3deb58
Reviewed-on: https://gerrit.openafs.org/13563 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 28 Sep 2018 19:55:56 +0000 (14:55 -0500)]
afs: Raise osidnlc NCSIZE
The currrent size of the osi DNLC is very small; only 300 entries.
Raise it to 4096 entries, to give it some chance of actually helping.
In the future, of course, this should be runtime configurable, and we
should also raise the hash table size. For now, just raise the number
of entries without changing anything else, to try to make sure nothing
breaks.
With the hash size of 256, this means our hash chains will be at least
16 items long. However, traversing even hundreds of hash items should
still be better than frequently hitting the disk cache to find
entries, and acquiring more locks, etc.
Reviewed-on: https://gerrit.openafs.org/13531 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 12b46b6af778625a9c360dca61a59fcf30b76fd1)
Change-Id: Ib4fd8bd01e2df22617e5a549d4ac76ba1d50b2fd
Reviewed-on: https://gerrit.openafs.org/13559 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 17 Jan 2019 06:04:36 +0000 (00:04 -0600)]
dir: Honor non-ENOENT lookup errors
Currently, several places in src/dir/dir.c assume that any error from
a lower-level function (e.g. FindItem) means that the item we're
looking for does not exist in that directory. But if we encountered
some other error, that may not be the case; the directory blob may be
corrupt, we may have encountered some I/O error, etc.
To detect cases like this, return the actual error code from FindItem
&c, instead of always reporting ENOENT. For the code paths that are
actually specifically looking for if the target exists (in
afs_dir_Create), change our checks to specifically check for ENOENT,
and return any other error.
Do the same thing for a few similar callers in viced/afsfileprocs.c,
as well.
FIXES 134904
Reviewed-on: https://gerrit.openafs.org/13431 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0b3bd1b7cdc88ba62c8cd540e8628faa84e33cf9)
Change-Id: Ia81ff85821c1987b97390a683f1d442ca70db41e
Reviewed-on: https://gerrit.openafs.org/13543 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 21 Mar 2019 20:24:06 +0000 (15:24 -0500)]
LINUX: Avoid lookup ENOENT on fatal signals
Various Linux kernel operations on various Linux kernel versions can
fail if the current process has a pending fatal signal (i.e. SIGKILL),
including reads and writes to our local disk cache. Depending on what
and when something fails because of this, some parts of libafs throw
an ENOENT error, which may propagate up to callers, and be returned
from afs_lookup(). Notably this can happen via some functions in
src/dir/dir.c, and previously was possible with some code paths before
they were fixed by commit 2aa4cb04 (afs: Stop abusing ENOENT).
For the most part, the exact error given to the userspace caller
doesn't matter, since the process will die as soon as we return to
userspace. However, for ENOENT errors specifically for lookups, we
interpret this to mean that the target filename is known to not exist,
and so we create a negative dentry for that name, which is cached.
Future lookups for that filename will then result in ENOENT before any
AFS functions are called.
The lingering abuses of the ENOENT error code should be removed from
libafs entirely, but as an extra layer of safety, we can just avoid
returning ENOENT from lookups if the current process has a pending
fatal signal. So to do that, change all afs_lookup() callers in
src/afs/LINUX to translate ENOENT to EINTR if we have a pending fatal
signal. If fatal_signal_pending() is not available, then we don't do
this translation.
FIXES 134904
Reviewed-on: https://gerrit.openafs.org/13530 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8b6ae2893b517bd4e008cae94acff70abe4d2227)
Change-Id: I8bf1b24c97ed74b0b457d79f48b2f40416c1d37e
Reviewed-on: https://gerrit.openafs.org/13542 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Sat, 2 Mar 2019 21:58:00 +0000 (15:58 -0600)]
afs: Cleanup state on rxfs_*Init errors
Currently, rxfs_storeInit and rxfs_fetchInit return early if they
encounter an error while starting the relevant fetch/store RPC (e.g.
StartRXAFS_FetchData64). In this scenario, they osi_FreeSmallSpace
their rock before returning, but they never go through their
destructor to free the contents of the rock
(rxfs_storeDestroy/rxfs_fetchDestroy), leaking any resources inside
that have already been initialized.
The only thing that could have been initialized by this point is
v->call, so hitting this condition means we leak an Rx call, and means
we can report the wrong error code (since we never go through
rx_EndCall, we never look at the call's abort code). For
rxfs_fetchInit, most code paths call rx_EndCall explicitly, except for
the code path where StartRXAFS_FetchData64 itself fails.
For both fetches and stores, it's difficult to hit this condition,
because this requires that the StartRXAFS_* call fails, before we have
sent or received any data from the wire. However, this can be hit if
the call is already aborted before we use it, which can happen if the
underlying connection has already been aborted by a connection abort.
Before commit 0835d7c2 ("afs: make sure to call afs_Analyze after
afs_Conn"), this was most easily hit by trying to fetch data with a
bad security object (for example, with expired credentials). After the
first fetch failed due to a connection abort (e.g. RXKADEXPIRED),
afs_GetDCache would retry the fetch with the same connection, and
StartRXAFS_FetchData64 would fail because the connection and call were
already aborted. In this case, we'd leak the Rx call, and we would
throw an RXGEN_CC_MARSHAL error (-450), instead of the correct
RXKADEXPIRED error. This causes libafs to report that the target
server as unreachable, due to the negative error code.
With commit 0835d7c2, this doesn't happen because we call afs_Analyze
before retrying the fetch, which detects the invalid credentials and
forces creating a new connetion object. However, this situation should
still be possible if a different call on the same connection triggered
a connection-level abort before we called StartRXAFS_FetchData64.
To fix this and ensure that we don't leak Rx calls, explicitly call
rxfs_storeDestroy/rxfs_fetchDestroy in this error case, before
returning from rxfs_storeInit/rxfs_fetchInit.
Thanks to yadayada@in.ibm.com for reporting a related issue and
providing analysis.
Reviewed-on: https://gerrit.openafs.org/13510 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 11cc0a3c4e0d76f1650596bd1568f01367ab5be2)
Change-Id: I3c2d66a5a6128bb8b403dfa6ea7c37e32bd2f156
Reviewed-on: https://gerrit.openafs.org/13517 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 10 Aug 2017 01:06:05 +0000 (20:06 -0500)]
SOLARIS: Switch non-embedded vnodes for Solaris 11
Newer updates to Solaris 11 have been including several changes to the
vnode struct. Since we embed a vnode in our struct vcache, our kernel
module must be recompiled for any such change in order for the openafs
client to work at all.
To avoid the need for this, switch Solaris to using a non-embedded
vnode in our struct vcache. Follow a similar technique as is used in
DARWIN and XBSD, where we allocate a vnode in osi_AttachVnode, and
free it in afs_FlushVCache.
Reviewed-on: https://gerrit.openafs.org/12696 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2aafe7df403e6a848185d15495139c07bced2758)
Change-Id: I2f5b3e2b2b908ea9815fd7735a1abed511cec9cb
Reviewed-on: https://gerrit.openafs.org/13528 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 10 Aug 2017 01:06:03 +0000 (20:06 -0500)]
SOLARIS: Fix vnode/vcache casts
A few places were using vnodes and vcaches interchangeably. This is
incorrect, since they may not always be the same thing if we stop
embedding vnodes directly in vcaches Fix these to properly go through
AFSTOV/VTOAFS to convert between vcaches and vnodes.
Reviewed-on: https://gerrit.openafs.org/12695 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit a6499e0b086d964f3fcc65fe4be31edc33015061)
Change-Id: Ia6889966a7c595786f0a273b4c2a5a63fe60ddd3
Reviewed-on: https://gerrit.openafs.org/13527 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 10 Aug 2017 01:06:00 +0000 (20:06 -0500)]
SOLARIS: Accept vnodes in vnode ops
Currently, our vnode op callbacks look like this:
int gafs_fsync(struct vcache *avc, afs_ucred_t *acred);
And a pointer to gafs_fsync is given directly to Solaris. This cannot
be correct, since 'struct vcache' is an OpenAFS type, so Solaris
cannot possibly give us a 'struct vcache'. The actual correct
signature for such a function is something like this:
int gafs_fsync(struct vnode *vp, afs_ucred_t *acred);
And then the 'gafs_fsync' function is supposed to translate 'vp' into
a vcache.
This works on Solaris right now because we embed the vnode as the
first member in our vcache, and so a pointer to a vnode is also a
pointer to a vcache. However, this would break if we ever change
Solaris vcaches to use a non-embedded vnode (like on some other
platforms). And even now, this causes a lot of warnings in
osi_vnodeops.c, since the function signatures are wrong for our vnode
callbacks.
So to fix this, change all of these functions to accept a 'struct
vnode', and translate to/from vnodes and vcaches appropriately.
Reviewed-on: https://gerrit.openafs.org/12694 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit 9a2b11747ce355d9adc8a5a646c88f8f3d9765ee)
Change-Id: I85cee787e26886596a10c6b9a02f33f2bf28d65d
Reviewed-on: https://gerrit.openafs.org/13526 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 10 Aug 2017 01:05:56 +0000 (20:05 -0500)]
SOLARIS: Reorder definitions for vnode callbacks
Currently, many of the functions for our vnode ops are
forward-declared, right before they are referenced in the relevant
vnop template array. Move the function definitions to before the
references, so we can simply get rid of the forward declarations.
These functions are also all only referenced in this file, so declare
them 'static'.
Reviewed-on: https://gerrit.openafs.org/12693 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit 41a22dbf719629e0977fa963b3d19c6594d0d729)
Change-Id: I5840fef98d2ce15525c4981636fad6e5990cbad2
Reviewed-on: https://gerrit.openafs.org/13525 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 10 Aug 2017 01:05:50 +0000 (20:05 -0500)]
SOLARIS: Clean up some osi_vnodeops func defs
Currently, the Solaris osi_vnodeops.c file forward-declares many of
its function definitions, but doesn't declare the arguments. For
example:
int afs_nfsrdwr();
This avoids type-checking for a few functions that are called before
they are defined in this file. Furthermore, many of these functions
are only used within this file, but are not declared 'static'.
To fix this weirdness, remove most of the forward declarations (most
are not referenced until the function is defined), and fully declare
the rest. Declare functions 'static' that are not referenced outside
of this file.
This commit only changes functions up to the 'afs_getsecattr'
definition. The rest of the file will be fixed in a future commit.
Reviewed-on: https://gerrit.openafs.org/12692 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Mark Vitale <mvitale@sinenomine.net>
(cherry picked from commit aa46af6ae35e4f026a8ed94012c3bc18c954de23)
Change-Id: I33f445ed253f1991896afff33e7cc14bf5e50b18
Reviewed-on: https://gerrit.openafs.org/13524 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Fri, 18 Jan 2019 22:05:49 +0000 (17:05 -0500)]
LINUX: correct include for ktime_get_coarse_real_ts64()
The include for the ktime_get_coarse_real_ts64() autoconf test is
incorrect; ktime_get_coarse_real_ts64() has always been in linux/ktime.h
(via #include timekeeping.h), not linux/time.h.
This autoconf test still ran correctly because the OpenAFS build was
inadvertently picking up ktime.h via the default autoconf include path.
Therefore, this commit is needed only to provide documentation and
clarity to future maintainers.
Andrew Deason [Fri, 28 Sep 2018 22:12:40 +0000 (17:12 -0500)]
afs: Remove afs_xosi
Since OpenAFS 1.0, all platforms in libafs have a lock called
afs_xosi, which is acquired and released around calls like VOP_GETATTR
on cache files. However, this lock doesn't appear to protect anything;
on all platforms, the code that runs while the lock is held uses only
calls VOP_GETATTR and accesses local variables (aside from
afs_osi_cred, which we use similarly in many other places). The
purpose of the lock has never been documented, and is not mentioned at
all in the afs_rwlocks text file.
The comment by the afs_xosi lock declaration suggests that the lock
was originally introduced to protect access to 'tvattr', which perhaps
was a global variable in the past. All uses of 'tvattr' are local now,
though, so protecting access to it doesn't make any sense.
So, remove afs_xosi, to remove the unnecessary serialization of
VOP_GETATTR calls.
Reviewed-on: https://gerrit.openafs.org/13350 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d75bc6370f625479a67c7c0a50cce23c4d4a4ce5)
Change-Id: I33dc7935872cf071c4221d46cbb458e1f77185a2
Reviewed-on: https://gerrit.openafs.org/13529 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Michael Meffie [Fri, 16 Mar 2018 14:25:18 +0000 (09:25 -0500)]
afs: make sure to call afs_Analyze after afs_Conn
The afs_Conn function is used to pick a connection for a given RPC. The
RPC is normally wrapped within a do-while loop which calls afs_Analyze
to handle the RPC code and manage the server connection references.
Among other things, afs_Analyze can mark the server as down, blacklist
idle servers, etc.
There are some special cases in which we break out of this do-while loop
early, by putting the connection reference given by afs_Conn and then
jumping out of the loop.
In these cases, be sure to call afs_Analyze to put the server connection
we got from afs_Conn, and to handle the RPC return code, possibly
marking the server as down or blacklisted.
Reviewed-on: https://gerrit.openafs.org/13288 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0835d7c2a183f896096684df06258aefd297f080)
Change-Id: Ic5648dbd250c33988d64284b906b3829a396a2cb
Reviewed-on: https://gerrit.openafs.org/13511 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 6 Sep 2018 18:42:11 +0000 (13:42 -0500)]
Run ctfconvert/ctfmerge for all objects
Commit 88cb536f (autoconf: detect ctf-tools and add ctf to libafs)
introduced running ctfconvert and ctfmerge for libafs on Solaris, but
didn't add any CTF data for userspace code. This commit causes the
same commands to be run for every binary that we build (if the ctf
tools are available).
To accomplish this, also refactor how we run ctfconvert and ctfmerge.
The approach in commit 88cb536f would require us to modify the
makefile rule for every executable to run RUN_CTFCONVERT and
RUN_CTFMERGE, which is somewhat impractical. So instead in this
commit, we modify all of our *_CCRULE and *_LDRULE variables to wrap
the compiler invocation with the new CC_WRAPPER script. This means our
*RULE variables change from something like this:
CC_WRAPPER expands to the script src/config/cc-wrapper, which just
runs ctfconvert or ctfmerge on the relevant files after the
compiler/linker runs. If the CTF tools are not configured, CC_WRAPPER
expands to nothing, to limit our impact on other platforms.
This commit was developed in collaboration with
mbarbosa@sinenomine.net.
Reviewed-on: https://gerrit.openafs.org/13308 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c1d39153da00d5525b2f7874b2d214a7f1b1bb86)
Change-Id: Ic357293a946f0759aa032f7c93b4b56e74e9209a
Reviewed-on: https://gerrit.openafs.org/13487 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 31 May 2018 12:46:56 +0000 (09:46 -0300)]
autoconf: do not reference the missing script
Currently, OpenAFS does not use automake. As a result, the missing script
is not copied to the build-tools directory. Since this script is not
present in the tree, am_missing_run is not initialized. Unfortunately,
the current version still has a few references to this variable. In order
to preserve a similar behavior, this commit replaces these references by
AC_ERROR.
While we are changing these, remove the AC_CHECK_PROGS calls for AR and
STRIP, since libtool already checks these for us.
Reviewed-on: https://gerrit.openafs.org/12982 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9d3ef9337fafe5dcf3865d3aced290be0f887c11)
Change-Id: Ibb2fa93e73f303cd68e9e030f1631476f1da329c
Reviewed-on: https://gerrit.openafs.org/13486 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
projects / packages / o / openafs.git / log