Benjamin Kaduk [Thu, 14 Jan 2021 18:50:13 +0000 (10:50 -0800)]
Pull in upstream patches for unixtime 0x60000000 CID fix
A combination of bugs led to a static CID value being used for all
outbound connections when a process was started after unix epoch time
0x60000000. That essentially means failure to communicate on all
connections.
Fix the bugs, and also make sure that we always use a random initial
CID instead of getting a static one half the time.
Benjamin Kaduk [Sat, 26 Sep 2020 18:51:44 +0000 (11:51 -0700)]
Some tidying in debian/rules
Use immediate assignment for a literal string.
Use DEB_VERSION from /usr/share/dpkg/pkg-info.mk instead of
manually invoking dpkg-parsechangelog, to appease lintian.
Cheyenne Wills [Fri, 15 May 2020 16:40:20 +0000 (10:40 -0600)]
LINUX-5.7: replace __pagevec_lru_add with lru_cache_add_file
The Linux function __pagevec_lru_add is no longer exported in Linux
5.7-rc1 commit bde07cfc65da5fe6c63fe23f035f5ccc0ffd89e0
"mm/swap.c: not necessary to export __pagevec_lru_add()".
As a replacement, the Linux function lru_cache_add_file can be used for
adding a page to the lru cache. The internal processing of
lru_cache_add_file manages its own internal pagevec and performs the
following:
get_page(...)
if(!pagevec_add(...))
__pagevec_lru_add_file(...)
Introduce an autoconf test for lru_cache_add_file and replace the calls
associated with __pagevec_lru_add with lru_cache_add_file.
NOTE: see Linux commit a0b8cab3b9b2efadabdcff264c450ca515e2619c
"mm: remove lru parameter from __pagevec_lru_add and remove parts of
pagevec API" as a reference for this change.
The lru_cache_add_file was introduced in Linux 2.6.28, therefore this
change affects systems with Linux 2.6.28 kernels and later.
Reviewed-on: https://gerrit.openafs.org/14159 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 17b42fe67c18fab0003fb712092d36f06c93f2eb)
Change-Id: I206925d1659164a54e0c3a41b82a1733cb656b41
Reviewed-on: https://gerrit.openafs.org/14210 Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 15 May 2020 16:39:53 +0000 (10:39 -0600)]
libafs: Abstract the Linux lru cache interface
Define static functions afs_lru_cache_init, afs_lru_cache_add and
afs_lru_cache_finalize to handle interfacing with Linux's lru
facilities.
This change's primary purpose is to isolate the preprocessor
conditionals associated with the details of the system lru interfaces to
just these functions and to simplify the areas that utilize lru caching
by removing the preprocessor conditionals.
As Linux's lru facilities change, additional conditional code will be
needed.
Reviewed-on: https://gerrit.openafs.org/14167 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dca95bcb7efdff38564dcff3e8f4189735f13b3a)
Change-Id: I863bbc9bb578716c42fdf34672ec8ad85f05ea31
Reviewed-on: https://gerrit.openafs.org/14209 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Mon, 18 May 2020 21:20:26 +0000 (17:20 -0400)]
LINUX 5.6: define osi_timeval32_t for 32-bit Linux
For 32-bit Linux (e.g., arch i586), AFS_LINUX_64BIT_KERNEL is not
defined, so osi_timeval32_t is defined as a typedef of the native
'timeval'. However, as of commit c766d1472c70d25ad475cf56042af1652e792b23 "y2038: hide
timeval/timespec/itimerval/itimerspec types" (Linux 5.6), the native
timeval struct is no longer available. On such a kernel, the OpenAFS
build will fail because osi_timeval32_t is not properly defined.
Instead, add new conditionals to properly define osi_timeval32_t for
this platform.
Reviewed-on: https://gerrit.openafs.org/14216 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9a5790cfbb8e7b1a4a2e832911c71da49f604c20)
Change-Id: I223d8407bf28e91ffb2669013c089053ae93feb3
Reviewed-on: https://gerrit.openafs.org/14234 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
If swig package is installed on a ppc64le system, build fails for
"libuafs" while running "shlib-build". "shlib-build" gets executed for
builing ukernel.so and this is triggered if "LIBUAFS_BUILD_PERL" is not
empty. Having "swig" package on system sets "LIBUAFS_BUILD_PERL" to
'LIBUAFS_BUILD_PERL' value. The reason for build failure was inside
"shlib-build", 'linker' was not set (it was empty). 'linker' value is
set based on SHLIB_LINKER, which was not defined in osconf.m4 if build
system is ppc64le.
To fix this add ppc64le_linux26 case in osconf.m4 file.
Reviewed-on: https://gerrit.openafs.org/13980 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f9c716fca1becea5a41fbe86535759ef817c924d)
Change-Id: I20a9b58e83166932f9b00370f27a146cf3343ff9
Reviewed-on: https://gerrit.openafs.org/14104 Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Tue, 24 Mar 2020 22:41:35 +0000 (15:41 -0700)]
Temporarily disable volser tests
We need to get the armhf build working again so that we can migrate to
testing and not get autoremoved.
Since the build (and test) is fine on the armhf porterbox and the test in
question is comparing output that's a list of IP addresses, the presumption
is that the buildd's network configuration involves an IP address that the
test is trying to use.
Benjamin Kaduk [Sun, 22 Mar 2020 01:57:28 +0000 (18:57 -0700)]
Go back to only using --fail-missing for binary packages
My conversion to debhelper-compat 12 (that requires dh_missing vs
dh_install --fail-missing) was insufficiently careful to notice that
it was only being run in the -arch override, not always.
Frédéric Bonnard [Tue, 10 Dec 2019 13:54:34 +0000 (14:54 +0100)]
Fix missing bits for ppc64el
d/sysname : typo fix
[kaduk@mit.edu: just take the typo fix from
https://salsa.debian.org/debian/openafs/-/merge_requests/2; for the actual
patch we'll use the version present in upstream]
If time_t is missing, define the time_t type when building the kernel
module.
Change the vattr structure in LINUX/osi_vfs.h to use timespec/timespec64
instead of the timeval structure.
Conditionalize the definition of gettimeofday (needed by rand-fortuna.c) in
crypto/hcrypto/kernel/config.h. It is unused by the Linux kernel module
and the function uses struct timeval that is no longer available.
Reviewed-on: https://gerrit.openafs.org/14083 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 78049987aa3e84865e2e7e0f3dd3b54d66258e74)
Change-Id: Iff80c161441356d19b5962956dd524792b7bf629
Reviewed-on: https://gerrit.openafs.org/14095 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 2 Mar 2020 22:17:55 +0000 (16:17 -0600)]
LINUX: Avoid building rand-fortuna-kernel.o
Currently, we build rand-fortuna-kernel.o for libafs on all platforms,
even though we only use the fortuna RNG on AIX, DragonFlyBSD, HP-UX,
and Irix. Everywhere else, our RAND_bytes() in
src/crypto/hcrypto/kernel/rand.c uses osi_readRandom() instead of
going through heimdal.
Building rand-fortuna.c causes occasional build headaches for the
kernel on Linux (see cc7f942, "LINUX: Disable kernel fortuna large
frame errors"). The most recent instance of this is that Linux 5.6
removes the definition for struct timeval, which is referenced in
rand-fortuna.c.
The Linux kernel is constantly changing, and so trying to keep
rand-fortuna.c building on Linux seems like a waste of ongoing effort.
So, just stop building rand-fortuna-kernel.o on Linux. The original
intent of building this file on all platforms was to avoid bitrot, so
still keep building rand-fortuna-kernel.o on all other platforms even
when it's not used; just avoid it on Linux specifically, the platform
that requires the most effort.
To accomplish this, move rand-fortuna-kernel.o from AFSAOBJS to
AFS_OS_OBJS, and remove it from the Linux-only AFSPAGOBJS.
[1.8.x: The 1.8 branch does not contain the commits that introduced
-Wno-error=frame-larger-than= (cc7f942a and 54150f38), so we can skip
removing the references to -Wno-error=frame-larger-than=.]
Reviewed-on: https://gerrit.openafs.org/14084 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b8088b49dec23da19406fcb014e7100695dc8322)
Change-Id: Iad0d1af5ffd79c576ddbc253b0037b9772187350
Reviewed-on: https://gerrit.openafs.org/14094 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 14 Feb 2020 18:50:03 +0000 (11:50 -0700)]
LINUX 5.6: use struct proc_ops for proc_create
The Linux commit d56c0d45f0e27f814e87a1676b6bdccccbc252e9
(proc: decouple proc from VFS with "struct proc_ops") was merged into
Linux 5.6rc1. The commit replaces the 'file_operations' parameter for
proc_create with a new structure 'proc_ops'.
Conditionally initialize and use proc_ops structures instead of
file_operations structures for calls to proc_create.
Notes:
* proc_ops.proc_ioctl is equivalent to file_operations.unlocked_ioctl
* The macros HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL are both
hardcoded to 1 in linux's fs.h
* proc_ops.compat_ioctl is conditional on Linux's CONFIG_COMPAT macro
which is a separate test from the HAVE_COMPAT_IOCTL macro
Reviewed-on: https://gerrit.openafs.org/14063 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1626986bd6d70c526376cf7cedfd3ebbf6d3588a)
Change-Id: Icaab45f4542131e636f2c60e3efce86c8afc57be
Reviewed-on: https://gerrit.openafs.org/14069 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Fri, 7 Feb 2020 17:58:56 +0000 (14:58 -0300)]
macos: add anchors to synthetic.conf grep pattern
The grep pattern that checks if /etc/synthetic.conf already has an entry
for afs is intended to check if this file holds a single column entry
named afs. Unfortunately, the current version does not completely
enforce this restriction. To fix this problem, add anchors to the grep
pattern in question.
Reviewed-on: https://gerrit.openafs.org/14062 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6d6a28720f4eae4652f2628fdfcc30983916f39d)
Marcio Barbosa [Sun, 22 Dec 2019 03:56:41 +0000 (19:56 -0800)]
macos: add entry for afs into synthetic.conf
The root mount point is read-only as of macOS 10.15. As a result, /afs
cannot be created at this location. To workaround this restriction,
macOS 10.15 provides an alternative way to create mount points at the
root. To make it possible, an entry for the mount point in question must
be added to /etc/synthetic.conf. The synthetic entities described in
this file are not physically present on the disk. Instead, they are
synthesized by the kernel during system boot.
This commit adds an entry for afs into the file mentioned above. Knowing
that this change only takes effect after reboot, also provide directions
to the user during the installation process.
Reviewed-on: https://gerrit.openafs.org/13928 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit daf6616aab6732d6b417c15f6f401731ef8e44b5)
Change-Id: If990608d968061ac8ab0391dbd83d1c6a87d32a6
Reviewed-on: https://gerrit.openafs.org/14037 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Sun, 22 Dec 2019 03:11:57 +0000 (19:11 -0800)]
macos: add script to notarize OpenAFS
In order to integrate the notarization process into our existing build
scripts, this patch introduces a script to automatically notarize the
OpenAFS package.
Reviewed-on: https://gerrit.openafs.org/13671 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 0563642cc1cb750c69a6471005adf36fabb2b7e3)
Change-Id: I50265b3305eb12db45371da1bf1982a6722c0018
Reviewed-on: https://gerrit.openafs.org/14036 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Tue, 26 Nov 2019 19:41:36 +0000 (11:41 -0800)]
macos: prepare for notarization
With the public release of macOS 10.14.5, all new and updated kernel
extensions must be notarized by Apple. To be taken into consideration,
all executables must be signed and the Hardened Runtime capability must
be enabled.
This patch adds the missing prerequisites mentioned above.
Reviewed-on: https://gerrit.openafs.org/13670 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 63fd13bf9e6af21136007c9980816875ebea5f7c)
Change-Id: If0c27732f667945f430fd2c5698e8f58a84e3bde
Reviewed-on: https://gerrit.openafs.org/14035 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Mon, 18 Nov 2019 14:34:08 +0000 (06:34 -0800)]
macos: add support for MacOS 10.15
This commit introduces the new set of changes / files required to
successfully build the OpenAFS source code on OS X 10.15 "Catalina".
Reviewed-on: https://gerrit.openafs.org/13668 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 93815caabc92acc6edc62b72805b44d2e46748cf)
Change-Id: Ia1fb98dd59d7b0ddad9c16c04b823623e07dd498
Reviewed-on: https://gerrit.openafs.org/14033 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Fri, 13 Dec 2019 03:03:04 +0000 (19:03 -0800)]
macos: upgrade *.xib files
According to Xcode 11, the *.xib files updated by this commit use an
older format that is potentially insecure when decoded. To fix this
problem, Xcode automatically upgraded these files to the modern format.
These changes are required to build OpenAFS on Catalina (Xcode 11).
Reviewed-on: https://gerrit.openafs.org/13935 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d4302d42149988fa6d04d626967063dfa916c9fd)
Change-Id: I1e29493a8431d4ad13ff36762f6112dd5309573c
Reviewed-on: https://gerrit.openafs.org/14032 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Fri, 8 Nov 2019 02:56:13 +0000 (23:56 -0300)]
macos: tell the compiler the system include path
In order to support multiple SDKs, macOS Catalina no longer has the
/usr/include directory. As a result, the compiler needs to know where
these headers can be found. To successfully build OpenAFS on OSX 10.15,
set KROOT so the compiler knows the correct location of these headers.
Reviewed-on: https://gerrit.openafs.org/13936 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 677b038814817defec9421e698ce67b44a7fd7d1)
Change-Id: I2043c2bc6e745ca55faf68b77d791168bc57bb1d
Reviewed-on: https://gerrit.openafs.org/14031 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 14 Nov 2019 20:29:56 +0000 (17:29 -0300)]
viced: add opt to allow admin writes on RO servers
Add the new option -admin-write to allow write requests from superusers
on file servers running in readonly mode (-readonly). This lets sites
run fileservers in readonly mode for normal users, but allows members of
the system:administrators group to modify content.
Reviewed-on: https://gerrit.openafs.org/13707 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f5f8b9336919debc5c26c429b12a14b65e0b697c)
Change-Id: Ia627b8c99767a875c1e8d1c69dcb45118df36937
Reviewed-on: https://gerrit.openafs.org/14019 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 14 Nov 2019 04:15:47 +0000 (01:15 -0300)]
viced: prevent writes on readonly fileservers
Currently, a fileserver can be initialized as readonly. In this mode,
writes on this server should not be allowed. Unfortunately, updates on
files stored by readonly fileservers are not completely prevented. In
some situations, the check for RO server is omitted (e.g. if the user is
the owner of the file to be updated). In other situations, the same
check is redundant.
To fix these problems, consolidate this check in one place.
Reviewed-on: https://gerrit.openafs.org/13934 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0593017177edd5b3bc6609d9dfcce55f15bba3e9)
Change-Id: I42034928d1f5e9342029121613ac8d716818c3ae
Reviewed-on: https://gerrit.openafs.org/14018 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: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 18 Nov 2019 02:58:15 +0000 (20:58 -0600)]
afs: Ensure CDirty is set during afs_write loop
Currently, in afs_write(), we set CDirty on the given vcache, and then
write the given data into various dcaches. When writing to a dcache,
we call afs_DoPartialWrite, which may cause us to flush the dirty data
to the fileserver and clear the CDirty bit.
If we were given more than 1 chunk of data to write, we will then go
through another iteration of the loop, writing more dirty data into
dcaches, but CDirty will not be set. This can cause issues with, for
example, afs_SimpleVStat() or afs_ProcessFS(), which use CDirty to
determine whether or not to merge in FetchStatus info from the
fileserver into our local cache. This can cause our local cache to
incorrectly reflect the state of the file on the fileserver, instead
of the state of the locally-modified file in our cache.
A more detailed example is as follows. Consider a small C program that
copies a file, fchmod()ing the destination before closing it:
Currently, on FBSD, using this to copy a 7862648-byte file, using a
smallish cache (10000 blocks) will cause the destination to appear to
be truncated, because avc->f.m.Length will be incorrect, even though
all of the relevant data was written to the fileserver.
On most other platforms such as SOLARIS and LINUX, this is not a
problem, since currently they only write one page of data at a time to
afs_write(), and so they never hit multiple iterations of the while()
loop inside afs_write().
To fix this, just set CDirty on every iteration of the while() loop in
afs_write(). In general, we need to set CDirty after calling
afs_DoPartialStore() anywhere if the caller continues to write more
data. But all callers already do this, except for this one instance in
afs_write().
Thanks to tcreech@tcreech.com for helping find occurrences of the
relevant issue.
FIXES 135041
Reviewed-on: https://gerrit.openafs.org/13948 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 9d0854547522f7b2fb1bb7aa876fe9f901674747)
Change-Id: Ie86313e9b9750bc6724bb6e18b7df8e010810023
Reviewed-on: https://gerrit.openafs.org/13951 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 5 Nov 2019 02:03:43 +0000 (20:03 -0600)]
afs: Avoid -1 error for vreadUIO/vwriteUIO
Commit c6b61a45 (afs: Verify osi_UFSOpen worked) added various checks
to return an error if a given osi_UFSOpen failed. However, two of
these checks (in afs_UFSReadUIO and afs_UFSWriteUIO) result in us
returning -1 on error, in functions that otherwise return errno codes
(e.g. ENOSPC). An error code of -1 might get interpreted as
RX_CALL_DEAD, which would be rather confusing, so use EIO as a generic
error instead.
Reviewed-on: https://gerrit.openafs.org/13931 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 360b9d5d71fb1de142ae4efd4660732476855a3f)
Change-Id: I4c6773affe02cc7a3ca01cf25bea21c960d98e87
Reviewed-on: https://gerrit.openafs.org/13938 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Michael Meffie [Mon, 22 Jul 2019 19:20:24 +0000 (15:20 -0400)]
vos: fix name availability check in vos rename
The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.
The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.
Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed. The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.
Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.
Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.
Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.
Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.
Reviewed-on: https://gerrit.openafs.org/13720 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9238b1eb9ef02889855eaade76e5b7962e5f2f28)
Change-Id: I8b03e4211c5d306f55779130c8461b14bc4913f0
Reviewed-on: https://gerrit.openafs.org/14055 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Fri, 4 May 2018 21:32:51 +0000 (17:32 -0400)]
ubik: improve logging for database synchonizations
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.
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>
(cherry picked from commit 0e1c042615d1aeb919a22568cdd2b2ea42c677ba)
Change-Id: I26e876e5bcd5adc004b985ea8c3f716cb6a72b5d
Reviewed-on: https://gerrit.openafs.org/13908 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Fri, 17 Mar 2017 22:12:23 +0000 (18:12 -0400)]
ubik: urecovery_AbortAll diagnostic msgs
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.
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>
(cherry picked from commit eac22d3e46c72c0e2b82f35c5187d50b6fa136a2)
Change-Id: Ia91bc1c5f041eccc9b974d4b195fed1a889252e7
Reviewed-on: https://gerrit.openafs.org/13907 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>
Mark Vitale [Tue, 9 May 2017 01:11:27 +0000 (21:11 -0400)]
ubik: log important messages at default log level
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.
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>
(cherry picked from commit 8b0e312d043d435f0e55c6dc14f5446ffedc7ce4)
Change-Id: I87425e78fb4f7fb1aa393b2f5b81ab34a71a38c4
Reviewed-on: https://gerrit.openafs.org/13906 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 27 Jul 2018 18:36:15 +0000 (13:36 -0500)]
ubik: Save errno before logging
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.
Reviewed-on: https://gerrit.openafs.org/13263 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 9ff5f8f7601cc9761cc6a4ef0e8b7c8c2c8dddb5)
Change-Id: I4f41ca758574e0d58659788467372af71a5f75f2
Reviewed-on: https://gerrit.openafs.org/13898 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Sat, 11 Aug 2018 17:17:28 +0000 (13:17 -0400)]
vol: remove empty directories left by vos zap -force
The vos zap -force command does not remove the directories associated
with the volume in question (AFS_NAMEI_ENV). When the vos zap -force
command is executed, the volume server goes through the /vicep*/AFSIDat
directories and removes the files associated with the volume id received
as an argument. Unfortunately, the volume server does not remove the
directories associated with this volume. As a result, empty directories
are left behind.
To fix this problem, remove the empty directories left behind when vos
zap -force is executed.
Reviewed-on: https://gerrit.openafs.org/12879 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 892045a9803ed471986569705d9d727165ca7ecf)
Change-Id: I18b727a561785443f488d60b967182e3ddb9064e
Reviewed-on: https://gerrit.openafs.org/13897 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 18:49:07 +0000 (12:49 -0600)]
vol: check snprintf return values in namei_ops
gcc8 is more aggressive about parsing format strings and computing bounds
on the generated text from functions like snprintf. In this case it seems best
to detect cases of truncation and error out, rather than trying to increase
stack buffer sizes or switch to asprintf. These paths should be well-behaved
since they are local to the fileserver, so this is mostly about appeasing the
compiler's -Wformat-truncation checks to allow us to build with --enable-checking.
Reviewed-on: https://gerrit.openafs.org/13463 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8632f23d6718a3cd621791e82d1cf6ead8690978)
Change-Id: Ie8f9005ad9cf7cdfd3eb472e01a6fdbde5b7e57e
Reviewed-on: https://gerrit.openafs.org/13732 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Tue, 31 May 2016 12:08:08 +0000 (09:08 -0300)]
venus: fix memory leak
In GetPrefCmd, when we request server prefs from the kernel and our
output buffer is not big enough, pioctl() will return E2BIG and we
allocate more memory and try again. However, if the size of the output
buffer reaches 16k bytes and this space is still not enough (or if
pioctl fails and errno != E2BIG), we return without releasing the
memory that was previously allocated.
To fix this problem, free our output buffer when this happens.
Reviewed-on: https://gerrit.openafs.org/12293 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8ad4e15ffc883c9a99f9636d7d8a5ed0a2fcc26a)
Change-Id: I62ceddc5284c94da205ec2351ab9ef970cd64c4a
Reviewed-on: https://gerrit.openafs.org/13895 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:09:36 +0000 (17:09 -0600)]
venus: appease gcc8's -Wformat-string
Interestingly, even before this commit, the buffer size was larger
than what the kernel would accept. Since the kernel does its own
length checking, it's simplest to just allow slightly larger requests
here and have them fail later.
Reviewed-on: https://gerrit.openafs.org/13471 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 dff81f1b78fecc54f5af91f7d728925ffca62d2c)
Change-Id: Ie19d887abebdd3603a04c06723f5cb750eb654f8
Reviewed-on: https://gerrit.openafs.org/13740 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Michael Meffie [Thu, 21 Dec 2017 16:59:38 +0000 (11:59 -0500)]
vol: avoid query for parent id when deleting disk header
When a DAFS volume server removes a volume disk header file (V*.vol),
the volume server invokes an fssync command to have the file server
delete the Volume Group Cache (VGC) entry corresponding to the volume id
and the parent id of the removed volume header.
The volume parent id is unknown to the volume server when removing a
volume disk header on behalf of a "vos zap -force" operation. In this
case, the volume server issues a fssync query to attempt look up to the
parent id from the file server's VGC. If this fssync query fails for
some reason, volume server is unable to delete the VGC entry for the
deleted volume header. The volume server logs an error and vos zap
reports a undocumented error code.
One common way this can be encountered is to issue a "vos zap -force" on
a file server that has just been restarted. In this case, the VGC may
not be fully populated yet, so the volume server is not able to look up
the parent id of the given volume.
With this commit, relax the requirement for the parent id when deleting
VGC entries. A placeholder of 0 is used to mean any parent id for the
given volume id.
This obviates the need to query for the parent id when performing a "vos
zap -force", and allows the volume server to remove any VGC entries
associated with the volume id being zapped.
Reviewed-on: https://gerrit.openafs.org/12839 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 65b55bcc26f69f25c67518f672b34be73f3be370)
Change-Id: I2e927d7b388c7be36a67e196a3acb70e58c9a661
Reviewed-on: https://gerrit.openafs.org/13896 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Mon, 6 Jun 2016 17:03:54 +0000 (14:03 -0300)]
sys: retry lsetpag if errno is EINTR
The variable errno might be set by some system calls to indicate the
reason why the system call in question did not work as expected. If the
setpag system call is interrupted by a signal, the value of errno will
be EINTR. This value means that setpag did not succeed because it was
interrupted.
If lsetpag did not succeed and errno is equal to EINTR, try again.
Reviewed-on: https://gerrit.openafs.org/12295 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2ae2a15c9dc9b26eaa15964cc96fdeeb6d82c74c)
Change-Id: I58d4aa633e5cadea2bc7b222f68306f07657b754
Reviewed-on: https://gerrit.openafs.org/13975 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 7 Nov 2019 03:10:12 +0000 (00:10 -0300)]
afs: afs_pag_wait() makes process unkillable
To enforce a maximum average rate of one PAG allocation per second,
afs_pag_wait(), called by afs_setpag*(), sleeps until the difference
between the current time and pag_epoch gets greater than pagCounter.
Unfortunately, this function ignores the code returned by afs_osi_Wait().
As a result, it is not possible to kill the process that requested the
new pag while afs_pag_wait() is sleeping.
To fix this problem, do not ignore the code returned by afs_osi_Wait().
Reviewed-on: https://gerrit.openafs.org/12260 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9563807791e2402f7a214a90e96cf6ed8ea5abfb)
Change-Id: Id2453d6eb2b6cc973082da28bb3746c9f9c5ddb2
Reviewed-on: https://gerrit.openafs.org/13974 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
afs: avoid extra VL_GetEntryByName for .readonly's
In the VLDB, there's only one logical entry for a volume and its
associated clones; there are not separate entries for the RW volume
"avol", the RO volume "avol.readonly", and the BK volume
"avol.backup". And so, when looking up a volume in the VLDB by name,
the vlserver ignores any trailing ".readonly" or ".backup" in the
given name. More concretely, the result of calling
VL_GetEntryByName*("avol") is identical to that from calling
VL_GetEntryByName*("avol.readonly").
Accordingly, if afs_GetVolumeByName(name) failed because the volume
was not found in the VLDB, afs_GetVolumeByName(name.readonly) will
fail as well (barring a change in external circumstances, such as the
volume being created or a network connection coming back up).
Therefore, the extra call in EvalMountData() is not necessary and can
be removed.
Remove the extra call, to slightly improve the response time of the
client if the volume in question does not exist, and to reduce
vlserver load when patched clients are looking up nonexistent volumes.
Michael Meffie [Fri, 4 Apr 2014 14:27:10 +0000 (10:27 -0400)]
cmd: improve help for programs without subcommands
Some programs do not have subcommands (other than the standard "help",
and "version" subcommands). The cmd library provides the "noopcode"
mechanism for new subcommand-less programs, but older programs take
advantage of the optional "initcmd" token to simulate subcommand-less
programs. The "initcmd" token is optional to run the command, however
it is required to display the command help.
For example, running the xstat_cm_test program without any options gives
a syntax error:
Retrying with -help (or help, -h, --help), gives the rather unhelpful
output:
$ xstat_cm_test -help
xstat_cm_test: Commands are:
apropos search by help text
help get help on commands
initcmd initialize the program
It is not obvious to the user how to get the command usage for the
program, nor that the initcmd subcommand to "initialize the program" is
actually is a placeholder to run the program.
Instead, display the command usage when help is requested and initcmd is
the only defined subcommand for a program.
For example:
$ xstat_cm_test -help
Usage: src/xstat/xstat_cm_test [initcmd]
-cmname <Cache Manager name(s) to monitor>+
-collID <Collection(s) to fetch>+ [-onceonly]
[-frequency <poll frequency, in seconds>]
[-period <data collection time, in minutes>] [-debug] [-help]
Where: -onceonly Collect results exactly once, then quit
-debug turn on debugging output
The libcmd library now supports an "noopcode", which should used for
future subcommand-less programs, but converting old programs to remove
the initcmd opcode could break scripts which actually specify the
optional initcmd token.
This commit adds a new libcmd flag called CMD_IMPLICIT which is used to
denote built-in subcommands such as "version" and "help".
Reviewed-on: https://gerrit.openafs.org/10983 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 77ae3dc899e89f327328c874628f100a765846c4)
Change-Id: I5b31f12f844f14e6cf31ee28c1eb60c98fcf4b59
Reviewed-on: https://gerrit.openafs.org/13894 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 2 Aug 2019 16:31:13 +0000 (10:31 -0600)]
restorevol: replace snprintf with asprintf
GCC is generating format-truncations warnings. With newer levels of gcc
(e.g. gcc8) and --checking-enabled these warnings result in errors and
failed builds. In addition clang8 static analysis tools are reporting
memory leaks.
Replace snprintf with asprintf and eliminate some of the large work
buffers that are being placed on the stack. In order to correct some of
the format-truncation errors the size of the buffers grew significantly
(e.g. gcc is reporting the need to resize some of the buffers from 256
bytes to 4K in order to eliminate the warnings).
Ensure allocated work buffers are freed before function return.
Obtained a clean build with gcc9/clang8 with --enable-checking and a
clean scan-build report with clang8.
Reviewed-on: https://gerrit.openafs.org/13494 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit bf24b301a10dcb5710a98e58252213bd72c6f352)
Change-Id: If9fa37613841ffd090ec565dc24171bf89579c5b
Reviewed-on: https://gerrit.openafs.org/13750 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 1 Mar 2019 15:46:32 +0000 (08:46 -0700)]
bos: remove smail-notifier
smail-notifier is a sample program that is undocumented and has not
been well maintained. It produces copious compiler warnings, and
would require effort to bring the code up to decent coding practices.
The bosserver provides a -notifier feature that can be used for
notifications, but that feature does not depend on this sample program.
Removed the code, cleaned up the Makefiles and .gitignore.
Reviewed-on: https://gerrit.openafs.org/13509 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 6e988a5b3900fe73c314c9960d6fb7753ff98411)
Change-Id: I073a2b772f894e321bd0b41e012229c8e6d3105c
Reviewed-on: https://gerrit.openafs.org/13738 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Tue, 1 Oct 2019 18:14:41 +0000 (12:14 -0600)]
LINUX 5.3: Add comments for fallthrough switch cases
With commit 6e0f1c3b45102e7644d25cf34395ca980414317f (LINUX: Honor
--enable-checking for libafs) building libafs against a linux 5.3
kernel compiles with errors due to fall through in case statements when
--enable-checking / --enable-warning is used.
e.g.
src/opr/jhash.h:82:17: error: this statement may fall through
[-Werror=implicit-fallthrough=]
case 3 : c+=k[2];
~^~~~~~
The GCC compiler will disable the implicit-fallthrough check for case
statements that contain a "special" comment ( /* fall through */ ).
Add the 'fall through' comment to indicate where fall throughs are
acceptable.
This commit only adds comments and does not alter any executable code.
The -Wimplicit-fallthrough flag was enabled globally in the linux kernel
build in 5.3-rc2 (commit: a035d552a93bb9ef6048733bb9f2a0dc857ff869
Makefile: Globally enable fall-through warning)
Reviewed-on: https://gerrit.openafs.org/13881 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a455452d7ee98d160620925bb8a0e3d0f4dfd7ec)
Andrew Deason [Wed, 3 Jul 2019 17:55:53 +0000 (12:55 -0500)]
LINUX: Unlock page on afs_linux_read_cache errors
When afs_linux_read_cache is called with a non-NULL task, it is
responsible for unlocking 'page' (unless it's unlocked in a background
task), even if we encounter an error. Currently we almost always do
unlock the given page for a non-NULL task, but if we manage to hit one
of the codepaths that 'goto out', we skip over the unlock_page() call
near the end of the function, and the page never gets unlocked.
As a result, the page stays locked forever. That generally means any
future access to the same file will block forever, and when we try to
flush the relevant vcache, we will block waiting for the page lock
while holding GLOCK. (This can happen via the background daemon via
e.g. afs_ShakeLooseVCaches -> osi_TryEvictVCache -> afs_FlushVCache ->
osi_VM_FlushVCache -> vmtruncate -> ... -> truncate_inode_pages_range
-> __lock_page on Linux 2.6.32-754.2.1.el6.) This quickly brings the
whole client to a halt until the machine can be forcibly rebooted.
To solve this, just move the 'out:' label to before the page unlock.
Add a few locking-related comments around the relevant code to help
explain some relevant details.
The relevant code has changed and been refactored over the years, but
this problem has probably existed ever since this code was originally
converted to using the readpage() of the underlying cache fs, in
commit 88a03758 (Use readpage, not read for fastpath access).
Reviewed-on: https://gerrit.openafs.org/13672 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit eed79e2d28dcab889d01869e57dec14fd30d421c)
LINUX: Avoid re-taking global lock in afs_dentry_iput
“dput” function internally can call dentry_iput which results in
calling afs_dentry_iput. So in case before calling “dput” if global lock
was held then when afs_dentry_iput is called it will again try to lock
global lock and will result in deadlock scenario. So to avoid this
deadlock make sure if global lock is already taken before calling
afs_dentry_iput, don’t try to lock it again. This issue was partially
fixed in commit 0dac4de8 (Linux: drop GLOCK before calling dput)
Reviewed-on: https://gerrit.openafs.org/13725 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5792e0211be275cf79d10e8c5f6ab2a14493e07a)
Change-Id: I4a17700adb18956fc61462663fdb690b267cc928
Reviewed-on: https://gerrit.openafs.org/13748 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> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 1 Oct 2018 15:56:53 +0000 (11:56 -0400)]
afs: Free 'addrs' array
Currently, 3 places in libafs allocate an 'addrs' array in a very
similar way to loop through our list of servers:
ForceAllNewConnections(), afs_LoopServers(), and PCallBackAddr(). Of
these, only afs_LoopServers actually frees the array.
ForceAllNewConnections and PCallBackAddr leak the memory, but these
are only hit from infrequent pioctls that can only be run by root, so
the impact is small.
Fix ForceAllNewConnections and PCallBackAddr to free the array.
Reviewed-on: https://gerrit.openafs.org/13355 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0548ee436d0f0f92a980d22e03149faedf38dc70)
Change-Id: I5d64899c7be40ba3e1b0985c4829933eebbd8323
Reviewed-on: https://gerrit.openafs.org/13899 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 26 Sep 2019 18:35:51 +0000 (13:35 -0500)]
rx: Fix test for end of call queue for LWP
Commit 6ad3d646 (rx: Correctly test for end of call queue) fixed a
broken end-of-queue check in rx_GetCall, but it only fixed the
RX_ENABLE_LOCKS version of rx_GetCall. The non-locks version (i.e. the
LWP version) still had this bug. Fix it for the LWP case, to avoid
some rare cases where an Rx call can get stuck in the incoming queue.
Also remove the comment added by commit 170dbb3c (rx: Use opr queues),
since we're fixing the mentioned problem.
Reviewed-on: https://gerrit.openafs.org/13880 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d9fc4890f01a41fa5a63f97f2446b3afc35b473f)
Change-Id: I2e0106b63a8bf09634500944490dfae2e86c18b9
Reviewed-on: https://gerrit.openafs.org/13892 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Fri, 9 Aug 2019 14:59:44 +0000 (07:59 -0700)]
The interminable rework of afs_random()
Commit f0a3d477d6109697645cfdcc17617b502349d91b restructured the
operation on tv_usec to avoid using undefined behavior, but in
the process introduced a behavior change. Historically (at least as
far back as AFS-3.3), we masked off the low nybble (four bits) of
tv_usec before adding the low byte (eight bits) of the rxi_getaddr()
output. Why there was a desire to combine two sources of input for
the overlapping four bits remains unclear, but restore the historical
behavior for now, as the intent of commit f0a3d477d6109697645cfdcc17617b502349d91b was to not introduce any
behavior changes.
Reviewed-on: https://gerrit.openafs.org/13759 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 1c4e94da2a8fce9d79006ad6d6673d3d7de117d3)
Change-Id: Iec10673e5ec73c1e0edcc231690cb6133fce8691
Reviewed-on: https://gerrit.openafs.org/13879 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>
Benjamin Kaduk [Sun, 3 Feb 2019 01:45:31 +0000 (19:45 -0600)]
rework afs_random() yet again
clang 7 notes that ~0 is signed and that left-shifting into the sign
bit is undefined behvaior. Use a new construction to clear the low
byte of tv_usec with only bitwise operations that are independent of
the width of tv_usec and stay within the realm of C's defined behavior.
Reviewed-on: https://gerrit.openafs.org/13474 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 f0a3d477d6109697645cfdcc17617b502349d91b)
Change-Id: I4f0438c2fc8237968f41409ca23ac098839508fe
Reviewed-on: https://gerrit.openafs.org/13743 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>
Benjamin Kaduk [Sun, 3 Feb 2019 00:39:53 +0000 (18:39 -0600)]
Avoid incomplete function type in casts
clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void). Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.
Reviewed-on: https://gerrit.openafs.org/13473 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 96c0b88947c7aab605170bdca633d3716051a58e)
Change-Id: I950ff8de925a1ca03e50ad7ec394123445b5ce4a
Reviewed-on: https://gerrit.openafs.org/13742 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 1 Feb 2019 22:31:50 +0000 (16:31 -0600)]
Avoid calling krb5_free_context(NULL)
Several places in the code currently call krb5_free_context(ctx) in a
cleanup code path, where 'ctx' may or may not be NULL. This is not
guaranteed to be okay, so check for NULL to make sure we don't cause
issues in these code paths.
While we are here cleaning up krb5_free_context() calls, also fix a
few call sites in afscp_util.c that were not calling krb5_free_context
in all error paths.
Reviewed-on: https://gerrit.openafs.org/13461 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 26b1dc036719a588a5cadecb14053bd4079c1f48)
Change-Id: I3b0d22f51f4fe85897116b7f96d096570258eed2
Reviewed-on: https://gerrit.openafs.org/13902 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 9 Aug 2019 19:25:26 +0000 (13:25 -0600)]
vlserver: initialize nvlentry elements after read
Commit 7620bd33487207b348ed7aeba45f8d743132ba84 (vlserver: fix
vlentryread() for old vldb formats) leaves the tail end of the
serverNumber, serverParition and serverFlags arrays uninitialized since
it only copies OMAXNSERVERS elements into arrays that have NMAXNSERVERS
elements.
Initialize the elements in the nvlentry server arrays that were not
copied with BADSERVERID.
Reviewed-on: https://gerrit.openafs.org/13755 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ddf7d2a7f4bfdcab238e791cb8c49bb803e76b09)
Change-Id: I4e1065bedda0f50b85cf472d015f2c86e4af82c8
Reviewed-on: https://gerrit.openafs.org/13846 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 20:23:03 +0000 (14:23 -0600)]
vlserver: fix vlentryread() for old vldb formats
When we're using old format compatibility, use OMAXNSERVERS for the
array lengths instead of MAXNSERVERS. Otherwise we'll try to copy more
data than we've read.
Detected by gcc8 as:
vlutils.c:183:2: error: ‘memcpy’ forming offset [149, 151] is out of the bounds [0, 148] of object ‘tentry’ with type ‘struct vlentry’ [-Werror=array-bounds]
memcpy(nbufp->serverFlags, oep->serverFlags, NMAXNSERVERS);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vlutils.c:141:26: note: ‘tentry’ declared here
struct vlentry *oep, tentry;
^~~~~~
Reviewed-on: https://gerrit.openafs.org/13465 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 7620bd33487207b348ed7aeba45f8d743132ba84)
Change-Id: I7dc4ad48805c6a82dd021d156fe187dd97e5b456
Reviewed-on: https://gerrit.openafs.org/13734 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning. With --checking-enabled, this error is causing
uss_procs.c to fail during compile.
A file name with the full path is being composed and the size of the
buffer was triggering a possible format-overflow warning/error.
Use asprintf to allocate the buffer dynamically instead of using a
buffer sitting on the stack (reducing the stack requirements by 2K).
Produces new error message if asprintf returns an error.
Reviewed-on: https://gerrit.openafs.org/13664 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 41ee558329560bce037ad2860282d8b49aa11b2d)
Change-Id: I5c5866142ae17c92017201fb567f847b5c2907a0
Reviewed-on: https://gerrit.openafs.org/13729 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>