src/libafs/MakefileProto.AIX.in contains rules for various versions of
AIX, but did not have any case for AIX 7.1 or 7.2 This causes build
failures on those platforms. Added in the missing entries for rs_aix71
and rs_aix72.
Reviewed-on: https://gerrit.openafs.org/15145
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0c43fe64dd885aed1ec1be4a2419e6396e583ec5)
Change-Id: I68315c09eb3d6b2e30ea759d4f9bf5726a98e5d7
Reviewed-on: https://gerrit.openafs.org/15380
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The original code used strcpy(), etc. Some compilers have begun
to raise warnings that the use of these functions is unsafe, and
in the case of newer Linux kernels in particular, have caused the
build to fail outright. To adapt to these compilers/kernels, the
code was changed to leverage strlcpy(), snprintf(), etc. as they
are safer. AIX does not provide these functions within the
kernel. For some of the functions such as strlcpy(), etc. we
can use replacement functions from libroken within the AIX kernel
extension. However, libroken does not offer a suitable
replacement for snprintf(), and instead the same purpose can be
accomplished by using strlcpy() and multiple calls to strlcat().
Reviewed-on: https://gerrit.openafs.org/15122
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 54dbd474a5bd43cf62a226802593b062069509ce)
Change-Id: Ie59450a91fcb374b1362f0bd88a93f258597a22d
Reviewed-on: https://gerrit.openafs.org/15378
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
After a build, running make clean leaves the following objects:
src/dir/test/dtest.o
src/libuafs/libuafs.a
src/libuafs/*.o
src/roken/*.o
Add a few rules to the various Makefiles to ensure that we clean
up those files as well.
Reviewed-on: https://gerrit.openafs.org/15119
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ad2b880c3791046883f8c0ef15f327c85e013b5b)
Change-Id: Iaef185ec0e045ded8453f6b276e6b6b9075b3388
Reviewed-on: https://gerrit.openafs.org/15377
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Include sys/malloc.h in AIX's osi_sleep.c. This resolves a build
failure in which pinned_heap is not defined.
The commit below introduced code to resolve an issue on AIX 5.3:
5e5bfa6b9401ebc1fa5446e208cf46c15943c411
Author: Tom Keiser <tkeiser@sinenomine.net>
Date: Mon Jun 25 21:22:49 2007 +0000
aix53-avoid-wait-crash-20070625
newp = (afs_event_t *) xmalloc(sizeof(afs_event_t), 5, pinned_heap);
pinned_heap has always been defined in sys/malloc.h since at least
AIX 4.1. It is likely that the aix53-avoid-wait-crash-20070625
commit did not compile, or that sys/malloc.h was included
elsewhere at the time.
Reviewed-on: https://gerrit.openafs.org/15108
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 615681710a38bd1a92f2c476df9fdab7ac1d9bdd)
Change-Id: I3fcfc1c7e3e26e927d0a8e2a233c4c12b0781308
Reviewed-on: https://gerrit.openafs.org/15376
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Remove make step in error. This was preventing the install of the
built kernel module on AIX when not using Transarc-style paths via
the make install step.
Reviewed-on: https://gerrit.openafs.org/15114
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 319d361499af933451425acaeabac9bc6548c96b)
Change-Id: I252de19363824ae23187b7b9da878137814ab09d
Reviewed-on: https://gerrit.openafs.org/15375
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The symbol RXAFS_OpCodeIndex is consumed by the fileserver via the various
"opcode_<RPC Name>" macros produced by rxgen. The functionality is provided
by liboafs_fsint but RXAFS_OpCodeIndex was omitted from the export symbol list.
This went undetected because we use static linking for the fileserver, and
libtool does not enforce export symbol lists while static linking, on platforms
other than AIX. Recent efforts to revive the AIX build illuminated the error,
which we resolve by adding RXAFS_OpCodeIndex to the export list.
Reviewed-on: https://gerrit.openafs.org/15112
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 91532e3142751468aa8f7bbabe7de087b77259bf)
Change-Id: Ia665937002137dca1a8ec4573b4fe8932fc90dd0
Reviewed-on: https://gerrit.openafs.org/15373
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Make sure that cfgexport and cfgafs are installed with execute
permissions. These executables load the AIX kernel modules into
the running kernel and are called by the rc.afs script.
Reviewed-on: https://gerrit.openafs.org/15116
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>
(cherry picked from commit 1a4da8868fd32e928def64599bb6ec9d6b455423)
Change-Id: I575d89164ef386d1cdf562b2206b502b3c2e8582
Reviewed-on: https://gerrit.openafs.org/15371
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Include sys/time.h in AIX's osi_machdep.h. This resolves a build
issue where the struct timestruc_t was not defined.
Reviewed-on: https://gerrit.openafs.org/15107
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b5b34278b26ca22eea988fb18d738969dd608ede)
Change-Id: Icb91b47d819f1bcc0e277a482f2a22d87dc8bc6c
Reviewed-on: https://gerrit.openafs.org/15370
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
AIX 7.2 doesn't seem to have libcsys, netinet.exp, sockets.exp, or
statcmd.exp available. To allow for our IMPORTS and LDFLAGS to change
depending on the AIX version, introduce the autoconf vars TSM_IMPORTS
and TSM_LIBS, which do not contain the missing libs on AIX 7.2, so we
can build on AIX 7.2.
Reviewed-on: https://gerrit.openafs.org/14703
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit a912db315b4f29673808a7f900eb038ebd7b89c2)
Change-Id: Ic106b893f212b33c85bded8443bcb782205f290c
Reviewed-on: https://gerrit.openafs.org/15369
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The roken-common.h header defines an empty macro called __attribute__
when HAVE___ATTRIBUTE__ is not defined. This macro conditionally removes
the `format' function attributes in the roken headers at compile time.
Unfortunately, the empty __attribute__ macro will also clobber other
attribute types encountered after the roken.h header inclusion.
This is not an issue when building under gcc or clang, since the empty
attribute macro will not be defined. However Solaris Studio supports a
subset of the function attribute types, with `format' not currently
supported. This means roken will define an empty __attribute__ macro,
which prevents the use of other attribute types.
This commit does not change the roken files directly because they are
external. Instead, the processing of the roken.h.in file has been
updated to undefine the __attribute__ macro at the end of the generated
roken.h header.
Reviewed-on: https://gerrit.openafs.org/12961
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 388eaec3452ed4b18a95ee34efcbe4cf64814701)
Change-Id: Id93ec414a59a2f5866e503601b7e42bbb4f8d66a
Reviewed-on: https://gerrit.openafs.org/15367
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit 'rx: Do not ignore RXS_* op errors' (635594d6c) changed the
rx_securityOps.op_DestoryConnection()'s signature to a void return.
This is a change to a public interface.
To maintain backward compatibility within openafs 1.8.x, restore
op_DestoryConnection's signature back to returning an 'int', and revert
the changes to rxkad_DestroyConnection() so it returns an int value.
Since returning an error value from this function doesn't make sense,
as noted by commit '635594d6c', always return a 0 value.
This is a 1.8.x specific commit
Change-Id: I9685ac884a10298ae8faad012717499874f25316
Reviewed-on: https://gerrit.openafs.org/15334
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit 3be5880d (afs: Avoid panics in afs_InvalidateAllSegments) added
an assert to check that vcache->lock is write-locked before we call
afs_InvalidateAllSegments_once from a background operation.
However, afs_InvalidateAllSegments_once should always be called with
vcache->lock write-locked; there's nothing specific about the
backgrounded call that requires this. So to make sure we catch all
cases, move this assert to afs_InvalidateAllSegments_once itself.
Also remove the conditional check for WriteLocked(&avc->lock) in here,
since clearly avc->lock must be write-locked (and actually is, since
change Ic309e4006bf47bcb38fa2b53bf103e0c645a856d "afs: write-lock
vcache->lock in afs_InactiveVCache").
Add some comments to this function while we're here, to more clearly
indicate what locks are needed.
Reviewed-on: https://gerrit.openafs.org/14592
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 72223e0958c2d7cddd968970547dd73fc3cc1351)
Change-Id: I9acf5599a8ef1e724a00cf362695fe34ca87c0bf
Reviewed-on: https://gerrit.openafs.org/15331
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Each server process can log a couple of different warnings about the
server keys found on disk:
- If afsconf_GetLatestKey() returns success (indicating a single-DES
key is present), we call LogDesWarning().
- If afsconf_CountKeys() returns 0 (indicating there are no keys at
all on disk), we log a warning that all authenticated access will
fail.
Currently, the code to do these checks and log the relevant warning is
duplicated across the startup code for nearly every server process. To
avoid this duplication, and to make sure the checks aren't
accidentally skipped for anyone, move these checks to
afsconf_BuildServerSecurityObjects, which every server process calls.
We must add an additional parameter to
afsconf_BuildServerSecurityObjects to handle the different logging
mechanism these servers use, but afsconf_BuildServerSecurityObjects is
declared in a public header (cellconfig.h), and is exported in a
public library (libafsauthent). So to avoid changing a public symbol,
introduce a new variant of the function, called
afsconf_BuildServerSecurityObjects_int. Declare this in a new internal
header, authcon.h.
We don't have easily-usable logging functions for upserver and butc,
so just don't log the warnings for those. For ubik servers, don't
update ubik_SetServerSecurityProcs to use the new function; the
initial call to afsconf_BuildServerSecurityObjects_int in the server's
startup code will cover logging the warning on startup.
Reviewed-on: https://gerrit.openafs.org/10831
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2630e70550defc664efa0952589cf82ed3c51796)
Change-Id: Ib37b92cfccbf161d72d2db73eeaea6fd8b312961
Reviewed-on: https://gerrit.openafs.org/15316
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Update all three copies in the tree, and the rpm specfile.
Reviewed-on: https://gerrit.openafs.org/15305
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1b92c766f1cf52b3bae3a00e08d40a2334bf9f24)
Change-Id: I26fb3ff045d41b840fc6565d1a17aca8e75fcd30
Reviewed-on: https://gerrit.openafs.org/15323
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Remove the obsolete kdump debugging tool from the tree. Remove and
clean up the preprocessor tests associated with KDUMP, KDUMP_RX_LOCK and
KDUMP_KERNEL. Clean up the autoconf and Makefiles to remove kdump and
the associated autoconf and Makefile vars XLIBELFA and XLIBKVM.
The kdump utility has not been well maintained; for some platforms it
fails to build (e.g. Solaris 11). For Linux, the makefile does not
even try to compile the kdump source but instead creates the kdump file
via touch.
The intended functionality of kdump has been replaced by various kernel
debugging tools, such as dtrace or systemtap.
Reviewed-on: https://gerrit.openafs.org/14623
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 489cfb587a87ab53817ad0b4eccd65d9f7b332e2)
Change-Id: Idf9582fd65482f32e7f13af0bf734c2b970da757
Reviewed-on: https://gerrit.openafs.org/15315
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit d1923139 (irix kill efs and start pruning pre-65) removed all
files that defined AFS_SGI64_ENV and earlier, but didn't remove that
code that depended on those defines. In addition, there has been code
in the tree that checks for AFS_SGI53_ENV since OpenAFS 1.0, but
nothing has ever defined Irix 5.3 support in OpenAFS.
Remove all of this obsolete code. Change all references to
AFS_SGIXX_ENV to AFS_SGI_ENV, and assume AFS_SGI_ENV is defined in all
IRIX dirs. Consolidate some of the resulting ifdef logic
appropriately.
Reviewed-on: https://gerrit.openafs.org/14230
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e0c288416df59a117cd818ada930fd1259955983)
Change-Id: Ie188b9f108bf55cfae7fcb358a1de21bad076f11
Reviewed-on: https://gerrit.openafs.org/15314
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit 248da50aa56f19bdc8b2b322f5e17b3d2a363dce 'icl 64 bit platform
rationalization' introduced support for 64-bit ICL_TYPE_POINTER and
ICL_TYPE_LONG for fstrace running on DARWIN kernels. However, it
neglected to make the matching change in the fstrace utility itself,
which reads and reports these trace entries. The result is that all
fstrace records which contain 64-bit pointers or longs are misreported
as 32-bit values. Furthermore, any subsequent values in the same
fstrace record are also misreported because the offsets are now
incorrect.
Move the definition of ICL_LONG from afs_icl.c to icl.h so fstrace.c may
share the ICL_LONG logic and value.
Modify fstrace to use logic similar to the recording logic in afs_icl.c
so that the correct size and offsets are maintained while decoding the
contents of each fstrace record.
We can use the build-time value of ICL_LONG (rather than the runtime
value of afs_sizeofLong) because the difference only matters for SGI62
32-bit kernels. It is unknown whether the existing code works correctly
for SGI62 32-bit mode, but this commit should not affect that support
either way.
Reviewed-on: https://gerrit.openafs.org/14558
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit adf08b464efa8c29256dc7b261b10b60cc31119d)
Change-Id: Ie3ef988d209a984839751051d7bd9a62369b5b11
Reviewed-on: https://gerrit.openafs.org/15313
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
An earlier version of the OpenAFS code used an unusual preprocessor
macro for the function osi_Msg and osi_VMsg. This causes problems
on newer Linux kernels. The macro was replaced with a function
leveraging vprintf, etc. These functions are not available in the
AIX kernel, where our only option is printf. However, AIX does
provide these functions in libc. This change ensures we only use
printf when building the AIX kernel module.
Reviewed-on: https://gerrit.openafs.org/15118
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8b1beaffb40c93ddab50c75b37f3de5ae517a849)
Change-Id: Id06478cbc87b6965c021f26902e13bdfc2ef83d5
Reviewed-on: https://gerrit.openafs.org/15309
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Currently, afs_osi_suser is declared with a void* argument, even
though its only argument is always effectively a afs_ucred_t*. This
allows us to call afs_osi_suser with any pointer type without the
compiler complaining. Currently, some callers call afs_osi_suser with
an incorrectly-typed afs_ucred_t** instead, like so:
func(afs_ucred_t **credpp)
{
afs_ucred_t **acred = *acredpp; /* incorrect assignment */
if (afs_osi_suser(acred)) {
/* ... */
}
}
The actual code in the tree hides this to some degree behind various
function calls and layers of indirection (e.g. afs_suser()), but this
is effectively what we do. This causes compiler warnings because we
are doing incorrect pointer assignments, but the end result works
because afs_osi_suser actually uses an afs_ucred_t*.
The type confusion makes it very easy to accidentally give the wrong
type to afs_osi_suser. This only really matters on SOLARIS, since that
is the only platform that actually uses its argument to
afs_osi_suser().
To fix all of this, just declare afs_osi_suser as taking an
afs_ucred_t*, and fix all of the relevant functions to handle the
right type.
Reviewed-on: https://gerrit.openafs.org/14085
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4ce922d339777faf647f7129f5ae3f173a7870b1)
Change-Id: I1a6ce7788e86c32e554f87785f96f1d7b56d1496
Reviewed-on: https://gerrit.openafs.org/15308
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
OpenAFS code requires osi_timeval32_t to have 32-bit sizes for members
tv_sec and tv_usec - a total of 8 octets. One symptom of a
misdefinition may be incorrect operation of xstat_cm_test, which relies
on wire representations of time being 8 bytes on both the client and
server side.
In order to prevent incorrect sizes of osi_timeval32_t, add a static
assert.
Reviewed-on: https://gerrit.openafs.org/14195
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 10c5ba12ace51440c7e98add83465a7018961e6f)
Change-Id: I9584a53154ffe673d19191a0bd9f6a92d6daf140
Reviewed-on: https://gerrit.openafs.org/15304
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Fix up indentation and white space within preprocessor statements.
Remove multiple blank lines
Fix #endif comments so they match the #if
Split long #define lines
RX_PACKET_TYPES
rx_MaxUserDatasize,
RXS_OP
RXS_SetConfiguration
Note, this commit does not refactor any preprocessor statements.
Reviewed-on: https://gerrit.openafs.org/14629
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>
(cherry picked from commit 21df433134a059de8d3b3b46bb0892b34d910364)
Change-Id: I197897f4f7e81bd2f931e3decefe447caae0c5d9
Reviewed-on: https://gerrit.openafs.org/15301
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Several places in rx call an RXS_* security layer operation, but
ignore the error code. Though errors for these operations are rare or
impossible currently, if they ever do return an error there could be
noticeable consequences, like a connection getting an uninitialized
challenge nonce, or sending a challenge packet with uninitialized
payload.
Change these call sites to record and handle the error. Errors from
the security class normally mean aborting the entire conn, but for
many operations we need to behave differently:
- For RXS_DestroyConnection, errors don't make sense, since we're just
freeing an object. Change the op to return void, and update our
implementations of DestroyConnection to match.
- For RXS_GetStats, just clear the relevant stats structure on error
instead. This change also results in us clearing the stats structure
when there is no security class associated with the connection;
previously we just reused the same struct data as the previous conn.
- For RXS_CreateChallenge, aborting the entire conn is difficult,
because some code paths have callers that potentially lock multiple
calls on the same conn (rxi_UpdatePeerReach -> TryAttach ->
rxi_ChallengeOn -> RXS_CreateChallenge), and aborting our conn
requires locking every call on the conn. So instead we just
propagate an error up to our callers, and we abort just the call we
have.
- For RXS_GetChallenge, we cannot abort the conn when
rxi_ChallengeEvent is called directly, because the caller will have
the call locked. But when rxi_ChallengeEvent is called as an event
(when we retry sending the challenge), we can.
- For RXS_SetConfiguration, propagate the error up to our caller.
Update all rx_SetSecurityConfiguration callers to record and handle
the error; all of these are during initialization of daemons, so
have them log an error and exit.
Reviewed-on: https://gerrit.openafs.org/13522
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 635594d6cceba6de4e09be5a9e9b908f7d16697d)
Change-Id: I800516335f6ab0d01d2b29dd0ceba9213dafde59
Reviewed-on: https://gerrit.openafs.org/15300
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
afs_remunlink is called to delete a file on the fileserver after it
has been silly-renamed (due to being unlinked while the file is open).
Sometimes current->fs is NULL when this happens, typically when the
process is shutting down, after current->fs has been freed and file
handles are getting released. During afs_remunlink, we need to
interact with our cache files, and so we call dentry_open, which calls
security_file_open, which calls into the configured LSM for security
checks. Certain LSMs (e.g. Crowdstrike Falcon) will panic the kernel
in this situation if current->fs is NULL.
There's no way to skip the LSM hooks, or to flag to the LSM that we're
making an in-kernel VFS call, so the only way to avoid these panics is
to do our I/O in another thread. Fortunately, we already have a way to
defer afs_remunlink calls to a background daemon (CUnlinkedDel), since
we already do this in some cases (when someone else is holding
afs_xvcache or afs_xdcache).
So, to avoid the panic in the above scenario, defer calls to
afs_remunlink to a background daemon using CUnlinkedDel when
current->fs is NULL, and we're using a disk cache.
More details on this issue is discussed at following thread:
https://lists.openafs.org/pipermail/openafs-info/2021-March/043073.html
Reviewed-on: https://gerrit.openafs.org/14691
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jonathan Billings <jsbillings@jsbillings.org>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit 9e043e1a0cdca7624de3e27872273263c57027ed)
Change-Id: If85d992c2639e59af7578ebc295f91d4f8462b69
Reviewed-on: https://gerrit.openafs.org/15295
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>
Since the original IBM code import, the comments for
afs_InvalidateAllSegments indicate that vcache->lock W should be held at
entry. However, even back then, only LINUX and IRIX honored this
requirement when the 'inactive' vnode operation reached
afs_InvalidateAllSegments.
Over the years, a number of commits have changed the operation and
locking for the LINUX inactive vnode op:
5293aa35617a6ad35980ce16fdf492ea960cc18a linux-iput-and-glock-changes-20010130
e8591334602e5e8dad78dc6426d3c44d564572c1 linux-osi-clear-inode-locking-fix-20010816
652f3bd9cb7a5d7833a760ba50ef7c2c67214bba linux-dynamic-inodes-20050710
e0d9e434bb778a2507c1cd6d96c1faa2071f2b2c put-inode-speedup-20050815
b21c13dc3ab751118220dc31276995050841a1ae linux-dentry-iput-20060813
Eventually, ac52e2f3c0bec9298d020de963036409165f380e
linux-dont-lock-around-inactivevcache-20061010 removed the vcache->lock
from afs_dentry_iput (the current OpenAFS handler for inactive vcaches).
The commit message states:
"iafs_InactiveVCache() [sic] calls afs_InvalidateAllSegments() which says
it should be called with the vnode locked. so the lock should
probably be moved to afs_InactiveVCache() so it can be droppped
before calling afs_remunlink()."
Unfortunately, the vcache->lock was never moved to afs_InactiveVCache.
Finally, 3be5880d1d2a0aef6600047ed43d602949cd5f4d 'afs: Avoid panics in
afs_InvalidateAllSegments' introduced a background operation
BInvalidateSegments that contains an assert for vcache->lock. This
assert has exposed the existing lack of proper locking for some paths to
afs_InvalidateAllSegments by causing a kernel panic:
d_iput -> afs_dentry_iput -> afs_InactiveVCache ->
afs_InvalidateAllSegments -> afs_BQueue(BOP_INVALIDATE_SEGMENTS..) ->
BInvalidateSegments -> osi_Assert(WriteLocked(&vcache->lock))
Prevent the panic by modifying afs_InactiveVCache to obtain vcache->lock
W before calling afs_InvalidateAllSegments, and dropping it before
calling afs_remunlink.
Thanks to Chaskiel Grundman for reporting and diagnosing the problem.
Reviewed-on: https://gerrit.openafs.org/14584
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f02be4e3b89382317a3baa496f9cb672cdb4b32a)
Change-Id: I38dc6e5d70b1743b96d2a227d28e58d1950b5835
Reviewed-on: https://gerrit.openafs.org/15324
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Currently, AFSFid fields are printed as signed integers. As a result,
large numbers can be erroneously printed as negative numbers.
To fix this problem, print AFSFid fields as unsigned integers.
Reviewed-on: https://gerrit.openafs.org/14950
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 29a89c82ad422f88b0898ad07e773dc2e71be983)
Change-Id: Ieb303354f1332abb8278e62252c4842baa2132c7
Reviewed-on: https://gerrit.openafs.org/15302
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
A couple of places in src/volser currently have some logic to get the
size and blocksize of a file. The existing logic is nontrivial due to
platform-specific quirks, and ignores afs_fstat errors.
To fix these issue and consolidate the code into one place, introduce
a new function, FDH_BLOCKSIZE, which gets the file size and blksize.
Update the places in src/volser to use the new function.
Reviewed-on: https://gerrit.openafs.org/14662
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 939787565d5be55a8a803043dbc4f27b3f11b906)
Change-Id: I32c73e87fa0b6b0b45971e06b8d8c5653f882f7b
Reviewed-on: https://gerrit.openafs.org/15303
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>
There are several compiler errors and warnings when building an out of
tree program that includes "afs/afs.h".
- Errors for unknown type names 'afs_ucred_t' and 'wait_queue_head'
.../afs/afs.h:1542:16: error: unknown type name ‘afs_ucred_t’
... | afs_set_cr_uid(afs_ucred_t *cred, uid_t uid) {
.../afs/afs.h:1605:5: error: unknown type name ‘wait_queue_head_t’
... | wait_queue_head_t cond;
- Warnings about declaring structures within missing declarations for
the structs: osi_File, dcache and afs_FetchOutput
.../afs/afs.h:1486:36: warning: ‘struct osi_file’ declared inside
parameter list will not be visible outside of this definition or
declaration
... | int (*read)(void *rock, struct osi_file *tfile,
afs_uint32 offset,
- Unable to find the file for the include opr/jhash.h
The missing type name 'afs_ucred_t' is due to miss-placed declarations
for some kernel only functions.
The type name 'wait_queue_head' is a data type for Linux kernel modules.
The warnings for the missing declarations are due to either references
to the structures before they are declared, or because they are not
available in any of the other public header files.
To fix the unknown type name afs_ucred_t, relocate the function
declarations that reference 'afs_ucred_t' into the KERNEL only section
(since afs_ucred_t is a kernel specific type).
To fix the unknown type name 'wait_queue_head', relocate the afs_event
structure and the afs_evhasht variable to be within the KERNEL only
section.
To resolve the warnings associated with the structures, simply declare
the structure names before they are referenced. All references that
are resulting in the warnings are declarations for pointers.
Relocate the include for opr/jhash.h and the define for VCSIZE into the
kernel block.
Reviewed-on: https://gerrit.openafs.org/14857
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 92342b099dd5ea539efc5ad119d36a87647c0895)
Change-Id: Ib321796e473495d7d8774133c5e690b53bb26c17
Reviewed-on: https://gerrit.openafs.org/15299
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>
Our libafs build logic involves a few targets that 'cd' into a
per-kernel subdir: notably INSTDIRS and DESTDIRS (the targets to 'make
install' or 'make dest' our kernel modules) and COMPDIRS (the target
to setup/build the kernel module).
Both of these potentially 'cd' into a subdirectory (e.g. MODLOAD64),
and run some make rules. Since INSTDIRS and COMPDIRS are different
targets and don't depend on each other for many platforms, running
those rules can happen in parallel. After they 'cd' into the relevant
dir, they run a new 'make' in a subshell, and so underlying rules for
building e.g. AFS_component_version_number.c are not serialized.
So for a parallel build on, say, Solaris, we can encounter errors when
two sub-makes try to make AFS_component_version_number.c at the same
time, which looks something like this (with various lines output from
other sub-processes mixed in):
cd src && cd sys && gmake install
gmake[3]: Leaving directory '/[...]/src/libuafs'
rm -f AFS_component_version_number.c.NEW
/opt/developerstudio12.6/bin/cc [...] -D_KERNEL -DSYSV -dn -m64 -xmodel=kernel -xvector=%none -xregs=no%float -Wu,-save_args -o AFS_component_version_number.o -c AFS_component_version_number.c
mv: cannot access AFS_component_version_number.c.NEW
gmake[4]: *** [/[...]/src/config/Makefile.version:13: AFS_component_version_number.c] Error 2
gmake[4]: Leaving directory '/[...]/src/libafs/MODLOAD64'
gmake[3]: *** [Makefile:85: solaris_instdirs] Error 2
gmake[3]: *** Waiting for unfinished jobs....
To avoid this, just make INSTDIRS and DESTDIRS depend on COMPDIRS, so
we can make sure they don't run at the same time.
Reviewed-on: https://gerrit.openafs.org/14137
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3db8c37e8ef6bea0f03ef6b8f82ed93d52937d7d)
Change-Id: Ied7875e885f51a6d3f00d65f1783df9439a18ae3
Reviewed-on: https://gerrit.openafs.org/15298
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Currently, our COMPDIRS make rule for SOLARIS libafs builds looks like
this:
${COMPDIRS} ${INSTDIRS} ${DESTDIRS}:
for t in $(KOBJ) ; do
# set some variables ; \
cd $$t ; \
$(MAKE) $@_libafs || exit $$? ; \
cd ../ ;\
done
And Makefile.common has this:
all: setup $(COMPDIRS)
Where the 'setup' rule creates the $(KOBJ) dirs and sets up some
symlinks.
For parallel builds, this means that our commands in the ${COMPDIRS}
target can be running in parallel with the 'setup' target, and so our
$(KOBJ) dirs may not exist by the time we try to 'cd $$t'.
For single-KOBJ platforms this actually largely works, since the 'cd'
will fail, but then the subsequent 'make' will run (just in the wrong
dir), but this can cause us to wastefully re-compile the same source
files (and cause some possibly confusing error messages). For
platforms with multiple KOBJs, this causes obvious problems, since we
don't cd into each KOBJ dir.
To solve this, just have the ${COMPDIRS}/etc rule depend on setup, so
we know that 'setup' has finished running. Also change our way of
'cd'ing into each KOBJ dir to actually cause the rule to fail, to make
any errors here more obvious and consistent.
Reviewed-on: https://gerrit.openafs.org/13344
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 00aa9200be86b187c903503e56b2af55639ea2b8)
Change-Id: I4b68cc8aa7b50f792152c2c00da6c6e3684755b7
Reviewed-on: https://gerrit.openafs.org/15297
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Depending on how the ncurses libraries were built the external symbol
'LINES' may be replaced with the '_nc_LINES' external symbol. Because
the symbol 'LINES' may or may not be present, the autoconf test can fail
to detect the correct libraries needed for curses support.
Add an additional AC_CHECK_LIBs for the symbol _nc_LINES (within the
ncurses or tinfo libraries) when setting the $LIB_curses.
This commit was adapted from the openSuSE source packaging for openafs.
Background: when ncurses is built with --enable-reentrant, LINES is
defined as a C preprocessor macro that expands to a call to _nc_LINES
Reviewed-on: https://gerrit.openafs.org/14889
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ralf Brunckhorst <rbrunckhorst@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c98994dd116121af75f6df6891e706957c6c953d)
Change-Id: I6eb15897f48eb93d72739965c10b5f51b21d7336
Reviewed-on: https://gerrit.openafs.org/15296
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit 981bc005f8161ca9ee52ea281c7d73e0e4e2461a refactored PNewStatMount
and PFlushMount by moving their common logic to a new function
afs_LookupName(). In this function, the output parameters are zeroed.
However, this is done before checking that their pointers are valid.
Add additional checks before memset().
Reviewed-on: https://gerrit.openafs.org/15283
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e2890626bc11964dd96cde0d7d8dd7fdfcf90857)
Change-Id: I213ea7e23e01e7902919919581ad1d8e596303a2
Reviewed-on: https://gerrit.openafs.org/15292
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
When using the proc_ops structure, set .proc_lseek explicitly rather
than leaving it unset. This field has always been present in proc_ops,
but prior to Linux 5.13, it could be unset, causing default_llseek to be
used. Starting with commit d4455faccd6 (proc: mandate ->proc_lseek in
"struct proc_ops"), this field is now mandatory.
This fixes a problem which would cause an oops if llseek(2) is called
on /proc/fs/openafs/afs_ioctl.
Reviewed-on: https://gerrit.openafs.org/14918
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 68851b782ca2cb5e4ae7457255841f44f3bef15c)
Change-Id: Ifd3a517f595cfef7fd9dd1fdd3f3aca8fe1bc25f
Reviewed-on: https://gerrit.openafs.org/15286
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The Linux 6.2 commit:
"folio-compat: remove lru_cache_add()" (6e1ca48d0)
removed the lru_cache_add() function (which was introduced in Linux 5.8)
The replacement function is folio_add_lru(), which was introduced with
the Linux 5.16 commit:
"mm/lru: Add folio_add_lru()" (0d31125d2d)
Reviewed-on: https://gerrit.openafs.org/15227
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit cfac0df9cd7152be2672c665442aac84215494d6)
Change-Id: I74535bf83cdd47c9dd60a7114ec7694ae9981c9b
Reviewed-on: https://gerrit.openafs.org/15281
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The build for the openafs Linux kernel module fails on RHEL9.1 with an
undefined function reference for block_dirty_folio().
RedHat 9.1 includes the Linux commit:
fs: Add aops->dirty_folio (6f31a5a261db)
which added the dirty_folio member to the address_space_operations
structure.
However RedHat 9.1 does not include the following 2 Linux commits:
fs: Convert __set_page_dirty_buffers to block_dirty_folio (e621900ad2)
which introduced block_dirty_folio() as a function that could be used to
handle the address_space_operations's dirty_folio operation.
And
fs: Remove aops ->set_page_dirty (3a3bae50af)
which removed the set_page_dirty member in the address_space_operations
structure.
The openafs commit:
Linux-5.18 replace set_page_dirty with dirty_folio (6aa129e743e88)
introduced an autoconf test that checks for the presence of aops'
dirty_folio member and assumed that the Linux function
block_dirty_folio() was also provided (since all three of the above
Linux commits were added in Linux-5.18-rc1).
Without the (e621900ad2) commit, the openafs Linux kernel module fails
to build since block_dirty_folio() is not defined by Linux.
Introduce new autoconf tests that checks for the presence of the
block_dirty_folio() function.
Change the preprocessor conditional within LINUX/osi_vnodeops.c to only
use dirty_folio if aops has dirty_folio and block_dirty_folio() is
available. When block_dirty_folio() is not available, we continue to
use the older set_page_dirty method, which remains a valid method until
its removal by the (3a3bae50af) Linux commit.
Note: Reviewing the Linux source for RedHat 9.1 shows that there is only
one location that is defining the dirty_folio member and it is providing
its own function instead of relying on block_dirty_folio.
Reviewed-on: https://gerrit.openafs.org/15199
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e7737edb932a1c4d55a2551a44e481b40310c96d)
Change-Id: If29ad539c5530289ffa49aa1fa489f612e9f5c78
Reviewed-on: https://gerrit.openafs.org/15228
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The vos convertROtoRW command converts a RO volume into a RW volume.
Unfortunately, the RO volume in question is not set as "out of service"
during this process. As a result, accesses to the volume being converted
can leave volume objects in an inconsistent state.
Consider the following scenario:
1. Create a volume on host_b and add replicas on host_a and host_b.
$ vos create host_b a vol_1
$ vos addsite host_b a vol_1
$ vos addiste host_a a vol_1
2. Mount the volume:
$ fs mkmount /afs/.mycell/vol_1 vol_1
$ vos release vol_1
$ vos release root.cell
3. Shutdown dafs on host_b:
$ bos shutdown host_b dafs
4. Remove RO reference to host_b from the vldb:
$ vos remsite host_b a vol_1
5. Attach the RO copy by touching it:
$ fs flushall
$ ls /afs/mycell/vol_1
6. Convert RO copy to RW:
$ vos convertROtoRW host_a a vol_1
Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving
the volume object for the RO copy set as VOL_STATE_ATTACHED (on success,
this volume should be set as VOL_STATE_DELETED).
7. Add replica on host_a:
$ vos addsite host_a a vol_1
8. Wait until the "inUse" flag of the RO entry is cleared (or force this
to happen by attaching multiple volumes).
9. Release the volume:
$ vos release vol_1
Failed to start transaction on volume 536870922
Volume not attached, does not exist, or not on line
Error in vos release command.
Volume not attached, does not exist, or not on line
To fix this problem, take the RO volume offline during the vos
convertROtoRW operation.
Reviewed-on: https://gerrit.openafs.org/14066
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 32d35db64061e4102281c235cf693341f9de9271)
Change-Id: I00a99819ac7d1d981695da3eae1bd60de1cb53ae
Reviewed-on: https://gerrit.openafs.org/15233
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Commit 8632f23d6718a3cd621791e82d1cf6ead8690978 introduced checks for
the return value of snprintf calls in namei_ops. On success, the value
returned by this function represents the number of written characters.
Unfortunately, the variable used to store this value is the same
variable that represents the status code returned by
namei_ConvertROtoRWvolume. Consequently, a successful execution of
namei_ConvertROtoRWvolume results in a status code different the 0 (and
equal to the number of written characters).
To fix this problem, set the status code in question back to 0 after a
successful execution of namei_ConvertROtoRWvolume.
Reviewed-on: https://gerrit.openafs.org/14065
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 957b06984b77cba74bd90217b723220c1844809b)
Change-Id: If82cf4d2983e7b6f8975ca4a9fa104ee5e36b917
Reviewed-on: https://gerrit.openafs.org/15232
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The Linux kernel build has -Wstrict-prototypes enabled and flags
functions without a proper prototype. With clang-16 these warnings are
reported as errors when the kernel is configured with CONFIG_WERROR or
when openafs is configured with --enable-checking.
src/libafs/MODLOAD-6.1.0-rc3-SP/osi_alloc.c:339:32: error: a
function declaration without a prototype is deprecated in all
versions of C [-Werror,-Wstrict-prototypes]
osi_linux_verify_alloced_memory()
^
void
Update function prototypes to comply with -Wstrict-prototypes.
There are no functional changes with this commit.
Reviewed-on: https://gerrit.openafs.org/15194
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 63db2de22ef75292463ec1f0979e32afc05d0b95)
Change-Id: I2e9c09c3b88ca3597720b1d8885537600d307418
Reviewed-on: https://gerrit.openafs.org/15275
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang-16 is flagging a incompatible-function-pointer-types warning which
results in build errors when --enable-warning is turned on.
client.c:498:13: error: incompatible function pointer types passing
'int (struct rx_connection *, afs_int32 *)'
(aka 'int (struct rx_connection *, int *)') to parameter of type
'int (*)(struct rx_connection *, afs_RPCStatsState_p)'
(aka 'int (*)(struct rx_connection *, afs_RPCStatsState_t *)')
[-Wincompatible-function-pointer-types]
(conn, RXSTATS_QueryPeerRPCStats, &state, &st)) {
^~~~~~~~~~~~~~~~~~~~~~~~~
Update the 'util_RPCStatsStateGet()' function's parameter to match the
function type for the RPC functions actually being called.
Reviewed-on: https://gerrit.openafs.org/15180
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 97f0a20e50f027fe00adb22c39b71f0ac79f1ff7)
Change-Id: Icbbbd137fa6a404090ef7af94621100bb552d502
Reviewed-on: https://gerrit.openafs.org/15274
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Clang-16 is flagging variables as unused-but-set-variables resulting in
build errors when --enable-warning is used.
db_verify.c:996:9: error: variable 'builtinUsers' set but not used
[-Werror,-Wunused-but-set-variable]
int builtinUsers = 0;
^
Remove the variables that are set but never actually used.
This commit fixes the simpler cases where variables are only set but
not used elsewhere.
Reviewed-on: https://gerrit.openafs.org/15178
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit afafde158ff875d2459bb81ac373cde3e45dac03)
Change-Id: I65cd27325b768ba192831401f4ac71e94071ecc7
Reviewed-on: https://gerrit.openafs.org/15273
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang-16 is flagging unused-but-set variables which result in build
errors when --enable-warning is turned on.
remote.c:485:15: error: variable 'pass' set but not used
[-Werror,-Wunused-but-set-variable]
afs_int32 pass;
^
These variables are actually used in specific cases depending on
build configuration (e.g. AFS_PTHREAD_ENV, etc.).
Relocate these variables so they are fully defined or referenced within
preprocessor '#if' blocks.
Reviewed-on: https://gerrit.openafs.org/15177
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 97018ace991d300a6ff75a1dcd1a69b4044f2b89)
Change-Id: Iee3a196d9c23a8725171db4a3a884a077f0e95ac
Reviewed-on: https://gerrit.openafs.org/15277
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang-16 is flagging unused-but-set variables which result in build
errors when --enable-warning is turned on. Several of these variables
are used within 'for(..)' loops but are not actually referenced anywhere
else.
fcrypt.c:181:16: error: variable 'i' set but not used
[-Werror,-Wunused-but-set-variable]
afs_uint32 i, j;
^
Refactor the for statements to eliminate the unused variables.
Note, this commit is a little more complex than simply removing unused
variables.
Reviewed-on: https://gerrit.openafs.org/15176
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 05eb420829f9bca155c1d5af9fe96844db974770)
Change-Id: I80506cb8ae1c4bef67225eb11e3f640e8de52d26
Reviewed-on: https://gerrit.openafs.org/15271
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
When building with clang-16 and configured with --enable-checking, the
external source heimdal/krb5/crypto.c used in src/crypto/rfc3961 fails
with the following error:
src/external/heimdal/krb5/crypto.c:702:28
error: implicit conversion from enumeration type 'krb5_enctype' (aka
'enum ENCTYPE') to different enumeration type 'krb5_keytype' (aka
'enum krb5_keytype') [-Werror,-Wenum-conversion]
*keytype = e->keytype->type; /* XXX */
~ ~~~~~~~~~~~~^~~~
Replace the enum definition of krb5_keytype with a typedef to
krb5_enctype and create an anonymous enum mapping of KEYTYPE_ARCFOUR to
ETYPE_ARCFOUR_HMAC_MD5.
It should be noted that krb5_keytype and KEYTYPE_ARCFOUR are only used
by the external file src/external/heimdal/krb5/crypto.c
Changing the type for krb5_keytype was suggested by Andrew Deason
(adeason@sinenomine.net).
Reviewed-on: https://gerrit.openafs.org/15189
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c9ac7cdfb6365e3fc1914de80019a10328de1f4f)
Change-Id: I15a793b35cfa920e8db1a99c5575b4f3f55be0dd
Reviewed-on: https://gerrit.openafs.org/15270
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang-16 is flagging unused-but-set variables which result in build
errors when --enable-warning is turned on.
./dumptool.c:1285:54: error: variable 'sflag' set but not used
[-Werror,-Wunused-but-set-variable]
int errflg = 0, lflag = 0, iflag = 0, Fflag = 0, sflag = 0, Rflag = 0;
Within dumptool the '-s' option of the 'ls' subcommand sets the 'sflag'
variable, but the variable itself is never used anywhere else.
Remove the variable 'sflag', and ignore the '-s' option.
The sflag variable was unused in the commit that introduced the code:
"test-suite-pull-tools-directly-in-20020114" (fcb32c07ed6d)
Reviewed-on: https://gerrit.openafs.org/15181
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3e9d41c98ecf07519ff6d2a1413615547ace13b8)
Change-Id: I4cd4584c6374a525714d392f98fb39be5406bdbc
Reviewed-on: https://gerrit.openafs.org/15269
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
clang-16 is flagging an implicit-function-definition which results in a
build error when --enable-warning is turned on.
PERLUAFS/ukernel_swig_perl.c:1585:9: error: call to undeclared
function 'afs_com_err'; ISO C99 and later do not support
implicit function declarations [-Wimplicit-function-declaration]
afs_com_err("AFS::ukernel", code, "parsing line: '%s'", line);
^
Add an include for afs/com_err.h to resolve the warning.
Reviewed-on: https://gerrit.openafs.org/15179
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4be3e5d31fa3fbe6c80ad0973430074124b157bc)
Change-Id: I62785fe6248cb4b26f680c2db044f59511a1e02e
Reviewed-on: https://gerrit.openafs.org/15268
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Harish Sharma <Harish.Sharma1@ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
The event_handler() function contains several counters that are
set and incremented but are not actually used. Clang-16 is flagging
these with a 'unused-but-set-variable' warning resulting in build errors
when --enable-warnings is used.
rx_pthread.c:136:19: error: variable 'rx_pthread_n_event_expired' set
but not used [-Werror,-Wunused-but-set-variable]
unsigned long rx_pthread_n_event_expired = 0;
Several 'if' statements are used to conditionally set these variables,
but serve no other purpose. These 'if' statements can also be
eliminated.
Remove the unused rx_pthread_* counter variables as well as the
associated 'if' statements. In addition the only purpose of the
'error' variable was to conditionally increment one of the removed
variables, remove the 'error' variable.
These variables have been 'unused but set' since the original commit
from IBM.
Reviewed-on: https://gerrit.openafs.org/15175
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit f7cb492c7e755ec91226c96cc82ad9f567f01f11)
Change-Id: I4dfdd7e536f6af642789fc51f6f055652c63a46d
Reviewed-on: https://gerrit.openafs.org/15267
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
