The VL_ error table currently doesn't have an error code to indicate
that an operation cannot succeed because the database is corrupted.
There are a few error codes for specific cases of errors that are
probably the result of corruption (like VL_IDALREADYHASHED, or
VL_EMPTY), but these are only for specific cases and indicate rather
low-level internal problems.
There are some instances where the real problem preventing an
operation from succeeding is that the database is just corrupt or
inconsistent in some way, and the administrator must repair the
database before it can succeed. And we currently don't have any way of
indicating that situation via an error code.
So, introduce the VL_DBBAD code, to indicate this situation. Error
codes already exist in other tables for similar situations, such as
PRDBBAD, and KADATABASEINCONSISTENT.
This commit does not use the new error code anywhere; we just
introduce it into the VL_ error table, so comerr-using applications
will be able to interpret it.
Note that the VL_DBBAD error code has been recognized by the AFS
Assigned Numbers Registry as recorded in the ticket history of
<https://rt.central.org/rt/Ticket/Display.html?id=134817>
Change-Id: I8fea356a4e0db907ec8418efe6ef35d547be0a63
Reviewed-on: https://gerrit.openafs.org/13383
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
put_prentries() is a helper function for listEntries(), but the contract
between the two is rather odd -- put_prentries() is expected to notice
when the backing store has not yet been allocated and silently allocate
it, even though there is only the single caller and the allocation could
be done in the caller.
Move the allocation to the caller and adjust the "buffer is full"
logic accordingly, and normalize the initialization of the output
array to just use calloc() instead of individual memset()s when
populating each entry.
Change-Id: Icf84e3b60eae81a1570b12d7adbf006a24a104f3
Reviewed-on: https://gerrit.openafs.org/13315
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
volmain.c calls osi_audit before the audit facility is fully
initialized.
Commit 16d67791 (auditlogs-for-everyone-20050702) introduced the
-auditlog parameter; it appears that it didn't remove the call
to osi_audit (right after osi_audit_init) that was called before command
line argument processing. This resulted in calling the audit facility
before it was fulling initialized with the -auditlog and
-audit-interface parameters. The 16d67791 commit replicated the
osi_audit call after command line processing.
Change-Id: Ia0c0054a2fb11892b5b30c0f0838a4d6bbdf9bbb
Reviewed-on: https://gerrit.openafs.org/13772
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, we skip the pthread_once call in osi_audit_init if
audit_lock_initialized is set. But this is somewhat pointless, since
pthread_once will effectively do this check itself, and better (it
will wait if osi_audit_init is actively running in another thread).
So just get rid of audit_lock_initialized, and replace the other
assert for audit_lock_initialized with another plain pthread_once
call.
Change-Id: I466c8ec2d1516edecaae23d4354892e7e3a88918
Reviewed-on: https://gerrit.openafs.org/14403
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
All but one RPC used the capitalization "taskId"; adjust the long
straggler for consistent style.
Change-Id: I996d96a4fc67af7f745bf67041c90390073ca9ea
Reviewed-on: https://gerrit.openafs.org/13318
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
These functions have been commented out since the original IBM
import, and un-commenting them in their current location would
be an ABI break (by causing opcodes to be reassigned for subsequent
RPCs). Since they are just noise in the interface description
file, remove them.
Change-Id: I7e8cd2e7dfa4469e39e26a0437059c108f3ef218
Reviewed-on: https://gerrit.openafs.org/13316
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
RPC handlers are a little bit special in that their output parameters
are discarded on error and an Rx abort is sent instead of the usual
response fields. Nonetheless, it is good code hygeine to adhere to
the practices we use for the rest of the functions in the tree:
initialize output variables before the first return.
Change-Id: I6c2e25b04ccb6277bd28e398121723b92fe42b04
Reviewed-on: https://gerrit.openafs.org/13314
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
If we are trying to delete an entry from the vldb, we fail with
VL_NOENT if we cannot find the given entry on one of its hash chains.
This is indicative of corruption in the vldb (since we have an entry
not on a hash chain), but we don't really indicate this clearly. There
are no log messages, and the user running 'vos' only sees an error
like this:
$ vos delentry 123456
Could not delete entry for volume 123456
You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
VLDB: no such entry
Deleted 0 VLDB entries
Which is the exact same error message if the user tries to delete a
volume that does not actually exist.
We currently do not have an error code that clearly says that the
database appears corrupted and needs to be fixed, but we can at least
log an error in VLLog for this case, to give the administrator a
chance at fixing the situation. So, log a message in this situation.
Change-Id: I4f0ee8749a90441e1f8d779890293dc5d1d9dbee
Reviewed-on: https://gerrit.openafs.org/13382
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
If dafs is configured but stopped, 'bos salvage <fs> <vicep>
-forceDAFS' will fail with:
bos: failed to get instance info for 'fs' (no such entity)
bos: shutting down 'fs'.
bos: can't stop 'fs' (no such entity)
This is due to incomplete logic in IsDAFS, introduced with commit
e46f10a0a0a930f318833a8a86b10c19744160c1 'bos: Do not assume DAFS just
if DAFS bnode exists'
Add logic to IsDAFS to work correctly when dafs is configured but
stopped.
Change-Id: I50f8209180536d25e68c0ad6fb826202d8f27ce7
Reviewed-on: https://gerrit.openafs.org/14382
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
On a new OpenAFS install where the log directory has not yet been
created. 'bosserver -auditlog /usr/afs/logs/<auditlog>' (absolute path)
fails with ENOENT because the log directory doesn't exist yet.
Furthermore, 'bosserver -auditlog <auditlog>' (relative path) succeeds,
but the audit file is created in the current working directory when
bosserver was started, not in the expected log directory (Transarc
/usr/afs/logs).
Both problems have been present since bosserver audit log support was
introduced by commit 16d67791dce45e5d4ee9b854c796492ffcde2113
'auditlogs-for-everyone-20050702'.
Reorder the bosserver initialization steps to ensure that the log
directory has been created and is the current working directory, before
creating and opening the audit log.
Change-Id: I1dc3c136edd12c5425ef0b7a3212a18d4c3036f7
Reviewed-on: https://gerrit.openafs.org/14381
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
cmd_OptionAsString returns non-zero if the given option _isn't_ given
(CMD_MISSING), so we need to call osi_audit_file only when
cmd_OptionAsString returns 0. Since commit
f6cdf71 (bozo: Use libcmd for command line options), this causes
bosserver to complain on startup if no -auditlog was given:
$ bosserver
Warning: auditlog (null) not writable, ignored.
To fix this, skip calling osi_audit_file if -auditlog was not given.
While we're changing this anyway, change our processing of our
audit-related options to more closely match what other daemons do,
like ptserver or viced, so it's easier to see if we're doing the right
thing. That is, just call cmd_OptionAsString() without a conditional,
and just test if auditFileName is non-NULL later on, after options
processing.
Change-Id: I563c7efd02cb5210c32c0cc7f5a03683db792e98
Reviewed-on: https://gerrit.openafs.org/14402
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
afs_GetServer calls ReleaseWriteLock(&afs_xvcb) twice within a few
lines. The second one is spurious.
Commits b18653de7ae90491c2e75f4a98410581655d776c 'xserver lock order
violation' and f2bf60ed4f1323cd6f74f2f01114f7e4f714db53 'xvcb lock order
violation' were written by the same author at the same time and
apparently were victims of a bad merge.
Discovered during a lock audit project as a panic during afsd startup:
assertion failed: (&afs_xvcb)->excl_locked == WRITE_LOCK, file:
/home/mvitale/src/sna-openafs/src/afs/afs_server.c, line: 2089
afs_GetServer is called frequently by many threads and so this bug could
easily have released another thread's write lock on afs_xvcb.
Remove the spurious second release.
Change-Id: I495f4775e18ed37cfbccd03b5f25594586864b83
Reviewed-on: https://gerrit.openafs.org/14411
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
To make the ubik_Call* functions cleaner, consolidate code that finds
the index of the connection associated with a host into a new function.
No functional change should be incurred by this commit.
Change-Id: I320d7a41221cb533e8d077c412f872152ac43b75
Reviewed-on: https://gerrit.openafs.org/14060
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, code inside afs_vcache.c assumes that osi_NewVnode always
returns non-NULL, which means that osi_NewVnode must panic if it
cannot create a new vnode.
All of the callers of afs_GetVCache, afs_NewVCache, etc, already
handle getting a NULL return, though (after all, the given fid may not
exist or be inaccessible due to network errors, etc). So, just
propagate NULL returns from osi_NewVnode up to our callers, to avoid
panics in these situations.
Modify osi_NewVnode on many arches to return an error on allocation
failure, instead of panic'ing.
Change-Id: Ib578b1747590bdf65327d4674e0849811ed999eb
Reviewed-on: https://gerrit.openafs.org/13701
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Since the original IBM code import, OpenAFS has an algorithm for
squaring clock values, implemented identically in three different
places. This algorithm does not account correctly for microsecs
overflow into seconds, resulting in incorrect "sum-of-squares" values
for queue and execution time in several OpenAFS performance utilities.
Specifically, this code:
t1.tv_usec += (2 * t2.tv_sec * t2.tv_usec) % 1000000 \
+ (t2.tv_usec / 1000)*(t2.tv_usec / 1000) \
+ 2 * (t2.tv_usec / 1000) * (t2.tv_usec % 1000) / 1000 \
+ (((t2.tv_usec % 1000) > 707) ? 1 : 0); \
Can allow for the tv_usec field to be increased by a theoretical max
of around:
t1.tv_usec += 999998 \
+ 999*999 \
+ 2 * 999 * 999 / 1000 \
+ 1; \
Or:
t1.tv_usec += 1999996; \
If t1.tv_usec is already 999999, after this calculation its value
could be as high as 2999995. So just checking once if t1.tv_usec is
over 1000000 is not sufficient, since the resulting value (1999995) is
still over 1000000.
Correct all implementations by repeatedly checking if tv_usec is over
1000000 after the above calculation:
macro affected utility
===================== ============================
afs_stats_SquareAddTo xstat_cm_test
fs_stats_SquareAddTo xstat_fs_test
clock_AddSq rxstat_get_process and _peer
Change-Id: I3145d592ba6bc1556729eac657f43d476c99eede
Reviewed-on: https://gerrit.openafs.org/14376
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Since the original IBM code import, rxstat_get_process and
rxstat_get_peer have reported vlserver VL_* RPC stats as for the
"volserver interface".
Correct this to read "vlserver interface".
Change-Id: Ie65fd41150bed8180ad8792c21a67012084459ab
Reviewed-on: https://gerrit.openafs.org/14375
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit d3eaa39da3693bba708fa2fa951568009e929550 'rx: Make the rx_call
structure private' inadvertently caused all rxstats (aka rpcstats) to be
recorded as client stats by hardcoding the value for isServer to 1.
Therefore, when peer or process rxstats are enabled for a OpenAFS
component, the rxstat_get_process and rxstat_get_peer utilities will
erroneously report both client and server stats as "accessed as a client".
This is particularly problematic for ubik VOTE_* and DISK_* RPC stats,
for which a given ubik server may be both client and server over time.
In this case, both client and server stats are conflated into the same
"accessed as a client" counters.
Instead, properly pass the value of isServer from
rx_RecordCallStatistics through to rxi_IncrementTimeAndCount.
Note to maintainers:
This bug is only in master and all 1.8.x releases; no 1.6.x releases are
affected.
Note:
Confusingly, isServer=1 indicates client stats and isServer=0 indicates
server stats. However, this is a quirk of the original implementation
and wire format of the RXSTATS_* RPCs and cannot be changed. isServer
is actually shorthand for "remote is server"; thus all RPC client stubs
record their rxstats with isServer == 1, and all RPC server stubs record
their rxstats with isServer == 0.
Change-Id: I2420f807e2c18ddfb9de7093a487825fa2d0a68e
Reviewed-on: https://gerrit.openafs.org/14374
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, if SAFSVolConvertROtoRWvolume cannot create a new transaction
for the volume to be converted, it returns without closing the directory
stream opened by it. To prevent this leak, go through a new 'goto done'
destructor if NewTrans fails.
Change-Id: Ie0580e7739ae667f1cd2f9cabb8aaf5e15d3f2dd
Reviewed-on: https://gerrit.openafs.org/14342
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The bosserver directory and file access check stops after finding one
directory or file with incorrect permissions or owner. A log message is
written for this first one found, but more than one directory or file
may have incorrect access rights.
Instead check all of them so the bosserver logs a warning message for
each incorrect director or file permission found. This should make it
easier to fix all of the file permission problems at once.
Change-Id: Ia3f14800ce036aa390929109a286cf21828e8a35
Reviewed-on: https://gerrit.openafs.org/14330
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
When the KeyFileExt and rxkad.keytab were added to OpenAFS, they were
not added to the bosserver's access rights check. Add these files to the
bosserver access checks, with the same access rights needed for the
original KeyFile.
Also, add the full path for KeyFileExt to the dirpath package (not just
the filename), which was not done when the KeyFileExt was introduced.
This is needed to perform the access checks.
Change-Id: I8c9028e846fad9f15823baeb7cc15a8f80ed5c1c
Reviewed-on: https://gerrit.openafs.org/14329
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
These have not been needed since src/afs/afs_prototypes.h gained 'extern
afs_rwlock_t afs_xvcache' with commit
8f2df21ffe59e9aa66219bf24656775b584c122d
"pull-prototypes-to-head-20020821"
Remove the vestigial extern references.
Change-Id: Id6aceff0d5df1f1bed210a3fbf2951c62f35ddbb
Reviewed-on: https://gerrit.openafs.org/14406
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit 64cc7f0ca7a44bb214396c829268a541ab286c69 "afs: Create
afs_StaleVCache" consolidated many references to afs_xcbhash into a new
function afs_StaleVCache. However, this left many references to 'extern
afs_wrlock_t afs_xcbhash' that are no longer needed.
But actually, many of these have not been needed since
src/afs/afs_prototypes.h gained 'extern afs_rwlock_t afs_xcbhash' with
commit 8f2df21ffe59e9aa66219bf24656775b584c122d
"pull-prototypes-to-head-20020821"
Remove the vestigial extern references.
No functional change is incurred by this commit.
Change-Id: Ie6cfb6d90c52951795378d3b42e041567d207305
Reviewed-on: https://gerrit.openafs.org/14405
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Historically xstat_cm_test and xstat_fs_test have supported option
'-period <mm>' to specify continuous operaiton for a length of time. If
'-period 0' was specified, both programs exited immediately.
Beginning with commits 2c1a7e47336c8f8d14dd6c65d53925a9e0e87c66 'xstat:
add xstat_*_Wait functions' and 6b67cac432043a43d7cdfa6af972ab54412aff94
'convert xstat and friends to pthreads', xstat_cm_test and xstat_fs_test
now support -period 0 to run "forever". This support is implemented in
xstat_cm_Wait and xstat_fs_Wait, respectively. Although the "wait
forever" logic was added to allow consolidation of similar code in
afsmonitor, it also changed how xstat_cm_test and xstat_fs_test behave
for '-period 0'.
Unfortunately, there is a bug in this support, at least when running on
pthreads. After the initial 24 minute timer expires, the while (1) will
repeatedly run select with a timeout that is now 0. This causes the
while loop to consume 100% of the CPU on which this thread is
dispatched.
Instead, modify the wait-forever logic to specify NULL for the select()
timeout value. Also update the man page to document that '-period 0'
means forever.
Change-Id: I25d0d5be0eedb8bf3de495785b9b03a3e3d45221
Reviewed-on: https://gerrit.openafs.org/14366
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, for AFS_NEW_BKG, background daemons run in the context of a
normal user process (afsd), in order to return to run
userspace-handled background ops. For non-AFS_NEW_BKG when
AFS_DAEMONOP_ENV is defined, background daemons run as kernel threads
instead, and have no corresponding userspace process.
On LINUX, whether or not we run as a kernel thread has some odd
side-effects: at least one example of this is how open file handles
(struct file) are treated when closed. When the last reference to a
struct file is closed, the final free is deferred to an asynchronous
call to be executed "later", in order to avoid issues with lock
inversion. For kernel threads, "later" means the work is schedule on
the global system work queue (schedule_work()), but for userspace
processes, it is scheduled on the task work queue (task_work_add()),
which is run around when the thread returns to userspace. For
background daemons, we never return from the relevant syscall until we
get a userspace background request (or the client is shutting down),
Commit ca472e66 (LINUX: Turn on AFS_NEW_BKG) changed LINUX to use
AFS_NEW_BKG background daemons, so background requests now run as a
normal userspace process, and last-reference file closes are deferred.
Since we may never return to userspace, this means that our file
handles (used for accessing the disk cache) may never get freed,
leading to an unbounded number of file handles remaining open.
This can be seen by seeing the first value in /proc/sys/fs/file-nr
growing without bound (possibly slowly), as accessing /afs causes
background requests. Eventually the number of open files can exceed
the /proc/sys/fs/file-max limit, causing further file opens to fail,
causing various other problems and potentially panics.
To avoid this issue, define a new userspace background op, called
AFS_USPC_NOOP, which gets returned to the afsd background daemon
process. When afsd sees this, it just does nothing and calls the
AFSOP_BKG_HANDLER syscall again, to go into the background daemon loop
again. In afs_BackgroundDaemon, we return the AFS_USPC_NOOP op
whenever there are no pending background requests, or if we've run 100
background requests in a row without a break. This causes us to return
to userspace periodically, preventing any such task-queued work from
building up indefinitely.
Do this for all platforms (currently just LINUX and DARWIN), in order
to simplify the code, and possibly avoid other similar issues, since
staying inside a syscall for so long while doing real work is arguably
weird.
Add a documentation comment block for afs_BackgroundDaemon while we're
here.
Thanks to mvitale@sinenomine.net for discovering the file leak.
Change-Id: I1953d73b2142d4128b064f8c5f95a5858d7df131
Reviewed-on: https://gerrit.openafs.org/13984
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The RPC-L type sampleName and related constant UMAXNAMELEN are not
referenced by anything, and have been unused since OpenAFS 1.0. Remove
the unused definitions.
Change-Id: I21a11d9db9ed80547de8685623fb09f9a86934f1
Reviewed-on: https://gerrit.openafs.org/14386
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
srcdir is a magic variable that needs to be set to @srcdir@, not some
relative path like ../../.. (which will usually be somewhere in the
objdir, not srcdir). Set it correctly in here.
Without this, objdir builds can fail with:
make[4]: Entering directory '...obj/src/dir/test'
make[4]: *** No rule to make target 'dtest.o', needed by 'dtest'. Stop.
Which happens because the automatic rule for dtest.o can't be
constructed, since we cannot find dtest.c automatically because srcdir
isn't set properly.
This has been broken since commit 37b4195d (dtest-20021111), but was
not noticeable until commit 192a2ff4 (dir: make dtest buildable
again), since that caused dtest to actually get built.
Also set LIBS correctly in here, using the conventional ${TOP_LIBDIR},
since ${srcdir} no longer points to "../../..".
Change-Id: I539e01a4397c558dc0eda492834b3f9913f71634
Reviewed-on: https://gerrit.openafs.org/14384
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Update bosserver to use libcmd for command line parsing.
Change-Id: Iaa55dc33b72983a48089a7b359260916bea2d1e7
Reviewed-on: https://gerrit.openafs.org/13845
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit d566c1cf874d15ca02020894ff0af62c4e39e7bb
'dread-do-validation-20041012' modified directory checking (in the
afs_buffer.c implementation of DRead()) to use size information passed
to DRead, rather than obtained from the cache via afs_CFileOpen.
Because this directory checking does not require any information from
the cache buffers or the cache partition, we can make the check right
away, before searching the cache buffers or calling afs_newslot.
To clarify and simplify, move the directory sanity checking logic to the
beginning of DRead. Remove the afs_newslot cleanup logic which is no
longer needed.
While here, add Doxygen comments for DRead.
Change-Id: I8cea4e885ece64e760271c8194c126250f87104e
Reviewed-on: https://gerrit.openafs.org/13803
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The dtest test program ignores the return from afs_dir_Makedir.
Fix this so errors may be identified in testing.
While here, also improve the diagnostic message for afs_dir_Create
failures, to make it consistent with the new diagnostic message for
afs_dir_MakeDir failures.
Change-Id: Ib882947e01c864344f17faad8a646b2487793f29
Reviewed-on: https://gerrit.openafs.org/13797
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>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The dtest -f subcommand (CRTest()) exits immediately if there is an
error while adding files. This may create an empty, incomplete, or
corrupt directory object on disk because we neglected to call DFlush
before exiting.
Always call DFlush from CRTest() whether it fails or succeeds.
Change-Id: Ia7b4ad00ea6f4f9f788cd75ae726bdadb60ee9c3
Reviewed-on: https://gerrit.openafs.org/13796
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The dtest utility has had its fid[] arrays defined as 'long' since the
initial IBM import. Commit 0a98548832472152304410e41306adcc5b91f6a2
'dir: Make test utility build again' converted some - but not all - the
fid arrays to afs_int32.
Allow dtest to operate correctly by converting the rest of the fid
arrays to afs_int32.
Change-Id: I2ebe36272e02cf860577153ab94f3591e1d707e8
Reviewed-on: https://gerrit.openafs.org/13795
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 7fe4125fe3435092b75ed29b884d8d3c2d1a2cad 'dir/vol: Die() really
does' overlooked src/dir/test/dtest.c, breaking its build.
Fix the signature of Die() and the makefile so dtest can be built.
In addition, change the Makefile so it is always built.
Change-Id: I18129acbfdaa770987c7f0b8055ff593f776e518
Reviewed-on: https://gerrit.openafs.org/13794
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Makefile rules for physio.c and test-salvage.c have been commented out
since the original IBM code import, and were removed in commit
37b4195d603630498664fa0975ea5d5c82f9aa4f 'dtest-20021111' to fix dtest.
However, that commit neglected to remove the source files and other
references to them in Makefile.in
Finish the job by removing the files and references to them.
No functional change is incurred by this commit.
Change-Id: I57527be99cd28a481a86b659d1eb3227af9f1c99
Reviewed-on: https://gerrit.openafs.org/14052
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The updateDirInode and listVicepx utilities are obsolete; they no longer
build, are severely bitrotted, and have been largely replaced by
volscan.
While here, also remove other objects that have not been built by default
since before the original IBM import:
- ILIST ilist.exe
- NAMEI_PROGS nicreate, nincdec, nino, nilist
Remove all of them from the tree.
Change-Id: I8f68ec425cce5e84bcc5f41d598eec23102109de
Reviewed-on: https://gerrit.openafs.org/13793
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Update version strings for the first 1.9.x development release.
Change-Id: I0d0e204ffe8d64d7c0f794f313c0f24ccea12783
Reviewed-on: https://gerrit.openafs.org/14362
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Stay up to date with the stable branch at least until the initial
version of the new release series.
Change-Id: Iefcd9cc039399cd4cbbcc0474c2cabffa7780305
Reviewed-on: https://gerrit.openafs.org/14344
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Add some entries for the commits that landed since the previous update.
Change-Id: I74820ee5a07c3fb539f233b2bd0c30aab262ba74
Reviewed-on: https://gerrit.openafs.org/14343
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Our kextutil signing check will fail for releases that require
notarization (Mojave 10.14.5 and up, Catalina 10.15 all versions),
because we aren't notarized yet at the time of the check.
Instead, disable the check for those releases.
Change-Id: Iec1b74d18ae02cdd031ed3194ffb9900aa8a1b55
Reviewed-on: https://gerrit.openafs.org/14222
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This fixes a bug where p->cb_dirent is called twice, if
it exists.
Change-Id: I7a7a6abf522b62eb310d003a61b3bbcdcda9e850
Reviewed-on: https://gerrit.openafs.org/14308
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This reverts commit 32d35db64061e4102281c235cf693341f9de9271. While that
commit did fix the mentioned problem, depending on "vos" to set the
volume to be converted as "out of service" is not ideal. Instead, this
volume should be set as offline by the SAFSVolConvertROtoRWvolume RPC,
executed on the volume server.
The proper fix for this problem will be introduced by another commit.
Change-Id: I0ce5ba793fe3c07e535225191b74eeb402ab5bfd
Reviewed-on: https://gerrit.openafs.org/14339
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Add a top-level makefile target to build RPMs for Red Hat distributions
from the currently checked out commit. The resulting rpms are placed in
the packages/rpmbuild/RPMS/<arch> directory.
The rpm target is intended to be a convenience for testing changes to
the rpm packaging or generating packages for local testing.
Change-Id: Id951eb2b03629be59f6258e89e8356fe1fde1ff5
Reviewed-on: https://gerrit.openafs.org/14114
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The makesrpm.pl script generates a source RPM by creating a temporary
rpmbuild workspace, populating the SOURCES and SPECS directories in that
workspace, running rpmbuild to build the source RPM, and finally copying
the resulting source RPM out of the temporary workspace.
The name of the source RPM file created by rpmbuild depends on the
package version and release strings. Unfortunately, the format of the
source RPM file name changed around OpenAFS 1.6.0, so makesrpm.pl has
special logic to find the version string and extra code depending on the
detected OpenAFS version.
Instead of trying to predict the name of the resulting source RPM file
from the OpenAFS version string, and having different logic for old
versions of OpenAFS, use a filename glob to find resulting source RPM
file name in the temporary rpmbuild workspace.
Remove the major, minor, and patch level variables, which were only used
to guess the name of the resulting source RPM file name.
Convert '-' characters to '_' in the package version and package
release, since the '-' character is reserved by rpm as a field
separator.
While here, add the --dir option to specify the path of the generated
source RPM, and change the 'srpm' makefile target to use the new --dir
option, instead of changing the current directory before running
makesrpm.pl. Also, add a dependency on the 'dist' makefile target,
since the the source and document tarballs are required to build the
source RPM.
Add pod documentation and add the --help (-h) option to print a brief
help message, and add the --man option to print the full man page.
With this change, we can build a source RPM even when the .version file
in the src.tar.bz file has a custom format or was created from a
checkout of the master branch or other non-release reference.
Change-Id: I7320afe6ac1f77d4dd38fcc194d41678fde5c950
Reviewed-on: https://gerrit.openafs.org/14116
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
There are no races. Racism does exist though.
Change-Id: I0a4cde55a5f470649eb99c5d7f30c9cec86d9baa
Reviewed-on: https://gerrit.openafs.org/14320
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, 'linktest' in libuafs is built with a weird custom rule
that specifies several various CFLAGS and LDFLAGS, etc. One
side-effect of this is that linktest is built without specifying -O,
even if optimization is otherwise enabled.
Normally nobody would care about the optimization of linktest, since
it's never supposed to be run, but this can cause an error when
building with -D_FORTIFY_SOURCE=1 on some systems (such as RHEL7):
In file included from /usr/include/sys/types.h:25:0,
from /.../src/config/afsconfig.h:1485,
from /.../src/libuafs/linktest.c:15:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
cc1: all warnings being treated as errors
make[3]: *** [linktest] Error 1
For now, to fix this just include $(COMMON_CFLAGS) in the flags we
give for linktest, so $(OPTMZ) also gets pulled in, and building
linktest gets a little closer to a normal compilation step.
Change-Id: I3362dcfe8407825ab88854ae59da4188ed16be9d
Reviewed-on: https://gerrit.openafs.org/14324
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
It looks like a call to ubik_SetLock(.. LOCKREAD) was left in
place in listSuperGroups after locking was moved to ReadPreamble
in commit a6d64d70 (ptserver: Refactor per-call ubik initialisation)
When compiled with 'supergroups', and once contacted by
"pts mem -expandgroups ..", ptserver will therefore abort() with
Ubik: Internal Error: attempted to take lock twice
This patch removes the superfluous ubik_SetLock.
FIXES 135147
Change-Id: I8779710a6d68e4126fc482123b576690d86e4225
Reviewed-on: https://gerrit.openafs.org/14338
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The change associated with gerrit #14300 removed support for older
Linux kernels (2.6.10 and earlier).
The commit 'Import of code from autoconf-archive' (d8205bbb4) introduced
a check for Autoconf 2.64. Autoconf 2.64 was released in 2009.
The commit 'regen.sh: Use libtoolize -i, and .gitignore generated
build-tools' (a7cc505d3) introduced a dependency on libtool's '-i'
option. Libtool supported the '-i' option with libtool 1.9b in 2004.
Update the INSTALL instructions to document a minimum Linux kernel
level and the minimum levels for autoconf and libtool.
Notes: RHEL4 (EOL in 2017) had a 2.6.9 kernel and RHEL5 has a 2.6.18
kernel. RHEL5 has libtool 1.5.22 and autoconf 2.59, RHEL6 has libtool
2.2.6 and autoconf 2.63, and RHEL7 has libtool 2.4.2 and autoconf 2.69.
Change-Id: I235eeffa4adb152e05aab7aca839700816e62c83
Reviewed-on: https://gerrit.openafs.org/14305
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Inside release_conns_user_server, connection vector is traversed and after
destroying a connection new eligible connection is found on which NatPing
event will be set. Ideally there should be only one connection on which
NatPing should be set but in current code while traversing all connection
of server a NatPing event is set on all connections to that server. In
cases where we have large number of connection to a server this can lead
to huge number of “RX_PACKET_TYPE_VERSION” packets sent to a server.
Since this happen during Garbage collection of user structs, to simulate
this issue below steps were tried
- had one script which “cd” to a volume mount and then script sleeps for
large time.
- Ran one infinite while loop where above script was called using PAG
based tokens (As new connection will be created for each PAG)
- Instrumented the code, so that we hit above code segment where NatPing
event is set. Mainly reduced NOTOKTIMEOUT to 60 sec.
To fix this issue set NatPing on one connection and once it is set break
from “for” loop traversing the server connection.
Change-Id: Ia38cec0403fde76cdd59aa664bd261481e2edee6
Reviewed-on: https://gerrit.openafs.org/14312
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reported symptoms:
If a 'vos rename' is interrupted after it has locked the volume and
replaced the VLDB entry, but before it has unlocked the volume, the
volume will remain locked. However, the locked volume will NOT be
listed as locked in any vos commands that display locked status (see
below for details).
Background:
Most vos write operations lock the VLDB volume entry before proceeding,
then release the volume lock when finished. This is accomplished via
VL_SetLock and VL_ReleaseLock, respectively.
VL_SetLock always sets these members in the VLDB volume entry:
- flags is modified to set the required VLOP_* code bit as specified
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to the current time
VL_ReleaseLock always sets them as follows:
- flags is cleared of any VLOP_* code bit
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to 0
VL_ReplaceEntry(N) may also optionally clear each of these members:
- flags operation bits may be explicitly cleared via LOCKREL_OPCODE
- LockAFSid may be explicitly cleared via LOCKREL_AFSID
- LockTimestamp may be explicitly cleared via LOCKREL_TIMESTAMP
When all 3 options are specified, VL_ReplaceEntry also does the
functional equivalent of a VL_ReleaseLock. Most vos operations use this
method. However, when no lock release options are specified on
VL_ReplaceEntry(N), the VLDB entry is simply replaced with the supplied
entry. This includes whatever flags values are specified in the
supplied entry; therefore, this amounts to an additional, implicit way
to set or modify the flags.
Root cause:
'vos rename' (UV_RenameVolume) is the only vos operation that does all
of the following things:
- accepts a replacement volume entry that was obtained before VL_SetLock
(and thus does NOT have any lock flags set)
- issues VL_SetLock (which sets the lock flag in the VLDB)
- issues VL_ReplaceEntry(N) with the original unlocked entry, and with
no lock release options (thus with explicit intent to leave the lock
flag unchanged, but inadvertently doing an implicit clear of the lock
flag in the VLDB)
- (performs some additional volserver work)
- issues VL_ReleaseLock to release the volume lock
Therefore, if 'vos rename' is cancelled or killed before reaching the
final VL_ReleaseLock step, the VLDB entry is left with the lock flags
cleared but the LockTimestamp still set. As we will see below, this
'half-locked' state produces confusing results from other vos commands.
Detection of locked state:
The 'vos lock' command (and all other vos commands that issue
VL_SetLock) use the lock timestamp to determine if a volume is locked.
However, several other vos commands ('vos listvldb <vol>', 'vos examine
<vol>', 'vos listvldb -locked') use the VLDB entry's lock flags (not the
lock timestamp) to determine if the volume is locked. Therefore, if the
lock flags have been cleared but the lock timestamp is still set, these
commands fail to detect that the volume is still locked. Yet an
administrator's 'vos lock <volume>' will still fail with:
Could not lock VLDB entry for volume <volume>
VLDB: vldb entry is already locked
This is the external manifestation of the 'half-locked' state.
Workaround and fix:
This scenario has a simple workaround: 'vos unlock <volume>'. However,
to avoid this confusing outcome in the first place, modify the 'vos
rename' logic so that the lock flags are no longer inadvertently
cleared. Now, if the 'vos rename' is interrupted before the volume is
unlocked, it will still appear locked in normal vos command output.
Change-Id: I6cc16d20c4487de4e9a866c6f0c89d950efd2f7d
Reviewed-on: https://gerrit.openafs.org/14157
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Since the original IBM code import, hndle_param_tail has been dead code.
It was later ifdef'd out in commit 8f2df21ffe59
'pull-prototypes-to-head-20020821'
Remove the dead code from the tree.
No functional change is incurred by this commit.
Change-Id: I29128eecc93a5871f5bb9369c3983baf5b537beb
Reviewed-on: https://gerrit.openafs.org/14322
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
