The SRCDIR_PARENT shell variable is set to the configure process current
working directory. It is used during configure to set the top level
directory variables used in the build; TOP_OBJDIR, TOP_INCDIR,
TOP_LIBDIR. It is also used during configure to specify the path to
generated programs.
However, this variable is redundant with the TOP_OBJDIR variable and the
name can be confusing, since the top build directory is not the source
parent directory when doing out-of-tree (objdir) builds.
Remove the SRCDIR_PARENT variable and set the top directory variables
early in configure. Use TOP_OBJDIR to indicate the path to generated
tools.
Change-Id: Iaf1ce7707e73dd3c8fdf849c9767e8b84401d5a7
Reviewed-on: https://gerrit.openafs.org/15816
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, vol_listLock and vol_sleep_cond have been defined and
initialized, but never used; remove them.
No functional change is incurred by this commit.
Change-Id: Id0e735de5495120035d7a77fd08ee16d33dae8ba
Reviewed-on: https://gerrit.openafs.org/15140
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, h_CheckHosts has zeroed 'zerofid'
but it is not referenced by any other code.
Remove the vestigial code.
No functional change is incurred by this commit.
Change-Id: I56ff2977bd210f2a37abf0b25f5e3aba2da19d85
Reviewed-on: https://gerrit.openafs.org/15101
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
When running afsd with the -memcache option, afsd_run will skip certain
AFSOP_* syscalls that are not needed for a memory cache, e.g.
AFSOP_CACHEINFO and AFSOP_VOLUMINFO. However, afsd -debug output still
misleadingly mentions these syscalls, as if they were about to be
invoked.
For AFSOP_CACHEINFO, this has been true since the original IBM code
import. For AFS_VOLUMEINFO, this was introduced with commit
1307b89188 memcache-no-volitems-20050113.
In order to avoid misleading debug output when running -memcache, move
the afsd_debug() calls under their respective AFSCALL_INIT_MEMCACHE
conditional clauses.
Change-Id: Id13b5fc7c39ccc0836204ecf213f0fe68f666889
Reviewed-on: https://gerrit.openafs.org/15566
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The DEST variable depends on the sysname, so move the assignment of the
DEST variable to the end of the OPENAFS_SYSNAME macro which is where the
sysname value is determined.
Also fix the test for an empty DEST variable, which put the dummy 'x'
after the variable, not before, to guard against values that start with
a dash.
Change-Id: Iaf8deefc685a6c9b9897d83b25b8919792847796
Reviewed-on: https://gerrit.openafs.org/15821
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
If we are compiled without kerberos support, afscp_util.c generates a
warning, breaking the build when built with --enable-checking:
CC .../src/libafscp/afscp_util.o
.../src/libafscp/afscp_util.c:152:1: error: '_GetLocalSecurityObject' defined but not used [-Werror=unused-function]
To avoid this, don't define _GetLocalSecurityObject if we don't have
HAVE_KERBEROS.
Change-Id: I2515402e19c6c44ad70de6e6ab16c39d61334ab4
Reviewed-on: https://gerrit.openafs.org/15818
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
The function afs_InitCacheFile can return an error under two
conditions: if the number of calls exceeds the number of cache files
specified during cacheinit, and if there is an error while performing
the lookup for the cache filename. In both cases, there there is
nothing logged to assist in diagnosing the problem.
Add diagnostic warnings for the above two conditions with information
related to the error condition.
Change-Id: I887c8b8ec5840c0f1947b6153710b2dba26ab21c
Reviewed-on: https://gerrit.openafs.org/15570
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Our opr/softsig-t tests run softsig-helper to generate SIGSEGV and
SIGBUS signals (among other things), which may generate core files (if
'ulimit -c' is nonzero). The core files are useless, since we expect
those signals to be generated.
Usually the core files are generated in the build tree (where we run the
tests from), which is a minor annoyance. But some systems may be
configured to store core files in a central location (e.g.
/var/lib/systemd/coredump), which starts to build up over time after
many builds.
To avoid this, prevent core files from being generated in softsig-helper
for the SIGSEGV and SIGBUS cases by calling setrlimit().
Change-Id: Ice71e79009cf2b44d4cbe32233d3a7ee12e08d2d
Reviewed-on: https://gerrit.openafs.org/15795
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit 09aba81c50 (Cast LWP event functions to void pointer) fixed a
compiler warning when building binaries with LWP threaded, but did so in
a way that appeased the compiler but did not address the underlying
undefined behavior.
The ISO C standard states "a pointer to any object type may be converted
to a pointer to void and back again; the result shall compare equal to
the original pointer", but since a function is not defined as an object,
the conversion of function pointer to a void pointer is undefined.
Fix this by creating dummy integer globals to be used as the event ids
for the few places function pointers are used for event ids. The values
of the dummy variables are set but are never read.
Change-Id: I00084b882fe62cb0a82963ef45c390e5082c6fab
Reviewed-on: https://gerrit.openafs.org/15794
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The merge-pod script is our simple custom preprocessor for man-page pod
files. The merge-pod script expects one or more arguments to specify the
input files and generates the output files in the same directory as the
input files. Unfortunately, this precludes us from using merge-pod to
do out-of-tree builds (a.k.a. objdir builds) which generate man-pages,
since the output files are written to the source directory.
Change merge-pod so when no input files are specified, merge-pod will
scan the man-page pod<n> directories for *.in files, and put the pod
output files in pod<n> directories in the current working directory.
With this change, merge-pod remains compatible with the old method,
which is still in use by the NT makefile and the regen.sh script, but
provides support for a future commit to invoke merge-pod from the
man-pages Makefile.
Change-Id: I36b5b851cd1a09d050cf21c65ab3ae160a5c15cb
Reviewed-on: https://gerrit.openafs.org/15788
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Errors from GetCell() are reported a bit oddly in its three callers:
- In WhichCellCmd() (and GetFidCmd() before change
Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we print an odd "no such
cell" error for ENOENT, and a more normal message for all other
errors.
- In BadName() (and GetFidCmd() after change
Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we don't print an error
at all, sometimes making it not obvious that an error has occurred.
(BadName() is called from 'fs cleanacl'.)
The ENOENT message can be confusing to users, since ENOENT is the
error code we get if the given path doesn't exist. This is easy to see
with 'fs whichcell':
$ fs whichcell notexist
fs: no such cell as 'notexist'
The VIOC_FILE_CELL_NAME pioctl also never returns ENOENT itself, so
this only happens if the given file doesn't exist. This behavior goes
back to OpenAFS 1.0.
To improve this, change GetCell() to report errors itself. So now
errors are reported from it consistently, and are printed for all
callers. For example:
$ fs whichcell notexist
fs: Failed to get cell for 'notexist'
fs: File 'notexist' doesn't exist
The message is a little redundant, but this lets us use the existing
error reporting from Die() while still providing context for what is
failing, since it may not be obvious for 'fs cleanacl' or 'fs getfid'.
Change-Id: Ib4a84288a9c2d94b2b0d3c4c360fc5c014e98b30
Reviewed-on: https://gerrit.openafs.org/15586
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, 'fs getfid' fails if we cannot get the cell for the given
file via GetCell(). This GetCell call was added in commit d390df097c (fs
getfid output changed for consistency with Windows implementation) to be
more similar to the WINNT 'fs getfid', but the WINNT 'fs getfid' still
prints the fid if getting the cell fails (and has since it was
introduced in commit 5520747790 (windows-fs-getfid-20090511)).
GetCell() shouldn't normally fail if getting the fid succeeded, but in
case it does, don't prevent us from printing the fid. Change 'fs
getfid' to just say the cell is "unknown-cell" and keep going.
Change-Id: Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6
Reviewed-on: https://gerrit.openafs.org/15585
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
After we get the fid for the requested path, 'fs getfid' then gets the
cell for the path:
GetCell(ti->data, cell);
But ti->data is the full path requested, whether -literal was given or
not. If the given path ends with a broken symlink/mountpoint or
nonexistent fid, we've already gotten the fid (if -literal was given)
but we'll still exit with an (often confusing) error:
$ fs getfid symlink.broken -literal
fs: no such cell as 'symlink.broken'
In addition, if we use 'fs getfid -literal' to get the fid of a
cross-cell mountpoint object, we'll get the wrong cell. We'll report
the cell of the mountpoint's target, instead of the cell of the
reported fid:
$ fs getfid /afs/example.com -literal
File /afs/example.com (1.16777244.1) located in cell example.com
To fix these, pass 'parent_dir' to GetCell() when -literal is given.
To do this, we need to not free parent_dir until later, so reorganize
the 'parent_dir' and 'last_component' vars to be freed at the end of
the loop, and change the 'continue' code paths to goto the end of the
loop instead.
With this, the cell is now reported properly for these cases:
$ fs getfid symlink.broken -literal
File symlink.broken (536871063.22.865) located in cell example.com
$ fs getfid /afs/example.com -literal
File /afs/example.com (1.16777244.1) located in cell dynroot
Change-Id: I8ec297dae84f677d530b6f7c39786f18c2a9c50f
Reviewed-on: https://gerrit.openafs.org/15584
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 3961e416f6 'rx: Cleanup and build simple.example' fails to
build on Solaris 11.3 or older due to undefined socket and resolver API
symbols, including bind, getsockname, connect, recvfrom, etc:
LD /.../src/rx/simple.example/sample_client
Undefined first referenced
symbol in file
bind /.../lib/libafsrpc.a(rx_user.o)
getsockname /.../lib/libafsrpc.a(rx.o)
gethostbyname sample_client.o
[...]
ld: fatal: symbol referencing errors. No output written to sample_client
This is because on Solaris, these have historically been supplied via
-lsocket, -lresolv, and other libraries as defined in the OpenAFS
variable XLIBS.
Add XLIBS to our link rules in the simple.example Makefile to avoid
these errors.
On Solaris 11.4, XLIBS is not required to build because the APIs
formerly found via XLIBS are now largely provided in libc.so instead,
with libsocket.so and libresolv.so maintained for compatibility as
filters on libc.so.
Change-Id: Id3b5d1903aa41807cca7a97d48dac9ff272101b1
Reviewed-on: https://gerrit.openafs.org/15789
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, volinfo/volscan offers an optional -volumeid parameter,
allowing users to specify the id of a single volume to generate output
for. If this option is omitted, volinfo/volscan processes every volume
in the specified partition, or all local partitions if no partition is
specified. Internally, when the -volumeid parameter is not provided, its
corresponding variable defaults to 0, which volinfo/volscan interprets
as an indication to process all volumes.
Unfortunately, if an invalid volume id is specified (e.g., a volume name
instead of a number), volinfo/volscan incorrectly treats it as 0 and
processes all volumes instead of validating the input and notifying the
user. This issue occurs because strtoul(), the function used to convert
the volume id string to a number, returns 0 when it fails to perform a
valid conversion, leading volinfo/volscan to misinterpret invalid volume
ids as 0.
This commit fixes this issue by adding validation for the -volumeid
option. It parses the result from strtoul() and returns an error if the
volume id is invalid. This ensures that users are properly informed when
an invalid id is provided, preventing unintended processing of all
volumes in the given partition.
Change-Id: I166211c8814c13f4a79273efa6408a447f0855a9
Reviewed-on: https://gerrit.openafs.org/15771
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
In ostype.m4 and sysname.m4, we detect amd64 FreeBSD by matching $host
against "x86_64-*-freebsd*". On FreeBSD, `uname -p` on these systems
prints "amd64", but the config.guess from the GNU config project (that
is, <https://savannah.gnu.org/projects/config/>) translates amd64 into
x86_64 for FreeBSD, and has for a very long time.
For whatever (historical) reasons, anything built from FreeBSD ports
uses a version of the config.guess script that has FreeBSD-specific
modifications (which lives in /usr/ports/Templates/config.guess). This
version does not translate amd64 into x86_64, and so our $host looks
like, for example:
$ sh /usr/ports/Templates/config.guess
amd64-unknown-freebsd12.3
If regen.sh is run on a FreeBSD host, we pull our config.guess from
libtool, which normally is built from FreeBSD ports, and so results in
a host triplet with "amd64" for amd64 hosts. And so the build breaks
early on, because we don't recognize that we're on FreeBSD.
To accommodate this, match our amd64 FreeBSD host triplets against
amd64 or x86_64, so we can build using a config.guess from FreeBSD or
GNU upstream.
Change-Id: I372c9c9150b6639fa0cda96052cf50eb2857a3bb
Reviewed-on: https://gerrit.openafs.org/15159
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Måns Nilsson <mansaxel@besserwisser.org>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
afs_xsetgroups was using old-style function definitions, and lacked a
proper prototype. Modernize the function definition, and make a proper
prototype for it.
Change-Id: Ib11a7fc15afabdf0a538da4c1665acae6041fda5
Reviewed-on: https://gerrit.openafs.org/12708
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Here, &avc->multiPage is just a struct afs_q*, so comparing it
directly to 'range' results in a compiler warning. Cast it to a struct
multiPage_range* to avoid the warning.
Change-Id: If37e078deadb15c07a1c87c8b5c4785f823f7182
Reviewed-on: https://gerrit.openafs.org/12706
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
A couple of places call afs_putpage outside of osi_vnodeops.c (where
it's defined). So, add a prototype for it in osi_prototypes.h. Also
make the call sites actually follow the prototype, by giving the
correct arguments in the AFS_SUN511_ENV case.
Change-Id: I2c9e500ee0fe544df64b4d023091f4a1ad965485
Reviewed-on: https://gerrit.openafs.org/12704
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
afs_osi_vget was called in a few different places, but it lacked a
proper prototype. Add one in afs_prototypes.h.
Change-Id: I74310bcee88a48ee98b8c2ec22fdbfda8d4e0324
Reviewed-on: https://gerrit.openafs.org/12703
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Currently, ez_create() fails to release cmdpath when it returns early
due to a failure returned by bnode_InitBnode(). This commit resolves
this issue by ensuring that cmdpath is properly deallocated in such
failure scenarios, thereby preventing memory leaks.
Change-Id: I03b137f9f45eca41c538574d842e99445bf55b2c
Reviewed-on: https://gerrit.openafs.org/15718
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit c66971ce42 'man-pages: Generate man
pages with Pod::Man' inadvertently broke the top-level Makefile.in
'pristine:' rule.
This leads to the following error with 'make pristine':
...
doc/man-pages/man5 \
doc/man-pages/man8 \
for i in doc/man-pages/pod*/*.pod.in; do \
/bin/rm -f ${i%.in}; \
done
sh: syntax error at line 15: `do' unexpected
*** Error code 3
make: Fatal error: Command failed for target `pristine'
Remove the stray line continuation so the pod file deletion script will
work properly.
Additionally, the doc/man-pages/man* file objects are directories;
therefore the existing pristine rule 'rm -f' command will fail to remove
them:
...
doc/xml/mobi-fixup.xsl \
doc/man-pages/man1 \
doc/man-pages/man3 \
doc/man-pages/man5 \
doc/man-pages/man8
rm: doc/man-pages/man1 is a directory
rm: doc/man-pages/man3 is a directory
rm: doc/man-pages/man5 is a directory
rm: doc/man-pages/man8 is a directory
*** Error code 2
make: Fatal error: Command failed for target `pristine'
Reinstate the former 'rm -rf' command so the man-pages/man* directories
will also be properly erased.
Change-Id: I11658de0c02679d6c4b57917949cf2a70c9c019f
Reviewed-on: https://gerrit.openafs.org/15782
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The afs_orig_setgroups* function pointers are used for
storing/resetting the function pointers in sysent[].sy_callc. On at
least Solaris 11, these return an int64_t, so change the
afs_orig_setgroups* declarations to reflect that.
Change-Id: Ie86ee999084a8c08c564427e3308b1d592ef68f5
Reviewed-on: https://gerrit.openafs.org/12707
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
modlookup returns a uintptr_t, not an actual pointer. Cast the result
to a pointer to avoid a compiler warning.
Change-Id: I33cf4600d21a713be3f90c1b6d626bdab2c3da28
Reviewed-on: https://gerrit.openafs.org/12705
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Fix a few functions that were declared without a return type, or were
using old-style declarations.
Change-Id: I1d19d06a588ba2d2e5005bfe8ca5dd267018ccdd
Reviewed-on: https://gerrit.openafs.org/12702
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
The gid_t arrays we get from crgetgroups are const, so declare our
local gid_t array const, as well, to avoid a compiler warning.
Change-Id: Id8a375bb17b5bbd28e81460b6cb68711802850c3
Reviewed-on: https://gerrit.openafs.org/12701
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Many of our function callbacks for vnode ops have incorrect function
signatures or return types for Solaris 11, since Solaris has added or
changed the arguments to these functions over time. None of these
updates significantly change the code in our implementation of these
functions, but update the signatures to avoid compiler warnings.
This commit restricts updates to Solaris 11. Some of these updates may
have happened earlier (e.g. in Solaris 10, or our signature was just
always wrong), but this commit allows for at least one platform with
reduced warnings.
Change-Id: I974071fe55c8a31279888f62443e8a234a14cd4c
Reviewed-on: https://gerrit.openafs.org/12700
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
caller_context_t is a type itself, not a struct name.
Change-Id: I0966f5be326cdad706324d8547a63518bbce6edc
Reviewed-on: https://gerrit.openafs.org/12699
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Include sys/vmsystm.h, so we get a prototype for map_addr().
Change-Id: Ia8d20d35993eab58fb3530b52366276edef70d5e
Reviewed-on: https://gerrit.openafs.org/12698
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, gafs_fid takes a 'struct fid **' argument, and gives it to
afs_fid(). But afs_fid() takes a 'struct fid *', and the Solaris
vop_fid callback also takes a 'struct fid *'. Just change the argument
to 'struct fid *' to get rid of compiler warnings for both of these
mismatches.
Change-Id: Ie937e4b24ef51265a5957666eda496661f3943ad
Reviewed-on: https://gerrit.openafs.org/12697
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
The generate-man script is currently a shell script which invokes the
pod2man command for each pod file to be converted into a man page. This
makes the pod conversion slow, since we load Perl and create a Pod::Man
parser for each pod file. In addition to being slow, generate-man
leaves behind a partially created man page when an error is
encountered during the pod2man execution.
To fix these issues, rewrite generate-man as a Perl script which uses
the Pod::Man module directly. The Pod::Man parser is created only once
and is reused to generate each man page. The Pod::Man module supports
this type of batch mode operation by clearing its internal state after
each man page is created.
We have some special processing to determine the man page names for the
pages in section 3, so create a sub class to handle the pod filename to
man page title determination, and add a helper function to support
processing more than one section with a single parser instance.
Be sure to cleanup any partially created man pages if an error is
encountered during the pod to man conversion. This will let us use this
script in the Makefiles in the future.
Change-Id: I8d3cce1edc62c490e93d05f72609dfde4b599a1b
Reviewed-on: https://gerrit.openafs.org/15774
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Originally, OpenAFS documentation was maintained in a separate tree, so
the doc directory may not be present when doing a build. However, the
docs have been maintained in-tree for many decades, and even though we
still distribute the doc tree in a separate tar archive, package
builders are accustomed to unpacking the docs archive in order to
package the man pages.
Clean up and simplify the top level makefile by removing the checks for
the doc directory. Unconditionally generate the Makefiles from
Makefile.in files in the doc tree.
Starting with this change, unpacking the doc tarball will be required
(no longer just optional) when building from source distribution
tarballs.
Change-Id: Idfadb33d365777a561dc64e7d336a49eb74b8b48
Reviewed-on: https://gerrit.openafs.org/15772
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>
Since the original IBM code import, the Unix cache manager has contained a few
fragments of apparently vestigial code related to processing directories via
RXAFS_BulkStatus.
Remove the unused code.
No functional change is incurred by this commit.
Change-Id: I60998b304c333ec177c1d88e5bea2e5beacabec3
Reviewed-on: https://gerrit.openafs.org/15398
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commands like 'fs flush' and 'fs flushvolume' require the caller to be
able to lookup the target file, but 'fs flushall' has no access checks
at all, and hasn't since it was introduced in commit 4197bbecd9
(libafs: fs flushall for unix cm). This allows unauthenticated users
to flush the cache of files/volumes they have no access to, and means
flushing the entire cache requires less access than flushing parts of
the cache, which doesn't make much sense.
Change the command to only be runnable by the local superuser root,
and document the restriction.
Change-Id: I906d6c02a16b49ae31ab8e644a8ffb85c4e3434d
Reviewed-on: https://gerrit.openafs.org/15393
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, we inhibit various -Wdeprecated-declarations warnings via
"#pragma GCC diagnostic warning". Some older compilers (like gcc 4.1 on
RHEL5) don't understand the pragma, but still need the warning inhibited
in order to build with --enable-checking. So just inhibit this warning
via command-line CFLAGS instead of using #pragma directives.
One source file, tests/auth/superuser-t.c, was inhibiting the
-Wdeprecated-declaractions warning unnecessarily (it has not been needed
since commit 5815a04cf1 (tests: Move token faking code to its own
file)). Just remove the warning inhibition there, instead.
Change-Id: I52b1aeeac8699f9a4820626e9f1349f8cd380585
Reviewed-on: https://gerrit.openafs.org/15777
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Heimdal's hcrypto declares various DES functions as deprecated. We use
these functions in various files, and so we inhibit the
-Wdeprecated-declarations warning so we can build with
--enable-checking.
Heimdal declares these functions as deprecated using the HC_DEPRECATED
(or HC_DEPRECATED_CRYPTO) macro, which conditionally expands to
__attribute__((deprecated)) depending on the platform. If we define
HC_DEPRECATED ourselves to nothing before including the relevant header
file, those functions will effectively not be declared deprecated. Some
of our source files do this to avoid the -Wdeprecated-declarations
warning.
Some of our code does one of these to avoid the warning, and some does
both. We should pick one or the other, and be consistent about it. In
this commit, get rid of defining HC_DEPRECATED (and
HC_DEPRECATED_CRYPTO) ourselves, and just inhibit the relevant warning
the same way we do for all other warnings.
All instances of this are also currently missing from the "Inhibited
warnings" section in CODING. Add all instances to that list.
Change-Id: I4d7ece94be22457ceefbe52b6ec286e67423e8cb
Reviewed-on: https://gerrit.openafs.org/15776
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since commit 840cf3b628 (afs: Introduce afs_kill_pending()),
osi_misc.c has lacked a newline at the end of the file. This triggers a
warning on some old compilers, such as gcc 4.1 on RHEL5, which breaks
the build when using --enable-checking:
[...]/src/libafs/MODLOAD-2.6.18-419.el5-SP/osi_misc.c:205:2: error: no newline at end of file
Add a newline to get rid of the warning/error.
Change-Id: Id5a3a3f36c4f51b36426b2fe78ac5afb1f4fb6b3
Reviewed-on: https://gerrit.openafs.org/15775
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, we inhibit various -Wstrict-prototypes warnings via
"#pragma GCC diagnostic warning". Some older compilers (like gcc 4.1
on RHEL5) don't understand the pragma, but still need the warning
inhibited in order to build with --enable-checking. So just inhibit
this warning via command-line CFLAGS instead of using #pragma
directives.
Change-Id: If5b37cba460bc243dbaeadc6305908aed0ad34d4
Reviewed-on: https://gerrit.openafs.org/15219
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit dba6ec9548 (cf: Set CC before calling AC_PROG_CC) moved our
logic for preventing a default CFLAGS from the top-level
configure.ac/configure-libafs.ac into OPENAFS_CONFIGURE_COMMON. This
doesn't work, because OPENAFS_CONFIGURE_COMMON calls
AC_USE_SYSTEM_EXTENSIONS, which effectively runs the compiler and sets
default CFLAGS at the beginning of OPENAFS_CONFIGURE_COMMON.
This means that if the user doesn't specify any CFLAGS, autoconf will
set our CFLAGS to the default of '-g -O2', which can break various
environments. (For example, --disable-optimize no longer works, because
that flag only controls the OPTMZ var, and doesn't touch CFLAGS.)
To fix this, move our logic for preventing default CFLAGS into
OPENAFS_PATH_CC, which is explicitly called before
OPENAFS_CONFIGURE_COMMON so we can set the compiler before autoconf sets
its defaults. This should ensure that we are setting CFLAGS before
autoconf does; otherwise, we're also probably not setting CC early
enough, either.
Change-Id: Ic64e46aee35ffd3b5ee4ad1241c4c7366d9ccb67
Reviewed-on: https://gerrit.openafs.org/15778
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The test_ftm and butm_test programs link against the libbutm.a library.
Currently those targets depend on libbutm.a but the link command also
includes the ${TOP_LIBDIR}/libbutm.a which is made by the install
target.
This can lead to errors during a parallel build:
gcc ... -o test_ftm test_ftm.o libbutm.a ... <top_dir>/lib/libbutm.a ...
gcc: error: <top_dir>/lib/libbutm.a: No such file or directory
Remove the ${TOP_LIBDIR}/libbutm.a from the LIBS macro, so the test_ftm
and butm_test programs are built from the libbutm.a in the local
directory, which those programs depend on.
Change-Id: I695b0bbff4053804c514b361dca4da49e623a2a3
Reviewed-on: https://gerrit.openafs.org/15781
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, the buserver has set its Rx dead
time to 60 seconds at initialization. Not only is this unnecesarily
long, but it is also moot because a subsequent call to rx_InitHost
resets the rx dead time to the default 12 seconds.
Remove the superfluous rx_SetRxDeadTime.
Change-Id: I21acaf3cef1c80af06fa031ca2cdecd29d0fc5a3
Reviewed-on: https://gerrit.openafs.org/15592
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
If an error is encountered, 'fs flush' and 'fs flushvolume' try to
print an error message using perror(), but do so after calling
fprintf(), which may change the value of errno.
Also, 'fs flushall' doesn't try to print a reason for an error at all;
it just shows that some kind of error happened.
Change all of these to print an errno-derived error message using
strerror().
Change-Id: I3d7983c6d48068d3b4cb11ae2e6a1d890f8b8ba7
Reviewed-on: https://gerrit.openafs.org/15392
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, the most common way to free an object allocated by xdr is
to call:
xdr_free((xdrproc_t) xdr_foo, &foo);
Which runs the given object through the xdr routines with the XDR_FREE
operation. This works, but is not typesafe; if the wrong xdr_foo
routine is given to xdr_free, we will silently run the wrong xdr
routines, potentially freeing corrupt memory, etc.
It is easy to make this mistake when dealing with many different XDR
types, or dealing with various levels of indirection (e.g. an array of
pointers to ...). It is also easy to make mistakes with strings;
xdr_string() isn't really appropriate to give to xdr_free(), since
xdr_string() takes 3 arguments, instead of the 2 arguments of most
other xdr_type() routines. Commit bbb1e8adfe (xdr: Avoid xdr_string
maxsize check when freeing) is an example of these issues.
There is a typesafe way to free an xdr object, if the caller basically
copies the implementation of xdr_free():
{
XDR x;
x.x_op = XDR_FREE;
(void)xdr_foo(&x, &foo);
}
But this is rather cumbersome, and so is uncommon.
To allow convenient freeing of xdr objects in a typesafe manner,
introduce a generated function for each xdr type, called
xdrfree_type(). This should result in the same behavior as xdr_free(),
but does so in a typesafe manner and avoids the weird quirks with
xdrproc_t and AFS_XDRPROC_NO_VARARG.
Also define xdrfree_string(), to allow for convenient typesafe freeing
of XDR strings directly.
This commit does not add any calls to xdrfree_type(), but future
commits will do so.
Change-Id: Icf34e6de5d0da2b43b3e8ad3dc1acc74ef0e61dd
Reviewed-on: https://gerrit.openafs.org/15497
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
When processing the -trace option for the vlserver (and a couple of
other places), we can easily overflow the rxi_tracename array if the
given string is too big. While the way this global setting works in
general isn't the best, at least for now just prevent the buffer
overflow by doing a simple bounds check with strlcpy.
Change-Id: I41faec8d2aa09f871a69d7db1643f1117aa5618c
Reviewed-on: https://gerrit.openafs.org/14753
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Currently, the refCount in struct rx_securityClass is not protected by
any locks. Thus, if two threads create or destroy a connection using
the same rx_securityClass at the same time (or call rxs_Release), the
refCount can become inaccurate. If the refCount is undercounted, we
can prematurely free it while it's still referenced by other
connections or services, leading to segfaults, data corruption, etc.
For client connections, this can happen between any threads that
create and destroy a connection using the same security class struct.
For server connections, only two threads can race in this way: the rx
listener thread (which creates connections), and the rx event thread
(which destroys idle connections in rxi_ReapConnections).
To fix this, ideally we would change the refCount field to be an
rx_atomic_t. However, struct rx_securityClass is declared in the
public installed rx.h header, which cannot include rx_atomic.h. So
instead, change refCount users to go through a few new functions:
rxs_Ref(), rxs_DecRef(), and rxs_SetRefs(). These functions interpret
the refCount as an rx_atomic_t, and so allows callers to use safe
refcounting without needing to call rx_atomic_* functions directly.
Rename the existing refCount field to refCount_data, and declare it as
a char[8]. This gives us enough space to use it as an rx_atomic_t, but
avoids using rx_atomic_t in a public header, and discourages callers
from manipulating the refCount directly.
Thanks to mvitale@sinenomine.net for helping investigate the relevant
issue.
Change-Id: I55094218c79e8bc5498a6d2c1daa5620b1fceaff
Reviewed-on: https://gerrit.openafs.org/15158
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
When building with --enable-checking, any of our "#pragma GCC
diagnostic warning" lines that are not understood by the compiler
tend to raise a warning, and so causes the build to fail. For example:
CC .../src/rxkad/ticket5.lo
cc1: warnings being treated as errors
.../src/rxkad/ticket5.c:64: warning: ignoring #pragma GCC diagnostic [-Wunknown-pragmas]
Sometimes an older compiler (like gcc 4.1 on RHEL5) doesn't need a
particular warning to be inhibited, but it doesn't understand the
pragma, and so the pragma can be safely ignored. So to avoid
unnecessary build failures on platforms like RHEL5, add
-Wno-unknown-pragmas to our CFLAGS when building with
--enable-checking, so unknown pragmas don't issue warnings. If we
accidentally ignore a pragma that is required on another platform, the
build will still fail as usual, just in a slightly different way.
Change-Id: I3ebfbfd489245aa2ae0494f397d815e284001bf3
Reviewed-on: https://gerrit.openafs.org/15218
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Building on RHEL5 with gcc 4.1 yields a few warnings that break the
build with --enable-checking.
A couple of headers lack a newline at the end of the file, such as
audit.h:
CC .../src/audit/audit.lo
In file included from .../src/audit/audit.c:30:
.../src/audit/audit.h:337:31: error: no newline at end of file
And UKERNEL's afsincludes.h:
CC .../src/libuafs/afs_analyze.lo
In file included from .../src/afs/afsincludes.h:16,
from .../git-foo/src/afs/afs_analyze.c:34:
.../src/afs/UKERNEL/afsincludes.h:35:47: error: no newline at end of file
To fix these, just add a trailing newline.
osi_vfsops.c has an 'out:' label that is only used under certain
#ifdefs, but we always define it, leading to a warning when it's
defined but not used:
CC [M] .../src/libafs/MODLOAD-2.6.18-419.el5-MP/osi_vfsops.o
cc1: warnings being treated as errors
.../src/libafs/MODLOAD-2.6.18-419.el5-MP/osi_vfsops.c: In function 'afs_fill_super':
.../src/libafs/MODLOAD-2.6.18-419.el5-MP/osi_vfsops.c:167: warning: label 'out' defined but not used
To fix this, put the 'out:' definition under the same conditions as
its users.
rxgk_crypto_rfc3961.c uses 'iterations' in a way where gcc claims it
may be uninitialized:
CC .../src/rxgk/rxgk_crypto_rfc3961.lo
cc1: warnings being treated as errors
.../src/rxgk/rxgk_crypto_rfc3961.c: In function 'rxgk_derive_tk':
.../src/rxgk/rxgk_crypto_rfc3961.c:617: warning: 'iterations' may be used uninitialized in this function
This doesn't seem possible to actually use uninitialized, but
initialize it to get rid of the warning.
Change-Id: I68dc4378d03f956c0e81b1dba37ed09d2e396c56
Reviewed-on: https://gerrit.openafs.org/15217
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>
The linux/config.h header has been useless since Linux 2.6.15 commit
2dd34b488a99135ad2a529e33087ddd6a09e992a ([PATCH] kbuild: permanently
fix kernel configuration include mess).
In Linux 2.6.19 commit 038b0a6d8d32db934bba6a24e74e76e4e327a94f
(Remove all inclusions of <linux/config.h>), included in some RHEL5
kernels, a #warning was added to it, which breaks building with
--enable-checking.
The header was removed entirely in Linux 2.6.20 commit
b0ac3f50b8f2cd992ffd36d22c82eabdf075e9c4 ([HEADERS] Put linux/config.h
out of its misery.).
Since the header has been unnecessary since 2.6.15, before our Linux
minimum version of 2.6.18, stop checking for the header at all. This
avoids an error with --enable-checking on RHEL5, and gets rid of a
configure-time check.
Change-Id: Ifa2cea7bd2c7911959910bdb8a6a01e0db016dd7
Reviewed-on: https://gerrit.openafs.org/15216
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Fix a few functions that were declared without a return type, or
were using old-style K&R declarations.
[mmeffie: Update commit message.]
Change-Id: Ia1f27202cc59e7471899790b37c14054a16bd8ea
Reviewed-on: https://gerrit.openafs.org/15359
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Convert the afs_cv_wait() and afs_cv_timedwait() function declarations
and definitions from K&R to ANSI style.
Provide prototypes to eliminate the warnings, such as:
warning: implicit function declaration: afs_cv_wait
[mmeffie: convert afs_cv_timedwait() as well.]
Change-Id: Ibf051838f4678cad67cfb6259d2997ddce9e8067
Reviewed-on: https://gerrit.openafs.org/15358
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
