The following budb RPCs do not initialize their output correctly.
This leaks buserver memory contents over the wire:
BUDB_FindLatestDump (backup dump)
BUDB_FindDump (backup volrestore, diskrestore, volsetrestore)
BUDB_GetDumps (backup dumpinfo)
BUDB_FindLastTape (backup dump)
struct budb_dumpEntry
- up to 32 bytes in member volumeSetName
- up to 256 bytes in member dumpPath
- up to 32 bytes in member name
- up to 32 bytes in member tape.tapeServer
- up to 32 bytes in member tape.format
- up to 256 bytes in member dumper.name
- up to 128 bytes in member dumper.instance
- up to 256 bytes in member dumper.cell
Initialize the buffer in common routine FillDumpEntry.
Change-Id: Ic057a6c906ce2acd39e0e4ea0a0ba1e100bba3e9
RXAFSCB_TellMeAboutYourself does not completely initialize its output
buffers. This leaks kernel memory over the wire:
struct interfaceAddr
Unix cache manager (libafs)
- up to 124 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 * 4) - 4))
- up to 124 bytes in array subnetmask "
- up to 124 bytes in array mtu "
Windows cache manager
- 64 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 - CM_MAXINTERFACE_ADDR 16)* 4)
- 64 bytes in array subnetmask "
- 64 bytes in array mtu "
The following implementations of SRXAFSCB_TellMeAboutYourself are not susceptible:
- fsprobe
- libafscp
- xstat_fs_test
Initialize the buffer.
Change-Id: I2ef868dd9269db7004a21cf913b6787948357d10
RXAFSCB_GetLock (cmdebug) does not correctly initialize its output.
This leaks kernel memory over the wire:
struct AFSDBLock
- up to 14 bytes for member name (16 - '<cellname>\0')
Initialize the buffer.
Change-Id: I4c5c8d67816c51645c0db44dc8f19b1b27c02757
PR_ListEntries (pts listentries) does not properly initialize its output
buffers. This leaks ptserver memory over the wire:
struct prlistentries
- up to 62 bytes for each entry name (PR_MAXNAMELEN 64 - 'a\0')
Initialize the buffer, and remove the now redundant memset for the
reserved fields.
Change-Id: I29d70c7e4dd567b8b046037f29f71911b8a0593f
AFSVolMonitor (vos status) does not properly initialize its output
buffers. This leaks information from volserver memory:
struct transDebugInfo
- up to 29 bytes in member lastProcName (30-'\0')
- 16 bytes in members readNext, tranmitNext, lastSendTime,
lastReceiveTime
Initialize the buffers. This must be done on a per-buffer basis inside
the loop, since realloc is used to expand the storage if needed,
and there is not a standard realloc API to zero the newly allocated storage.
[kaduk@mit.edu: update commit message]
Change-Id: I79091fc63435ed2a795955f95bb867bc625ad398
AFSVolPartitionInfo and AFSVolPartitionInfo64 (vos partinfo) do not
properly initialize their reply buffers. This leaks the contents of
volserver memory over the wire:
AFSVolPartitionInfo (struct diskPartition)
- up to 24 bytes in member name (32-'/vicepa\0'))
- up to 12 bytes in member devName (32-'/vicepa/Lock/vicepa\0'))
AFSVolPartitionInfo64 (struct diskPartition64)
- up to 248 bytes in member name (256-'/vicepa\0'))
- up to 236 bytes in member devName (256-'/vicepa/Lock/vicepa\0')
Initialize the output buffers.
[kaduk@mit.edu: move memset to top-level function scope of RPC handlers]
Change-Id: If64c02f36f10f52bfbab4b21ad1f60032c223c82
SPR_IDToName does not completely initialize the return array of names,
and thus leaks information from ptserver memory:
- up to 62 bytes per requested id (PR_MAXNAMELEN 64 - 'a\0')
Use calloc to ensure that all memory sent on the wire is initialized,
preventing the information leak.
[kaduk@mit.edu: switch to calloc; update commit message]
Change-Id: Iad623f2cc4c54b79f14a64b8714ba12579d05447
Add an --enable-rxgk switch to control whether the feature is used.
For the sake of buildbot coverage, we still attempt to build the core
subdirectory provided that a sufficiently usable GSS-API library
is available, but do not install anything when rxgk is disabled at
configure time. Future commits will use the configure argument to
control the behavior of other rxgk-aware code in the tree.
We provide a few new symbols to conditionally compile code for rxgk.
The two new high-level symbols are:
- AFS_RXGK_ENV: when defined, rxgk is available
- AFS_RXGK_GSS_ENV: when defined, we can use GSS-API calls
AFS_RXGK_GSS_ENV is turned on only for userspace pthread builds. For
now, AFS_RXGK_ENV is only turned on for userspace pthread builds, and
non-ukernel kernel builds. This effectively disables rxgk integration
in any ukernel or LWP code, but this can be changed in the future by
changing when AFS_RXGK_ENV is defined.
Change-Id: Iab661d47aac77c1a238e809362015b869752df18
Reviewed-on: https://gerrit.openafs.org/10564
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Use the AFS_UNREACHED macro to suppress statement not reached warnings while
building under Solaris Studio. These warnings are emitted for statements
following functions declared with the noreturn function attribute.
Change-Id: Ic18cbb3ea78124acbe69edc0eccb2473b46648fe
Reviewed-on: https://gerrit.openafs.org/13010
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Add missing lwp function prototypes for Solaris. This fixes the compile time
warning messages:
warning: implicit function declaration: LWP_NoYieldSignal
Change-Id: I69c3660bb2631215cd296c08729c8e84d60660fd
Reviewed-on: https://gerrit.openafs.org/13008
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The Solaris implementation of the rx_atomic functions generate numerous
complile time warnings due to an integer type mismatch.
"rx_atomic.h", line xxx: warning: argument #1 is incompatible with prototype:
The rx_atomic_t is an unsigned int under Solaris, however the Solaris
atomic_set_long_excl and atomic_clear_long_excl functions take a ulong_t type
Solaris does not provide 'unsigned int' variants of these two functions.
Fortunately, ulong_t variants of all the atomic we need for rx are available,
in current as well as older versions of Solaris, so convert the Solaris
rx_atomic_t type to be a ulong_t and convert all of the Solaris atomic calls to
the ulong_t variants to avoid integer type mismatches.
Change-Id: Ib54ca4bb8b9f044684301f0fb7971aec223e5993
Reviewed-on: https://gerrit.openafs.org/12991
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Declare the nfs translator dispatch functions to be static to enforce
they are not to be called from outside of the translator.
Change-Id: I1c3d8917c080409424e21e377405472094941da0
Reviewed-on: https://gerrit.openafs.org/13277
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Replace the use of char * and char ** with void * for representing
generic pointers in the nfs dispatcher functions. This was done to fix
a large number of compile time warnings, and allows us to remove a
number of explicit casts.
Also, remove the unnecessary char * casts of memset and memcpy arguments in the
nfs translator dispatcher.
This commit fixes a large number of Solaris Studio warning messages in the
form:
... warning: argument #X is incompatible with prototype:
Change-Id: I42e2d40b8112ada9417724282c0230f48a40324f
Reviewed-on: https://gerrit.openafs.org/12989
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>
The fourth argument of the afs_nfs{2,3}_dispatcher functions is a pointer to a
pointer to a exportinfo structure. However, this argument is not an output
argument, so the extra level of indirection is unnecessary. A separate local
variable is used as an output argument to the afs_nfsclient_reqhandler call
within the dispatchers, which is not passed back to the afs_nfs{2,3}_dispatcher
caller.
In anticipation of other changes to fix warning messages, simplify the
signature of the afs_nfs{2,3}_dispatcher functions to avoid taking the address
of the exportinfo structure when calling afs_nfs{2,3}_dispatcher.
Change-Id: I6fb1a190e6aab286bfac41df783688a0be46a21f
Reviewed-on: https://gerrit.openafs.org/12988
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>
Fix a missing early return value in the function afs_nfs3_dispatcher. All
callers check the return code of afs_nfs3_dispatcher and interpret values
greater that 1 to be errors. Return 3 as an error code for this code path,
which is the next available error code in afs_nfs3_dispatcher.
This commit fixes the following Solaris Studio warning message:
... warning: function expects to return value: afs_nfs3_dispatcher
Change-Id: I47b545bd57a46c03006b9f031da3647c8a530377
Reviewed-on: https://gerrit.openafs.org/12987
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
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.
Change-Id: Iea5622ae175e7f82a60780838948178bd7f8b56f
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>
Move our krb5 and GSS-related autoconf tests into their own separate
files, in src/cf/krb5.m4 and src/cf/gss.m4.
Change-Id: I4202df5d810f2d3942fc4ffb3fd406869f68029b
Reviewed-on: https://gerrit.openafs.org/13237
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, OpenAFS does not use automake. As a result, the missing script
is not copied to the build-tools directory. Since this script is not
present in the tree, am_missing_run is not initialized. Unfortunately,
the current version still has a few references to this variable. In order
to preserve a similar behavior, this commit replaces these references by
AC_ERROR.
While we are changing these, remove the AC_CHECK_PROGS calls for AR and
STRIP, since libtool already checks these for us.
Change-Id: I833dc6e8611dc7227db4ec77b0160dfa47b7e531
Reviewed-on: https://gerrit.openafs.org/12982
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The autoupdate tool was run to modernize the autoconf macros but
generates very long lines. Manually reformat the long lines to make them
more reasonable.
Change-Id: I6f08138aa7134d8110da885ea4375cebbe903575
Reviewed-on: https://gerrit.openafs.org/13125
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Run autoupdate on macros.
[mmeffie@sinenomine.net: re-run autoupdate, no other edits]
Change-Id: I8b45edea97cf2e065f23f02d2d7f6a0e7adcb8a5
Reviewed-on: https://gerrit.openafs.org/12202
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Replace the obsolete AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM
in the curses check for the getmaxyx macro.
This change was done manually instead of using autoupdate because the
program prologue argument for this particular check is an m4 macro,
which will not expand to code when autoupdate adds m4 quotes to the
AC_LANG_PROGRAM arguments.
Change-Id: I85b65fb9b59b45d31286436a9f15110cec31bec8
Reviewed-on: https://gerrit.openafs.org/13021
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Replace obsolete AC_TRY_COMPILE with AC_COMPILE_IFELSE. Replace shell
if/then conditionals with AS_IF macros. Reformat indentation and
quoting.
This change was done manually, since autoupdate copes poorly with the
old, nested AC_TRY_COMPILE macros.
Change-Id: I2c34d1426f154daff65999076821f49ddaa16a24
Reviewed-on: https://gerrit.openafs.org/13018
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Update autoconf macros to their modern equivalents, according to what
the 'autoupdate' tool does. While we're here, remove automake references
that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor
of AFS_LT_INIT.
Change-Id: I71066d6d72f8b1d8663e26fec83ae23d7f73f059
Reviewed-on: https://gerrit.openafs.org/12199
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The -m64 flag to specify 64bit builds was introduced in Sun Studio 10, circa
2005. The old flag -xarch=amd64 was deprecated as of Sun Studio 12, circa 2007.
Ever since Sun Studio 12, the compiler complains with a warning message when
the old -xarch=amd64 flag is given:
cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit programs
Update the cflags when building the Solaris kernel module for x86 to use the
modern -m64 under Solaris 11 or later. Since Solaris 11 has been available
since 2010, it is very unlikely a compiler on Solaris 11 would not support the
modern -m64 flag.
Change-Id: Ib13c00f1c69f34ab1905a8dd4a46c90895046f25
Reviewed-on: https://gerrit.openafs.org/12959
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When afsd is started with the -debug flag, extensive debug output is
generated including tracing for each syscall. Unfortunately the
existing syscall tracing is not especially helpful. It dumps out two
constants that we already knew at compile time, the first parameter of
the syscall along with the syscall's return code. Specifically it does
not tell you which syscall is currently being traced. Here's a current
example of afsd -debug:
afsd: cacheFiles autotuned to 581250
afsd: dCacheSize autotuned to 10000
afsd: cacheStatEntries autotuned to 15000
SScall(183, 28, 6860800)=0
SScall(183, 28, -847416368)=0
SScall(183, 28, 1)=0
afsd: Forking rx listener daemon.
afsd: Forking rx callback listener.
afsd: Forking rxevent daemon.
SScall(183, 28, 0)=0
SScall(183, 28, 1)=0
...
This patch drops the compile time constants (183 and 28 in the above
sample output) and replaces them with the name of the syscall being
traced. Additionally the first parameter to a syscall is as likely to
be an address as a decimal value so display it in hex. Here's an example
of afsd -debug with these changes:
afsd: cacheFiles autotuned to 581250
afsd: dCacheSize autotuned to 10000
afsd: cacheStatEntries autotuned to 15000
os_syscall(AFSOP_SET_THISCELL, 0x68bf80)=0
os_syscall(AFSOP_SEED_ENTROPY, 0x7fff9ce40c10)=0
os_syscall(AFSOP_ADVISEADDR, 0x1)=0
afsd: Forking rx listener daemon.
afsd: Forking rx callback listener.
afsd: Forking rxevent daemon.
os_syscall(AFSOP_RXEVENT_DAEMON, 0x0)=0
os_syscall(AFSOP_BASIC_INIT, 0x1)=0
...
[mmeffie@sinenomine.net: avoid c99 array initialization.]
Change-Id: I4f3d46d420d19abeddbf719efa04aef7e553d51f
Reviewed-on: https://gerrit.openafs.org/11858
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Check for function attributes by type and update src/afs/stds.h to
conditionally include the attributes detected, instead of checking for
specific compilers and compiler versions.
This allows attributes to be used when building under Solaris Studio.
Change-Id: I8a4dbc1b2cb6032d28176349481085bf6deb309c
Reviewed-on: https://gerrit.openafs.org/12963
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 71dc077831d339fc5822f2c2c79b65afe14b12f8 changed the AFS_NONULL
macro in opr.h to fix a build error on windows by adding an empty
argument index list.
However, Solaris compilers do not support empty parameter lists.
Specify the argument index to allow so nonnull function attributes can
be supported on Solaris.
Change-Id: I3e629868374eb6484923c253da2cdd1d8eacdb2f
Reviewed-on: https://gerrit.openafs.org/13276
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Building with Solaris Studio generates a ludicrous number of warnings
in the form:
roken.h, line ...: warning: attribute "format" is unknown, ignored
Modern Solaris Studio supports several GCC-style function attributes,
including the `noreturn' attribute, however does not support the
`format' attribute.
Currently, configure defines HAVE___ATTRIBUTE__ when the `noreturn'
attribute is available. roken headers conditionally declare printf-like
functions with the `format' function attribute when HAVE___ATTRIBUTE__
is defined, leading to the warning messages when building under Solaris
Studio. Unsupported function attributes generate warnings, not errors.
Fix these warnings by defining HAVE___ATTRIBUTE__ if and only if the
`format' attribute is supported by the compiler, instead of checking for
`noreturn'. Note that the `format' type is currently the only attribute
used by roken at this time.
Change-Id: I569167333d65df2583befc19befa8d719b93d75a
Reviewed-on: https://gerrit.openafs.org/12956
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Import Gabriele Svelto's AC_GCC_FUNC_ATTRIBUTE autoconf macro to check for
GCC-style function attributes. This macro is part of the GNU Autoconf
Archive[1]. The imported file is distributed under an all-permissive license.
[1] https://www.gnu.org/software/autoconf-archive/
Change-Id: I64ccd00717fa9606a26aeeeea9030f4fb4877cf8
Reviewed-on: https://gerrit.openafs.org/12962
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
During cache initialization, we can fail to allocate our dcache
entries for memcache. Currently when this happens, we just log a
message and try to disable dcache access. However, this results in at
least one code path that causes a panic anyway during startup, since
afs_CacheTruncateDaemon will try to trim the cache, and afs_GetDownD
will call afs_MemGetDSlot, and we cannot find the given dslot.
To avoid this, change our cache initialization to return an error,
instead of trying to continue without a functional dcache. This causes
afs_dcacheInit to return an error in this case, and by extension
afs_CacheInit and the AFSOP_CACHEINIT syscall. Also change afsd to
actually detect errors from AFSOP_CACHEINIT, and to bail out when it
does.
Thanks to gsgatlin@ncsu.edu for reporting the relevant panic.
Change-Id: Ic89ff9638201faae6c4399a2344d4da3e251d537
Reviewed-on: https://gerrit.openafs.org/13273
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
With 4.18+ Linux kernels we see a transition to 64-bit time stamps by
default.
current_kernel_time() returns the 32-bit struct timespec.
current_kernel_time64() returns the 64-bit struct timespec64.
struct iattr->ia_ctime expects struct timespec64 as of 4.18+.
Timestamps greater than 31-bit rollover after 2147483647 or
January 19, 2038 03:14:07 UTC. This is the same approach taken by
the Linux developers for converting between timepsec64 and timespec.
Change-Id: Icc1cf5d1a6679f5c749f8720f225a9b293f675fd
Reviewed-on: https://gerrit.openafs.org/13241
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Currently, in the libuafs MakefileProto for every platform, CFLAGS is
set to a bunch of flags, ignoring any CFLAGS set by the 'make'
command-line provided by the user. Since most of the rest of the tree
honors CFLAGS, it is confusing and can cause errors when src/libuafs
ignore the user-set CFLAGS.
One example of this breaking the build is when building RHEL RPMs for
certain sub-architectures of the current machine. If you try to
'rpmbuild --target=i686' on 32-bit x86 RHEL 5, we will build with
-march=i686 in the CFLAGS, which will be used to build most objects
and is used in our configure tests. As a result, our configure tests
will say that gcc atomic intrinsics are available. But when we go to
build libuafs objects, we will not have -march=i686 in our CFLAGS,
which causes (on RHEL 5) gcc to default to building for i386, which
does not have gcc atomic intrinsics available. This causes build
errors like this:
libuafs.a(rx.o): In function `rx_atomic_test_and_clear_bit':
[...]/BUILD/openafs-1.8.0/src/rx/rx_atomic.h:462: undefined reference to `__sync_fetch_and_and_4'
To fix this, change the libuafs MakefileProtos to not set CFLAGS
directly; instead, set them in a new variable UAFS_CFLAGS.
Makefile.common then pulls those flags into MODULE_CFLAGS, which is
used in our *_CCRULE build rules.
While we are here, also move the common set of CFLAGS set by each
platform's MakefileProto into Makefile.common. Now, each MakefileProto
only needs to set CFLAGS that are specific to that platform, which
ends up being very few (since most platforms were using the exact same
set of CFLAGS).
Relevant issue identified and analyzed by mbarbosa@sinenomine.net.
Change-Id: I1bd21a6e7669137be3e5edee86227fd37f841d62
Reviewed-on: https://gerrit.openafs.org/13262
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit 278581c24a802834719e0d57f27978321556c9bb (redhat: package libuafs
perl bindings) added swig as a build dependency on RHEL 6+/Fedora 15+ to
build and package AFS::ukernel perl bindings for libuafs. The man page
for AFS::ukernel is generated from the pod files unconditionally, so
needs to be removed from the staging directories when AFS::ukernel is
not packaged.
Unfortunately, the full path to the staged AFS::ukernel manpage was
not given in that commit, so the rpmbuild will fail on RHEL 5 with
the error:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/man/man3/AFS::ukernel.3.gz
Fix this error by specifying the full path to the AFS::ukernel man page
to actually remove it when we are not packaging AFS::ukernel files.
[mmeffie: updated commit message]
Change-Id: If43f083a1014216e2f9a2669bf9e834149a40944
Reviewed-on: https://gerrit.openafs.org/13257
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The value of errno can change after a syscall, and ViceLog may issue
syscalls (such as write()). So, make sure we save errno here before
calling ViceLog().
Issue spotted by kaduk@mit.edu.
Change-Id: I0f3308d64cd779bd97c97834ec2b270f5edd7ba6
Reviewed-on: https://gerrit.openafs.org/13263
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
As an aid for debugging database synchronization issues, ensure that the
logging is consistent and unambiguous for both the client and server
sides of DISK_GetFile and DISK_SendFile. Add new error messages as
required.
In addition, rework the "recovery sending version to <IP>" message in
urecovery_Interact. This message is misleading because the new version
database is only sent to a DB server if its version is not up to date.
Instead, move this message into the version check block immediately
below it. Also reword it for clarity and promote its log level from 5
to 0. Finally, remove the now-superfluous "recovery stating local
database" log message.
Change-Id: If8bbaa1215cab9fd24b157a0ee57759b34e77e9c
Reviewed-on: https://gerrit.openafs.org/13079
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
As a troubleshooting aid for developers, add a few counters and a log
msg so we know when transactions are being aborted (if any) by
urecovery_AbortAll.
Change-Id: I528df6d51acd5d10bb2de30f43b8d4415adc7f8a
Reviewed-on: https://gerrit.openafs.org/12618
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Many important ubik messages (e.g., errors, warnings, sync state
changes) are logged at log level 5 (-d 5) or higher. Many sites are
reluctant to run ubik servers at a logging level higher than the default
due to the large number of extremely noisy informational messages at log
level 5. Therefore, many important log messages are never seen.
Instead, issue critical errors, warnings, and other important messages
at log level 0 so that they are always seen, even at the default logging
level.
In addition, disambiguate the two "I am no longer sync-site" messages by
adding a unique reason text to each.
Change-Id: I057edf01e2502e39c5135836f1d0081d03559270
Reviewed-on: https://gerrit.openafs.org/12617
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit 6b93ad695e53a86dbe9eea13bd0ff651e1d8c9b7 fixed a false error
reported when the vldb contained more than one mh extent blocks. That
fix changed the readMH() function to convert the flags field to host
byte order of all the mh blocks, not just the first block, in order to
check the value of those flags.
Unfortunately, that commit missed converting non-zero blocks back to
network byte order in the complementary writeMH() function, which is
used to write the data back to disk when vldb_check is run with the -fix
option.
FIXES 134589
Change-Id: I4cdbd57b3336e78a9eb1e543ee6d09b33f5e6153
Reviewed-on: https://gerrit.openafs.org/13245
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In userspace, we assume that free(NULL) does nothing, which makes
certain cleanup code paths simpler. This may or may not be true for
our free() abstractions that can run in the kernel (like afs_osi_Free,
rxi_Free, etc), which is confusing. To make the higher-level free()
abstractions more consistent, change afs_osi_Free to guarantee that
passing a NULL pointer does nothing.
Change-Id: If7c7011795f66464eeb578eacfc943475b4d59f8
Reviewed-on: https://gerrit.openafs.org/13236
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Parallel builds can be an order of magnitude faster. Add the
_smp_mflags macro to all invocations of make in the rpm spec,
to make use of all available cores and SMT threads on the build
system. This should also help noticing new dependency issues
early. Note the macro can be overridden on the rpmbuild command
line.
Change-Id: Idddf8b867500d1ee73ff51de9d8a173bb4cc8c68
Reviewed-on: https://gerrit.openafs.org/13240
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
When building with --define "build_modules 0", have configure
skip the Linux kernel tests, which are slow and many.
Change-Id: Ie318bf4939776c9a3f8594dcdd5be54b446f33dd
Reviewed-on: https://gerrit.openafs.org/13239
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Commit 792dd44ac57032a3f2a4743c83c8a0208a08ecec added the
installation of include/opr/lock.h, but the rpm spec fails
to pick it up, making rpm builds fail. Add the new file
to the files list for the -devel package.
FIXES 134579
Change-Id: I998f48bd88308d81779dd775b322590eda75d5c8
Reviewed-on: https://gerrit.openafs.org/13238
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In afs_linux_write_begin, we call grab_cache_page_write_begin to get a
page to use for writing data when servicing a write into AFS. Under
low-memory conditions, this can return NULL if Linux cannot find a
free page to use. Currently, we always try to reference the page
returned, and so this causes a BUG.
To avoid this, check if grab_cache_page_write_begin returns NULL, and
just return -ENOMEM, like other callers of grab_cache_page_write_begin
do.
Linux's fault injection framework is useful for testing code paths
like these. The following settings made it possible to
somewhat-reliably exercise the relevant code path on a test RHEL7
system:
# grep ^ /sys/kernel/debug/fail_page_alloc/*
/sys/kernel/debug/fail_page_alloc/ignore-gfp-highmem:Y
/sys/kernel/debug/fail_page_alloc/ignore-gfp-wait:N
/sys/kernel/debug/fail_page_alloc/interval:1
/sys/kernel/debug/fail_page_alloc/min-order:0
/sys/kernel/debug/fail_page_alloc/probability:100
/sys/kernel/debug/fail_page_alloc/space:90
/sys/kernel/debug/fail_page_alloc/task-filter:Y
/sys/kernel/debug/fail_page_alloc/times:-1
[...]
Change-Id: I00908658ae43aa3c8e12f2a0b956016d4441016c
Reviewed-on: https://gerrit.openafs.org/13242
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
rxi_ChallengeEvent is called directly from rxi_ChallengeOn to start the
first challenge; subsequent calls to rxi_ChallengeEvent are from the
event handler. When called as an event, we must putConnection the
reference held by the event. But when called directly for the first
time, the event has not been scheduled yet and so has not taken a
reference on the connection. For this case, we must not putConnection
or the rx_connection refCount will go negative.
One reported symptom of this bug is a fileserver crash with:
'Assertion failed! file rx.c, line 1327.'
Introduced by commit 304d758983b499dc568d6ca57b6e92df24b69de8
('Standardize rx_event usage').
Change-Id: I67122ff84ac9b1b6445ad4005e76e5f8482fd7be
Reviewed-on: https://gerrit.openafs.org/13228
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When moving, copying or releasing volumes, do not treat a failure
to delete a volume because the volume no longer exists as an error.
The volume clone has flags
VTDeleteOnSalvage | VTOutOfService
assigned to it which means that the fileserver won't attach the volume
and volume has its deleteMe field assigned the value of DESTROY_ME.
Such a volume will be deleted the next time the salvager scans the
partition. Once the transaction is complete the volume might be
removed.
Change-Id: I0bd38906e3836e0c96f3784a8bd9ad63f5b857c6
Reviewed-on: https://gerrit.openafs.org/12976
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, afs_AllocDCache can fail in 2 different situations:
- When we are out of dslots on the free/discard lists
- When we encounter an i/o error when trying to traverse the dslot
lists
But afs_AllocDCache cannot distinguish between these two cases to its
caller in any way, since all we have to return is a struct dcache (and
so we return NULL on any error).
Currently, the caller of afs_AllocDCache in afs_GetDCache is
determining which of these cases happened by looking at
afs_discardDCList and afs_freeDCList, to see if they look empty. This
is not great for at least a couple of reasons:
- We are examining afs_discardDCList/afs_freeDCList after we drop
afs_xdcache (but while still holding GLOCK)
- If afs_discardDCList/afs_freeDCList are somehow changed while
afs_AllocDCache is running, we may infer the wrong reason why
afs_AllocDCache failed. (currently impossible, but this seems
fragile)
And in general, this check against afs_discardDCList/afs_freeDCList is
rather indirect. It may be easier to follow if afs_AllocDCache just
directly returned the reason why it failed.
So do that, by changing afs_AllocDCache to return an error code, and
providing the struct dcache in an output argument. This involves
similiarly changing several called functions in the same way, to
return error codes. We only define 2 such error codes with this
commit:
- ENOSPC, when we are out of free/discrad dslots
- EIO, when we encounter a disk i/o error when trying to examine the
dslot list
Note that this commit should not change any real logic; we're mostly
just changing how errors are returned from these various functions.
Change-Id: I07cc3d7befdcc98360889f4a2ba01fdc9de50848
Reviewed-on: https://gerrit.openafs.org/13227
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Nothing using afs_AllocDCache outside of afs_dcache.c. Declare the
function static, to ensure that nobody else uses it, and to maybe
allow for more compiler optimization.
Change-Id: I4e4d1e77e20e853fc20b3d5c5289a5f4124de7a4
Reviewed-on: https://gerrit.openafs.org/13226
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In order to better manage voting and recovery, each ubik server tracks
(in array ubik_servers) which of its fellow quorum members are 'up' or
not. However, ubik currently logs only when a server is "back up"; that
is, ubik_server->up transitions from 0 to 1.
Add new log messages to identify the time and reason when a server is
"marked down" (i.e., ubik_server->up transitions from 1 to 0).
Also modify two existing messages to have consistent wording with the
new "marked down" messages. Also change them to ViceLog (log level
0) so they will always be logged.
Change-Id: I29ee93e96cb7b28b943171d1477671c540a10d78
Reviewed-on: https://gerrit.openafs.org/12616
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
afs_CheckLocks has been dead code since openafs-ibm-1_0.
No functional change incurred.
Change-Id: I9d57cf3bbbddef182fb128f65b04465bfe0fb492
Reviewed-on: https://gerrit.openafs.org/13210
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
