pool/openafs
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6fab3d252e
openafs/ChangeLog
Christof Hanke 9e626f9fc0 Accepting request 910047 from home:hauky:branches:filesystems 
- update to openafs version 1.8.8 
- remove linux-kmp.patch. Not required at the minute.

OBS-URL: https://build.opensuse.org/request/show/910047
OBS-URL: https://build.opensuse.org/package/show/filesystems/openafs?expand=0&rev=82
2021-08-04 07:22:38 +00:00

5841 lines
255 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

commit 8c307b42f0b0b80bcf69de09031991d2ab776ed9
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Thu Jun 17 17:03:16 2021 +0200
Make OpenAFS 1.8.8
Update version strings for the 1.8.8 release
Change-Id: I8dc5b309ab17890410825caa329e536f14430d6b
Reviewed-on: https://gerrit.openafs.org/14642
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 40a209edeeb984ab20b35cde666dac087bfc5eb0
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Thu Jun 17 16:59:56 2021 +0200
Update NEWS for OpenAFS 1.8.8
Finalize the release notes for the 1.8.8 release.
Change-Id: I01b4527f708fbc8a733b3aa7754274c94683cb92
Reviewed-on: https://gerrit.openafs.org/14641
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>
commit 270bb0998f149485e4ae251fce802d8e80794e7c
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Thu Jul 15 17:27:10 2021 +0200
Make OpenAFS 1.8.8pre2
Update version strings for the second 1.8.8 prerelease.
Change-Id: Ie920e12fde0bc5043273d6dfceceaa1a4705ea3a
Reviewed-on: https://gerrit.openafs.org/14699
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 67e7662714a39d00d77b7689c3457fdcc689f160
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Thu Jul 15 21:09:12 2021 +0200
Update NEWS for 1.8.8pre2
Release notes for the second 1.8.8 prerelease.
Change-Id: I178d09bfa6c8d24b129cfdf92d4a4fb641518087
Reviewed-on: https://gerrit.openafs.org/14700
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit d15cd1c8cfd431617ff29e9b83e79d82e1fa0d58
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jun 4 10:18:39 2021 -0600
cf: Resolve implicit function definition for memset
The autoconf function OPENAFS_HAVE_STRUCT_FIELD can produce a compiler
warning for an implicit function definition for memset, however with
macOS 11 (Big Sur) the default compiler flags have been changed
(-Werror=implicit-function-declaration) so that this is now flagged as an
error. As an error this can lead to an incorrect result returned by
OPENAFS_HAVE_STRUCT_FIELD.
Add an include for <string.h> to provide the necessary definition for
memset.
Note, both gcc and clang can produce the implicit function definition
warning.
Reviewed-on: https://gerrit.openafs.org/14631
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fd5aa52ef8ce719502f970ab93ffde07d7ed4780)
Change-Id: I6829f13ee2fb1698738e95b379928cfea383e348
Reviewed-on: https://gerrit.openafs.org/14668
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 6fbbc7b579dc21b9229c24b1d0d577f7a7bd14fa
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jun 17 17:15:13 2021 -0500
afs: Free pioctlToken in extractPioctlToken
Ever since it was introduced in commit 5ec5ad5 (New GetToken pioctl),
extractPioctlToken has incorrectly freed pioctlToken by passing
'&pioctlToken' to xdr_free (instead of 'pioctlToken').
This causes xdr_ktc_tokenUnion to interpret &pioctlToken (which is a
struct ktc_tokenUnion **) as a struct ktc_tokenUnion *. This doesn't
cause any corruption or panics, since ktc_tokenUnion doesn't contain
any freeable fields unless its at_type is 2 (AFSTOKEN_UNION_KAD). So
as long as the bogus 'at_type' from the misinterpreted pointer is not 2,
the xdr_free call will just not free anything (and return an error,
which we ignore).
If the bogus at_type is 2, this would probably cause some memory
corruption or other nastiness. For this to happen on 32-bit systems,
the value of the 'pioctlToken' pointer itself would need to be 0x2.
On 64-bit systems, the top or bottom 32-bits of the pointer would need
to be 0x2 (depending on endianness). Those situations seem impossible
or very unlikely on most systems, and have never been seen in the
wild.
FIXES 135238
Reviewed-on: https://gerrit.openafs.org/14651
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit 966d5eb58f1f4fb333f263f018429c3a782be344)
Change-Id: Ied9b6c42106fa2c4353cccd08e1a6b50190a8504
Reviewed-on: https://gerrit.openafs.org/14667
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
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: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5abea9b8b1164f203fe18b5abe7d64ac8cb514eb
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Tue Jun 22 20:02:18 2021 -0400
bos: Let xdr allocate rpc output strings
The bos client provides fixed sized buffers on the stack for RPC output
strings instead of letting xdr allocate output strings. Unfortunately,
the fixed sized buffers do not account for the terminating nul char when
the output string is the maximum size defined for the bozo RPCs.
To avoid potential buffer overflows, and to allow for larger xdr string
sizes in the future, convert these to xdr allocated strings. Be sure to
always free the xdr allocated strings.
The following bozo RPCs have xdr output strings, and are addressed in
this commit:
BOZO_EnumerateInstance
BOZO_GetCellHost
BOZO_GetCellName
BOZO_GetInstanceInfo
BOZO_GetInstanceParm
BOZO_GetInstanceStrings
BOZO_GetStatus
BOZO_ListSUsers
Thanks to Cheyenne Wills for pointing out this issue.
Reviewed-on: https://gerrit.openafs.org/14650
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9ae5b599c7289a6f3ea2b03f2646402da182bb5d)
Change-Id: If8b23bbee3db83d65b7c7532fd47f3b5a16c424c
Reviewed-on: https://gerrit.openafs.org/14666
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 6484bc7d5aa2dd15ed0fc6dbf7a3ddcf071f7dad
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Tue Oct 6 00:02:53 2020 -0400
bos: do not assume fs just if dafs bnode is stopped
If dafs is configured but stopped, 'bos salvage <fs> <vicep>
-forceDAFS' will fail with:
bos: failed to get instance info for 'fs' (no such entity)
bos: shutting down 'fs'.
bos: can't stop 'fs' (no such entity)
This is due to incomplete logic in IsDAFS, introduced with commit
e46f10a0a0a930f318833a8a86b10c19744160c1 'bos: Do not assume DAFS just
if DAFS bnode exists'
Add logic to IsDAFS to work correctly when dafs is configured but
stopped.
Reviewed-on: https://gerrit.openafs.org/14382
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 48df3ac30210056ec046b48c28aee425b0690f92)
Change-Id: Ib55b9e322f529d120f424813c21af133ca2e6acc
Reviewed-on: https://gerrit.openafs.org/14665
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 0b55780042d8f856c33ad7a97c65825e3ddee5b7
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Thu Jul 1 20:14:12 2021 -0400
libadmin: Be sure to free the server list in ListCellsRPC
Commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc added a check to avoid
overrunning a buffer when the cell name returned by RXAFSCB_GetCellServDB
is too large for the libadmin buffer, but in that case missed freeing
the server list returned in the same rpc.
Move the xdr_free() of the server list under the cleanup label so the
server list returned by the RPC will always be freed.
Thanks to Mark Vitale for finding this bug.
Reviewed-on: https://gerrit.openafs.org/14690
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a5c146116faccc9891ae6d50506cd43d52dadb70)
Change-Id: Ic310d8d940588db2c966130a1e7b0a9543dd5e23
Reviewed-on: https://gerrit.openafs.org/14698
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 00423e6920fba66ce4ce7ab746210825830aae5b
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri May 21 12:38:01 2021 -0400
libadmin: Let xdr allocate rpc output strings
In most functions, the libadmin library provides fixed sized buffers for
RPC output strings instead of letting xdr allocate the output string.
Unfortunately the fixed sized buffers do not account for the terminating
nul char when the output string is the maximum length possible for the
xdr output strings.
To avoid potential buffer overflows, and to allow for larger xdr string
sizes in the future, convert these to xdr allocated strings and use safe
string functions to copy the results to the application buffers. Fail
with an error if the application buffer is too small, instead of
overflowing the buffer or truncating results.
Thanks to Cheyenne Wills for pointing out this issue.
Reviewed-on: https://gerrit.openafs.org/14626
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc)
Change-Id: Ia477d68ec62558470ae27544c86c340a7d2b7235
Reviewed-on: https://gerrit.openafs.org/14664
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5b557f37ade19c0eb7073ee39808a16cf9508fd5
Author: Andrew Deason <adeason@sinenomine.net>
Date: Wed Aug 21 11:48:53 2019 -0500
afs: Update style in afs_tokens.c
Fix a few style nits and other minor edits in afs_tokens.c. Mark a few
functions 'static' that are not referenced outside of that file.
Reviewed-on: https://gerrit.openafs.org/13806
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 1d2a1002bd1bc8d82c05399c06836ede83f9eeea)
Change-Id: I85b263674477e63cdc72d4dd9b4f714611b71d7e
Reviewed-on: https://gerrit.openafs.org/14663
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: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c978f92cbf9306c0b12eec68cd64ebac045c65e6
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Tue Jun 30 22:53:33 2020 +0200
Make OpenAFS 1.8.8pre1
Update version strings for the first 1.8.8 prerelease.
Change-Id: Ia7468e6ae5ec93a81e13dda55842ec57135c2a03
Reviewed-on: https://gerrit.openafs.org/14264
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
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: Stephan Wiesand <stephan.wiesand@desy.de>
commit e9cc2c3c71eba2f5a1b1be1f5d4198385b681d5c
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Fri Feb 19 21:51:15 2021 +0100
Update NEWS for 1.8.8pre1
Release notes for the first 1.8.8 prerelease.
Change-Id: I04762b28b3cc5528f31c2b5d8f1d7f906e46f62f
Reviewed-on: https://gerrit.openafs.org/14540
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit f0283af65e81a4bc9aa4fa44eb8a4a45c6a0448e
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu May 27 11:02:01 2021 -0600
afscp: Link against opr/roken/hcrypto
Link afscp against libopr, libroken, and libafshcrypto, so afscp can
be built again.
Reviewed-on: https://gerrit.openafs.org/13656
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4eeed830fa31b7b8b5487ba619acbc8d30642aaa)
Change-Id: I73264df34743dcb6a8f6232267892ee602a76053
Reviewed-on: https://gerrit.openafs.org/14627
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit d7900532e3e7897f8030a6ed31abff4ec0d32ebf
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Fri Jan 29 01:30:47 2016 -0500
afs: free the Buffers array correctly during shutdown
DInit() allocates 'Buffers' with afs_max_buffers = 4*nbuffers
worth of buffer structs to allow for run-time expansion.
But shutdown_bufferpackage() free 'Buffers' as if it only had
nbuffers worth of buffer structs.
Correct the size of Buffers passed to afs_osi_Free().
Discovered during Solaris shutdown testing with kmem_flags=x0f.
This bug is not Solaris-specific, but it may be symptomless on other
platforms.
Introduced by commit e7c966354c428a5a5929a3db6a829ee71c8ba2fc 'Flexible
client buffer growth'; this only affected cold shutdowns (afsd
-shutdown).
After commit 2336164d1bf63980419d3a870f908f1f384fdfc0 'afs: Actually
free resources during warm shutdown', this bug also affects warm
shutdowns (the default when /afs is unmounted).
Reviewed-on: https://gerrit.openafs.org/12183
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit d1c944ec167b8845d703a6b6a8d9492751056b98)
Change-Id: I612b33a3788d2c9a0c39c5cb22a3473f8e1c01e1
Reviewed-on: https://gerrit.openafs.org/14616
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5cfee79d9a12e67720906cc5a985f7c12064db41
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 21 17:02:34 2019 -0500
afs: Actually free resources during warm shutdown
Currently, the shutdown_*() code paths for several subsystems only
free the memory for that subsystem for "cold" shutdowns, and not for
"warm" shutdowns. This means the memory gets leaked during a "warm"
shutdown, since we never free these resources anywhere else.
Specifically, this happens in shutdown_bufferpackage, shutdown_AFS,
and shutdown_osinet.
To avoid these leaks for warm shutdowns, just move the
afs_cold_shutdown check around a little, so we free the relevant items
in either codepath.
Reviewed-on: https://gerrit.openafs.org/13716
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2336164d1bf63980419d3a870f908f1f384fdfc0)
Change-Id: I1d2360ea777b7a7488e599b6e707c98295d8fbdd
Reviewed-on: https://gerrit.openafs.org/14615
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 4d03c0cac0abe575ccf1a74078c3338245690462
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Jul 30 16:42:19 2020 -0400
vol: ensure ih package defaults are set for salvage
Like most OpenAFS components that work with ihandles, salvager relies on
implicit invocation of ih_PkgDefaults via the one-shot in the first call
to IH_INIT.
Unfortunately, there is at least one reachable code path in salvager
that asserts (panics) because vol_io_params has not yet been
initialized. This is when salvaging a volume group that does not have a
link table; the salvager then panics while attempting to create a new
link table:
SalvageFileSys -> SalvageFileSys1 -> DoSalvageVolumeGroup ->
CreateLinkTable -> IH_CREATE -> namei_icreate -> icreate ->
namei_SetLinkCount -> FDH_SYNC -> ih_fdsync -> osi_Assert(0)
This path was discovered while testing the non-dafs salvager, but it has
also been observed in the field with the DAFS salvageserver. It is
possible that there are additional undiscovered paths where
vol_io_params are required but uninitialized.
Add an implicit ih_PkgDefaults call to icreate to avoid triggering the
assert via the code path above.
Reviewed-on: https://gerrit.openafs.org/14378
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9d65bcf8833a826a74fc433777599380cd5b03b9)
Change-Id: I8c7fb5acbaf2d84b290ce95e11a7baf0421b920d
Reviewed-on: https://gerrit.openafs.org/14614
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 90e54b2a2010b4620b007ea5c8d3a5a7cbc30069
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Fri Oct 9 16:28:15 2020 -0400
vol: move ih_PkgDefaultsSet check inside ih_PkgDefaults
Instead of repeating the oneshot check in each caller of ih_PkgDefaults,
move the oneshot check into ih_PkgDefaults itself.
While here, ensure that ih_PkgDefaults does its work under IH_LOCK.
Finally, make ih_PkgDefaultsSet a local static variable (no longer
exported).
Reviewed-on: https://gerrit.openafs.org/14383
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 896524963ca1f1d8144a668dafefc8ce88ad440b)
Change-Id: I179640df6e0a5fd6b9a97b57cfde6377213e1d14
Reviewed-on: https://gerrit.openafs.org/14613
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 1b794441fe2c7d3c22ca92135035b5ebe826431f
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Oct 1 17:13:51 2020 -0400
afsd: remove unused variable afs_shutdown
Since the original IBM code import, the variable afs_shutdown has been
set but never read.
Remove it from the code base.
No functional change is incurred by this commit.
Reviewed-on: https://gerrit.openafs.org/14380
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0761bb7c58260985fbbfcf477d597da3c5d64fc5)
Change-Id: I35d657fb93b9e6f611d91d5a374899249cec5b88
Reviewed-on: https://gerrit.openafs.org/14612
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 553270ec9e02fc36bdb59924344fa4f470ee20cc
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Jan 28 23:38:59 2016 -0500
afs: remove duplicate declaration for afs_shutdown()
Somehow there were two. Now there is but one.
Reviewed-on: https://gerrit.openafs.org/12181
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 3e2fe677a2d3b9f76644175f3a59d392872b87f3)
Change-Id: I19a2f0ebe2c79fd32800cc388e488fa11fd8f0ce
Reviewed-on: https://gerrit.openafs.org/14611
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7ebe9b70b994ba04d016a5bbf479f30934b7c632
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Jan 28 10:01:13 2016 -0500
afs: afsd -shutdown sets afs_cold_shutdown too soon
'afsd -shutdown' always invokes syscall(AFSOP_SHUTDOWN)
with parm2 set to 1 to indicate a "cold" shutdown.
(There are no other callers to AFSOP_SHUTDOWN).
AFSOP_SHUTDOWN sets global variable afs_cold_shutdown
based on the value of parm2. Then it checks to see if
AFS is still mounted; if so, we return early with EACCES.
However, global afs_cold_shutdown remains set.
Therefore, the next successful 'umount' after a "failed"
'afsd -shutdown' will always trigger a "cold" shutdown.
This is contrary to the intent of the current implementation,
which is to perform a "warm" shutdown upon 'umount' for
most platforms. (Exceptions: AIX, OBSD, NBSD always
specify a cold shutdown upon 'umount').
This bug would never be noticed on the "cold" exception
platforms, but on the "warm" platforms the inconsistency
of seeing an unexpected "COLD" shutdown may be confusing
and surprising.
Make shutdown operation more self-consistent by modifying
AFSOP_SHUTDOWN to defer setting of afs_cold_shutdown until
after the mount test.
Reviewed-on: https://gerrit.openafs.org/12180
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c72ec68bcea646aa3e0395ad103afb2ee9ba9cde)
Change-Id: I7b40728bcb56c9bb0d86912f140fed315e93bf64
Reviewed-on: https://gerrit.openafs.org/14610
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit de668dbafb55682a209f71cb1d09b5084d0c2af1
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Fri Apr 9 15:14:52 2021 +0000
macos: delegate sock_* calls to bkg daemons
As part of Apple's ongoing effort to modernize macOS, improve security
and reliability, the deprecation of kernel extensions was officially
announced at WWDC19. According to this announcement, Kernel programming
interfaces will be deprecated as alternatives become available, and
future OS releases will no longer load kernel extensions that use
deprecated KPIs by default.
Unfortunately, the following KPIs, extensively used by rx, are included
in the list of deprecated KPIs as of macOS 10.15:
- sock_receivembuf
- sock_close
- sock_send
- sock_socket
- sock_setsockopt
- sock_bind
To workaround this problem, delegate calls to the functions mentioned
above to bkg daemons forked by afsd. Notice that the ifadd_* and ifnet_*
functions are also deprecated. Fortunately, these calls can be avoided
enabling AFS_USERSPACE_IP_ADDR.
Thanks to Andrew Deason for his assistance (ideas, suggestions,
documentation, etc).
Reviewed-on: https://gerrit.openafs.org/14431
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 70e5c4f6a45854ae3a4241568769279747a8b76f)
Conflicts:
src/config/afs_args.h
Change-Id: I4370c0aa3978f208c763ed43c3cc5567ee74e730
Reviewed-on: https://gerrit.openafs.org/14600
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7f7ff82c0ab57ee23f19c3ea783ab8ebf23ca045
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Aug 14 15:53:20 2018 -0500
afs: Add AFS_USPC_SHUTDOWN bkg request
When AFS_NEW_BKG was added, the kernel module indicated to the
relevant afsd process that it's time to shutdown by returning -2. This
works on DARWIN, but it's difficult to make this work on all
platforms, because of the different way that platforms handle error
codes from our pioctls and other AFS syscalls.
Specifically, on LINUX, negative error codes are assumed to be
negative errno codes, and so returning -2 from the syscall handler
means we return -1 to userspace, with errno set to 2 (ENOENT).
Getting this to work consistently across platforms is probably more
trouble than its worth, so instead of relying on specific return codes
from the syscall, just add a new background daemon operation called
AFS_USPC_SHUTDOWN, which just tells the background daemon to exit.
Reviewed-on: https://gerrit.openafs.org/13281
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 397199a1992d74d8b7e693a2d76df836f7a70080)
Change-Id: Ib809a27476f49baef70dcbcc749eed95a4de8d2f
Reviewed-on: https://gerrit.openafs.org/14605
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit a80e04a9eb6fb6b3d4cffce0a682931f63efc933
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Thu Jan 28 15:49:25 2021 -0800
macos: packaging support for MacOS X 11.0
This commit introduces the new set of changes / files required to
successfully create the dmg installer on OS X 11.0 "Big Sur".
Reviewed-on: https://gerrit.openafs.org/14430
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 40c6f3aa5576d7e1ac23caff1ae4ffd69e74dc44)
Change-Id: I55bab1631c41fdb636fa84359f2d76d4bfc2b6a1
Reviewed-on: https://gerrit.openafs.org/14598
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 3ea37d57106901e8d4e82537dcee3609f1ef2c1e
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Thu Jan 28 14:45:10 2021 -0800
macos: add support for MacOS 11.0
This commit introduces the new set of changes / files required to
successfully build the OpenAFS source code on OS X 11.0 "Big Sur".
While here, refactor the code that checks if the "-Xlinker -kext"
system-specific linker option is needed.
Reviewed-on: https://gerrit.openafs.org/14429
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit acc955bc17e1a1e10f634e7017c1323954f07b31)
Change-Id: Ie5b791c7444612c617eeb3b16e1165510fe9f251
Reviewed-on: https://gerrit.openafs.org/14597
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c7a8bf889ddacf1935282da14e06abf0e63999f7
Author: Andrew Deason <adeason@dson.org>
Date: Fri Dec 20 22:09:35 2019 -0600
rx: Indent ifdef maze in rx_kcommon.c
Reviewed-on: https://gerrit.openafs.org/13997
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 08c769967ca12f1ac99c736789f1925763d8a115)
Change-Id: I75d5ec5c9f75f79817adec3f259e546e79fc3629
Reviewed-on: https://gerrit.openafs.org/14599
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit efac54c67d527fb8a4fa118f53fc55ad75c7d2ff
Author: Andrew Deason <adeason@dson.org>
Date: Fri Dec 20 21:51:18 2019 -0600
afs: Indent ifdef maze in afs_server.c
Reviewed-on: https://gerrit.openafs.org/13996
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2a8db42664cc450c2db097fe19472fe7876203df)
Change-Id: Iff5bb059ea7005c4f174401b9daa45f1ae6d092d
Reviewed-on: https://gerrit.openafs.org/14604
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7550806b15b3347c70520b23d5f7f59665e8d4a0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Thu Mar 18 08:28:22 2021 -0600
bozo: Fix the test for bosserver '-cores none'
The check for the '-cores none' parameter is incorrect resulting in the
parameter to be taken as a directory path.
Update the string comparison.
Reviewed-on: https://gerrit.openafs.org/14559
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 000fe6b7e6e7bf140c7cca7becc8fb7e8006fec7)
Change-Id: I45ac645bb7cdd6f3cd1dfd81d6ccdc9cda4547a8
Reviewed-on: https://gerrit.openafs.org/14589
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 3c19cf40f4016931accc97c555bc5b623b838e96
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Dec 7 14:42:54 2020 -0500
vol: always build vol-bless utility
In order to avoid future bit-rot, always build vol-bless. Also add it
to the clean rule. However, continue to leave it undistributed and
uninstalled by default.
Reviewed-on: https://gerrit.openafs.org/14464
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1efa4e49f2dabe2f3a1ef235e21a96ae9d5ff6bf)
Change-Id: I62b2f192e2bcb24221c94468e2e72aaa567568d4
Reviewed-on: https://gerrit.openafs.org/14601
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 91a298cc1fb93ffa8766f291b5a1c7ab29ad6f84
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Dec 7 14:40:33 2020 -0500
vol: add vol-bless to .gitignore
No functional change is incurred by this commit.
Reviewed-on: https://gerrit.openafs.org/14463
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 986ee6a0a70d70f366baeb43670eb367f0525b97)
Change-Id: I1819537c8ac26101a81100871f85a6de78408cea
Reviewed-on: https://gerrit.openafs.org/14602
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit b6c9bf43988d5945e502be1c9455adc791539a72
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Dec 7 13:13:28 2020 -0500
vol: make vol-bless buildable again
The vol-bless utility is not built by default and so is subject to
bit-rot. Thus commit 170dbb3ce301329ff127bb23fb588db31439ae8d 'rx: Use
opr queues' overlooked vol-bless.c when adding includes for users of
struct rx_queue.
Add the required #include <rx/rx_queue.h> so vol-bless builds again.
Note to maintainers: this change is only required for 1.8.x and later;
vol-bless builds fine in 1.6.x and earlier releases.
Reviewed-on: https://gerrit.openafs.org/14462
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e1f20287a4d0cd80c6bfe7309b907fe5a4ac1464)
Change-Id: I1f9acb176758bd34b7f63d5ebde54e9af191ad77
Reviewed-on: https://gerrit.openafs.org/14603
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 67385e65cbdb41a8b2895a7fe1d637c7b899ef5c
Author: Tim Creech <tcreech@tcreech.com>
Date: Thu Oct 29 21:29:10 2020 -0400
FBSD: Add support for FreeBSD 12.2
Reviewed-on: https://gerrit.openafs.org/14474
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 96ebee44c322934b9eda1bab5907ee87b03d571f)
Change-Id: I95dedbee8b67a2bb05a8bb3614045fa3a49f9a11
Reviewed-on: https://gerrit.openafs.org/14590
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c58313fc4f1c04e1d3f94f53b966516b2560e4c2
Author: Tim Creech <tcreech@umd.edu>
Date: Mon Dec 9 21:13:58 2019 -0500
FBSD: Add support for FreeBSD 12.1
Reviewed-on: https://gerrit.openafs.org/13982
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 71ce9fff8e682a77e17490a54e091656cbf96925)
Change-Id: I4214101d314cac6d677a08f760ccf990a4441306
Reviewed-on: https://gerrit.openafs.org/14537
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 4b14b60afbf28f5fcf325ee378a26657f7780254
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Tue Aug 18 13:56:26 2020 +0000
bos: suppress unnecessary warn if -noauth
Commit d008089a7 (Add interface to select client security objects)
consolidated the code that selects the client security objects into a
set of new interfaces. Before this commit, the "bos: running
unauthenticated" message, which warns the user when an unauthenticated
connection is established, used to be suppressed if the -noauth flag was
specified.
Similarly to commit b3c16324e (ubik: Make ugen_ClientInit honor
noAuthFlag), recover the original behavior avoiding warn messages about
unauthenticated connections if the -noauth flag is provided.
Reviewed-on: https://gerrit.openafs.org/14306
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d5f0e16ac44475be55a7cc3e2895fc4a3a923ece)
Change-Id: Id78494c2a189f2e99e25111200cabde32a4add2b
Reviewed-on: https://gerrit.openafs.org/14546
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c747b15dd2877e6d17e3e6b940ae78c1e1ccd3ea
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Mar 5 16:31:03 2021 -0700
Linux 5.12: Add user_namespace param to inode ops
The Linux commits:
"fs: make helpers idmap mount aware" (549c72977) and
"attr: handle idmapped mounts" (2f221d6f7) that were merged into
Linux-5.12-rc1 cause a build failure when creating the kernel module.
Several functions within the inode_operations structure had their
signature updated to include a user_namespace parameter. This allows
a filesystem to support idmapped mounts.
OpenAFS only implements some of the changed functions.
LINUX/vnodeops function inode_operation
===================== ===============
afs_notify_change setattr
afs_linux_getattr getattr
afs_linux_create create
afs_linux_symlink symlink
afs_linux_mkdir mkdir
afs_linux_rename rename
afs_linux_permission permission
Update the autoconf tests to determine if the Linux kernel requires
the user_namespace structure for inode_operations functions. If so,
define a generic "IOP_TAKES_USER_NAMESPACE" macro.
Update the above vnodeops functions to accept a 'struct user_namespace'
parameter.
When using the 'setattr_prepare' function a user namespace must be
now provided. In order to provide compatibility as a non-idmapped mount
filesystem the initial user namespace can be used. With OpenAFS, the
initial user namespace obtained at kernel module load time is stored in
a global variable 'afs_ns'.
Update the call to setattr_prepare to pass the user namespace pointed
to by the 'afs_ns' global variable.
Update calls to setattr to pass the user namespace pointed to by
the 'afs_ns' global variable.
Notes:
The changes introduced with Linux 5.12 allow a filesystem to support
idmapped mounts if desired. This commit does not implement support for
idmapped mounts, but will continue to use the same initial user
namespace as prior to Linux 5.12.
With Linux 5.12 the following autoconf checks fail:
HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS
HAVE_LINUX_SETATTR_PREPARE
IOP_CREATE_TAKES_BOOL
IOP_GETATTR_TAKES_PATH_STRUCT
IOP_MKDIR_TAKES_UMODE_T
The new macro 'IOP_TAKES_USER_NAMESPACE' covers the cases where these
macros where used.
Reviewed-on: https://gerrit.openafs.org/14549
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 1bd68506be3243c5670aaf53798b2e4e715d4c8b)
Change-Id: I8cd54042da4e0295f3cf8417c84138bb0458f881
Reviewed-on: https://gerrit.openafs.org/14565
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5a5d358b02b88d6d2c7a27a75149e35b1de7db38
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Mon Mar 8 09:22:04 2021 -0700
Linux: Create wrapper for setattr_prepare
Move call to setattr_prepare/inode_change_ok into an osi_compat.h
wrapper called 'afs_setattr_prepare'. This moves some of the #if logic
out of the mainline code.
Reviewed-on: https://gerrit.openafs.org/14548
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 12ae2beeeb172cebdfa24d5ea149f73fd85541f8)
Change-Id: I1c7806893daf2404a8b3ac1b5c88ca04e6409226
Reviewed-on: https://gerrit.openafs.org/14564
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit cdec210405afb47ee338bfde9280710b64d7abc6
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Jul 23 13:50:31 2019 -0500
LINUX: Introduce afs_d_path
Move our preprocessor logic around d_path into an osi_compat.h
wrapper, called afs_d_path. This just makes it a little easier to use
d_path, and moves a tiny bit of #ifdef cruft away from real code.
Reviewed-on: https://gerrit.openafs.org/13721
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 4c4fb6e36634e5663c8be25acd4a1ac872e4738c)
Change-Id: I08763c71006e4ac6f2bf88d8ac71941fc44e6ab8
Reviewed-on: https://gerrit.openafs.org/14563
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8cdd8ad84006b17bfe243b004f0c4191c7df3af5
Author: Andrew Deason <adeason@dson.org>
Date: Sun Apr 12 22:28:29 2020 -0500
tests: Skip SIGBUS test on FreeBSD
Currently, 'softsig-helper -buserror' causes a SIGBUS on most
platforms, but can result in SIGSEGV on FreeBSD by default (at least
on 11.3-RELEASE). Skip the test on FreeBSD, until we can provide a
more reliable way to generate SIGBUS.
Note that when the sysctl machdep.prot_fault_translation is set to 1,
'softsig-helper -buserror' generates a SIGBUS instead of SIGSEGV,
suggesting that generating a SIGBUS here is the old 'compat' behavior.
When machdep.prot_fault_translation is 0 (the default), the code path
in the FreeBSD kernel that dictates whether to send a SIGBUS or
SIGSEGV in this situation depends on some autodetection heuristics,
and so may produce different results depending on FreeBSD releases or
even compiler settings (due to detection of ABI based on some ELF
notes in the relevant binary).
For some details on this sysctl, see
<https://www.freebsd.org/news/status/report-2019-07-2019-09.html#Signals-delivered-on-unhandled-Page-Faults>
or the FreeBSD source code. In 11.3-RELEASE, the decision to issue a
SIGBUS or SIGSEGV can be found around sys/amd64/amd64/trap.c:355.
Reviewed-on: https://gerrit.openafs.org/14145
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit df5480057c2994914e22bd14b169dbcd8857485a)
Change-Id: Ifd2c17c52a7a9be7a8a09776cf15500fdc9ca62d
Reviewed-on: https://gerrit.openafs.org/14536
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5c1aa944d73e20272fa886e46ba0d4e69c54e8db
Author: Andrew Deason <adeason@dson.org>
Date: Sun Sep 8 16:10:40 2019 -0500
FBSD: Remove MA_* abstractions
In FBSD/osi_vnops.c, we have a few abstractions (e.g. MA_VOP_UNLOCK)
that used to expand to different things for older FreeBSD versions.
Currently, they always expand to the same thing, so just remove the
abstractions.
While we are changing these calls, also change one instance of
MA_VOP_LOCK to vn_lock (instead of VOP_LOCK), since we're not usually
supposed to call VOP_LOCK directly, according to the VOP_LOCK(9)
manpage. The MA_VOP_LOCK call was added in commit bd707fb7
(freebsd-almost-working-client-20020216), seemingly by mistake.
Reviewed-on: https://gerrit.openafs.org/13843
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 7260c7164b9a2199c7b5f83279fa18af16e7d387)
Change-Id: I831e798546da97eeba923965c24dd79be14a9b89
Reviewed-on: https://gerrit.openafs.org/14535
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit b03f8b684077c9224fe059abf8c316739096e0cd
Author: Tim Creech <tcreech@umd.edu>
Date: Fri Dec 13 22:24:57 2019 -0500
FBSD: Build vnode_if.h before libafs objs
Currently, if we are building with -j2 or higher, we can easily fail
to build some libafs objects because vnode_if.h does not exist yet.
vnode_if.h is generated by the FreeBSD build, but none of our objects
depend on it, so during parallel builds it may not be available by the
time we build, for example, src/external/heimdal/hcrypto/sha256.c.
This results in build errors that can look like this:
--- sha256-kernel.o ---
cc -I. -I.. -I../nfs [...]/src/external/heimdal/hcrypto/sha256.c
In file included from [...]/src/external/heimdal/hcrypto/sha256.c:34:
In file included from [...]/src/crypto/hcrypto/kernel/config.h:30:
In file included from [...]/src/afs/sysincludes.h:354:
/usr/src/sys/sys/vnode.h:588:10: fatal error: 'vnode_if.h' file not found
#include "vnode_if.h"
^~~~~~~~~~~~
1 error generated.
*** [sha256-kernel.o] Error code 1
make[4]: stopped in [...]/src/libafs/MODLOAD
1 error
To avoid this, make all of our libafs objects depends on vnode_if.h.
[adeason@dson.org: Expanded commit message.]
Reviewed-on: https://gerrit.openafs.org/13983
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0ee53d2fe9341e60f420662749d5ae8c6d4b5f24)
Change-Id: I85696c23aeeabf8ebc38c8a9ea320fdcf8141ad9
Reviewed-on: https://gerrit.openafs.org/14534
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8825b5346f67f2193e770d524d4524b2ff16d84a
Author: Tim Creech <tcreech@tcreech.com>
Date: Sun Mar 5 18:15:58 2017 -0500
FBSD: Remove LOCKPARENT/ISLASTCN lookup logic
Currently, our afs_vop_lookup on FBSD tries to only lock 'dvp' for
ISDOTDOT requests when LOCKPARENT and ISLASTCN are set. There are a
couple of problems with this:
- The conditional locking logic involving LOCKPARENT/ISLASTCN is only
relevant in very old FreeBSD releases (per-fs checking of these
flags for parent locking went away around the FreeBSD 6 era).
- Our current logic here is wrong anyway, since we try to lock 'dvp'
twice when those flags are set. This was mostly introduced by commit
2f6be821 (FBSD: band-aid vnode locking in lookup), which added a
lock/unlock pair for 'dvp' around the lock for 'vp', even though
'dvp' was unlocked several lines earlier.
This means that if we hit the relevant code path, we will deadlock,
since we try to lock 'dvp' twice. To avoid this, just remove the
relevant logic for LOCKPARENT/ISLASTCN, since it is only relevant for
old FreeBSD releases that are not supported by us or FreeBSD.
Add and rearrange some comments around here to try to more explicitly
explain the relevant locking rules.
[adeason@dson.org: Commit message rewrite, adding comments, removing
old FreeBSD code.]
Reviewed-on: https://gerrit.openafs.org/12578
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 17a845c8d44f453b09b21afd59182e616234e872)
Change-Id: I105dfe397bb723b0939bb626103d857007e1a7bf
Reviewed-on: https://gerrit.openafs.org/14533
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 27268300531101748069741f9deaae5e160616a8
Author: Andrew Deason <adeason@dson.org>
Date: Sun Apr 12 22:40:14 2020 -0500
FBSD: Remove unused 'wantparent' logic
In afs_vop_lookup, the 'wantparent' variable doesn't actually change
any logic in the function. In the if() clause that it's used, the
value of 'wantparent' is only ever used if cnp->cn_nameiop is RENAME
and ISLASTCN is set. But if both of those are true, then the second
half of the if() conditional will always be true, so the value of
'wantparent' doesn't matter.
So to remove this confusing unused logic, remove the 'wantparent'
local var, and all its associated logic.
Issue spotted by kaduk@mit.edu.
Change-Id: Ia63b88d67d21cc2b81a0c25aa31ea60ab202b0a7
Reviewed-on: https://gerrit.openafs.org/14143
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7df5c003ed6eb17a693d67ffdfc0556f0c569cc1)
Reviewed-on: https://gerrit.openafs.org/14532
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fa25fb8f53f8a31556b6aa189becef5850cc068a
Author: Andrew Deason <adeason@dson.org>
Date: Sun Aug 18 19:59:50 2019 -0500
FBSD: Add support for FreeBSD 11.3
Reviewed-on: https://gerrit.openafs.org/13792
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7116de596a8f1d0be3da6eebe92d486f57aefd02)
Change-Id: I9bbf3a72041dda4220b63963b6fc9bd8bd2342e8
Reviewed-on: https://gerrit.openafs.org/14531
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ed6170582ce6fc9fc501349aa98ccc726c04501b
Author: Andrew Deason <adeason@dson.org>
Date: Sun Dec 1 15:39:04 2019 -0600
FBSD: Declare vnops/vfsops static
Declare our vnode and vfs operations as static functions, since they
are not referenced outside of osi_vfsops.c/osi_vnodeops.c. Shuffle
around the definitions in osi_vnodeops.c so that we don't need forward
declarations for the functions.
Reviewed-on: https://gerrit.openafs.org/13973
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 37c5db3ce767868803135c916b282ff2e541d052)
Change-Id: I8817e0e2a02bc4211dc84c0d9f8b418de756120e
Reviewed-on: https://gerrit.openafs.org/14530
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 60f3f689c4a0bd152e1c5a2fe660a3c59933491e
Author: Andrew Deason <adeason@dson.org>
Date: Sun Aug 25 23:21:23 2019 -0500
FBSD: Remove pre-8 code
Commit 123f0fb1 (config: remove support for old FreeBSD releases)
removed our support for FreeBSD releases before FreeBSD 8. However,
various areas of code still reference the symbols from those old
versions (e.g. AFS_FBSD53_ENV). Remove our ifdef logic for these old
symbols, according to the following rules:
- In FBSD-specific dirs, assume AFS_FBSD80_ENV is always true (as well
as the symbols for earlier versions)
- In non-FBSD dirs, convert AFS_FBSD80_ENV to AFS_FBSD_ENV (and do the
same for all earlier versions)
This allows us to remove code that was specific to older FreeBSD
versions, and simplify some ifdef conditionals.
Also remove the definitions for AFS_FBSD80_ENV and earlier versions in
our existing param.h files.
With this commit, the functions afs_start, afs_vop_lock,
afs_vop_unlock, and afs_vop_islocked are now always unreferenced, so
remove them.
Reviewed-on: https://gerrit.openafs.org/13812
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 847b63af92dd527de31675a0c3c82c9a57e6c4b3)
Change-Id: Icaaf660a95084a358d1ddf6fbc63944eff90492f
Reviewed-on: https://gerrit.openafs.org/14529
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit dcda95f388426e6bf6ace5f86905f0cf695e8413
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jun 23 17:48:53 2019 -0500
libafs: Create debug KMODDIR for FBSD debug inst
Commit 99418024 (libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst)
made it so we create the kmod installation dir before copying our
module into it. However, if we build a 'debug' variant of our module,
the FreeBSD build process also installs debug symbols in a different
directory, ${DESTDIR}${KERN_DEBUGDIR}${KMODDIR}, which may not exist.
So do the same thing for that dir too, if --enable-debug-kernel is
turned on, so the build still works.
To do this, introduce the LIBAFS_REQ_DIRS var, to make it easier to
keep track of which dirs we may need to create.
Reviewed-on: https://gerrit.openafs.org/13690
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit 3bc03e7a5f8ef521e71a30cb8e66e07e2d1b4605)
Change-Id: Idee5614e92b99bd1140a3cef971537fb68eec151
Reviewed-on: https://gerrit.openafs.org/14528
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 44d7a30657d8b507e5d382c68b8411b8437c2af2
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 14 17:31:30 2019 -0500
FBSD: Use ucontext for FreeBSD 10+ on amd64
Currently, running any LWP program on recent FreeBSD on amd64 causes
(or can cause) a SIGBUS very quickly. This is possibly because our
stack management code in LWP only ensures our stacks are 4 or 8-byte
aligned in most cases (except DARWIN, which gets 16-byte-aligned
stacks), according to the value of STACK_ALIGN. The amd64 ABI mandates
that stacks be 16-byte-aligned, and some function calls assume that
this is followed, causing a SIGBUS when it is not. FreeBSD on amd64
currently uses process.amd64.s for its savecontext() implementation,
which does not do any checking or fixup of the stack alignment.
This behavior has been observed on amd64 with FreeBSD 11 specifically,
but it probably happens on any FreeBSD release when using clang.
FreeBSD switched to clang as the default compiler with FreeBSD 10, so
this probably occurs with FreeBSD 10 and newer.
We could perhaps try to fix this by changing our stack management
code, but we can also avoid most of this nonsense by just using
ucontext instead of our custom assembly code. So, do that, by setting
USE_UCONTEXT for FreeBSD 10+. Also enable the same 'stackvar'-based
workaround in savecontext() as Linux uses, since otherwise 'topstack'
appears to always be NULL, and triggers our stack overflow checks.
Note that while LWP use is deprecated, as of this commit many small
utilities (like 'fs') are still linked to LWP, and so are unusable
without a fix like this.
Reviewed-on: https://gerrit.openafs.org/13691
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0a39efee224e8d4431ae79281ca353a7ba6fdce4)
Change-Id: I8cb4c20eb32c12310f41e38a3f40b132c919bace
Reviewed-on: https://gerrit.openafs.org/14527
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 56ec046f0137b217a55ff40cc66363c36b7e5c21
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 28 15:03:43 2019 -0500
FBSD: Set KERNBUILDDIR for --with-bsd-kernel-build
Currently, specifying --with-bsd-kernel-build during configure causes
us to set BSD_KERNEL_BUILD, which sets KBLD in MakefileProto.FBSD.in,
but nothing ever uses KBLD. This means that when we use
--with-bsd-kernel-build, we don't actually build against the
configuration for that kernel, which can result in a libafs.ko that
cannot be loaded or causes other errors. Specifically, if trying to
build for a VIMAGE kernel, the kernel complains when trying to load
libafs:
[...] kernel: link_elf_obj: symbol in_ifaddrhead undefined
[...] kernel: linker_load_file: Unsupported file type
The FreeBSD module build system looks for KERNBUILDDIR for an
alternative build, which it uses to pull in opt_global.h and other
required pieces from the build tree. So just specify KERNBUILDDIR if
we have one.
At the same time, avoid setting our default value for BSD_KERNEL_BUILD
for FBSD when the calculated dir doesn't exist. At least for the
default GENERIC kernel on FreeBSD 11.2-RELEASE, there may not be a
build dir on the running machine, and so setting BSD_KERNEL_BUILD to
the calculated value causes the build to fail when it doesn't exist.
Reviewed-on: https://gerrit.openafs.org/13746
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8f9c92a888df7b2fd61a3e84aaf1d2c96a8b10dd)
Change-Id: I7afc54121ac3a9d81a7a8005d53eb2ed5df489c1
Reviewed-on: https://gerrit.openafs.org/14526
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit be3b02e7dee78f492090e89746167116e4f221fd
Author: Tim Creech <tcreech@tcreech.com>
Date: Sun Mar 5 18:18:01 2017 -0500
FBSD: Call CURVNET_SET/CURVNET_RESTORE for VIMAGE
In commit 9703b023 (FBSD: VIMAGE support), we changed a couple of our
variable references to their V_* equivalents, to accommodate kernels
with VIMAGE turned on. This allows us to build, but causes us to crash
whenever we hit that code when VIMAGE is enabled, because the relevant
macros reference 'curvnet', which is NULL outside of networking code.
What we're supposed to do is to set 'curvnet' before entering
networking code by calling 'CURVNET_SET(xxx)', and reset it afterwards
by calling 'CURVNET_RESTORE()'. We must make exactly one _RESTORE call
for each _SET, and they are supposed to be run at the same level of
scope.
So to avoid the crashes, make the relevant CURVNET_* calls whenever we
look at networking info. We currently only do this in a few places:
- In afs_SetServerPrefs, to try to detect if a given server address is
in the same network as one our local interfaces (V_in_ifaddrhead)
- In rxi_GetIFInfo, for some MTU-related info (V_ifnet)
- In rxi_FindIfnet, for some MTU-related info (ifa_ifwithnet)
As for what vnet we actually set 'curvnet' to, we could set it to the
vnet of the current thread (TD_TO_VNET(curthread)), or we could set it
to the vnet of an associated network object (a socket, an interface,
etc). Since all of our network-related code goes through Rx, in this
commit we set curvnet to the vnet of the Rx socket
(rx_socket->so_vnet).
Note that VIMAGE is optional in 11-RELEASE, but is turned on by
default in 12.0-RELEASE. For more information, see:
https://wiki.freebsd.org/VIMAGE/porting-to-vimage
[adeason@dson.org: Reworded commit message; moved some code around.]
Reviewed-on: https://gerrit.openafs.org/12580
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1effc3517fdb4b4653d47c59bf67076567209324)
Change-Id: I5fd8b2bf204790b1da6427fe72b8743a7aaa4f13
Reviewed-on: https://gerrit.openafs.org/14525
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 642f9776c28933ac2769ef9ea67d316dd1c6cff5
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 14 22:53:39 2019 -0500
FBSD: Remove unnecessary explicit osi_fbsd_alloc
AFS_KALLOC is already defined to be osi_fbsd_alloc on FBSD, so this
extra #ifdef here is completely unnecessary. Remove it.
Do the same for AFS_KFREE/osi_fbsd_free.
Reviewed-on: https://gerrit.openafs.org/13708
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit ad1fe5e1a825a3b3f88c04fd84613e4105206443)
Change-Id: Ib62b52d040ffd4170a0bb556684244ee1f372401
Reviewed-on: https://gerrit.openafs.org/14524
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7a5f648e0ac84ecb6321752be5334e16b1b5051e
Author: Andrew Deason <adeason@dson.org>
Date: Sat Jul 20 23:09:27 2019 -0500
FBSD: Give 0 'rootrefs' to vflush on unmount
Currently, in afs_unmount, we give vflush a 'rootrefs' arg of 1,
indicating that we hold 1 reference on the root vnode. But ever since
commit 6eb1088a (freebsd: properly track vcache references), we drop
the ref for the root vnode at the beginning of this function.
What happens currently in afs_unmount for a normal successful umount
is something like this (at least, on FreeBSD 11.2-RELEASE):
- We afs_PutVCache the afs_globalVp vcache, reducing its v_usecount
and v_holdcnt to 0, and afs_globalVp is set to NULL.
- vflush calls afs_root() to get the root vnode, which sees that
afs_globalVp is NULL, and so calls afs_GetVCache for the root fid
and returns it (and sets afs_globalVp to that vcache), with a
v_usecount of 1.
- vflush tries to vgonel() all of our vnodes, which calls our
afs_vop_reclaim, which calls afs_FlushVCache(). For the root vnode
specifically, vflush() sees that v_usecount is nonzero, and so skips
calling vgonel() at first, but later calls vgone() on it
specifically because we gave a nonzero 'rootrefs'. The resulting
afs_FlushVCache() for the root vnode fails, because the root vnode's
v_usecount is still 1. Since a failure from afs_vop_reclaim would
cause a panic, we just log a warning and try to continue on anyway.
- vflush() calls vrele() on the root vnode, right before returning.
All of this allows the unmount to proceed, but this means that most of
afs_FlushVCache() doesn't actually run for the root vcache, and it
means we always log a warning like this on unmount:
afs_vop_reclaim: afs_FlushVCache failed code 16 [...]
In addition, this means that setting afs_globalVp at the beginning of
afs_unmount() is largely pointless, since it gets set to a vcache
again near the beginning of vflush().
To avoid all of this, stop lying to vflush about how many references
to the root vnode we hold, and just say that we hold 0 references.
Reviewed-on: https://gerrit.openafs.org/13709
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d13b647aa392e1d802be1023930a8e1a07fb11ab)
Change-Id: I7ca79ee5c10277d6ef94b5f317aa4ba091642ffd
Reviewed-on: https://gerrit.openafs.org/14523
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit a4f5adb0cdc8493603f51422501b4a45b9e26c7f
Author: Tim Creech <tcreech@tcreech.com>
Date: Sun Mar 5 18:17:23 2017 -0500
FBSD: Handle F_UNLCK in VOP_ADVLOCK
When a_fl->type is F_UNLCK, FreeBSD gives our VOP_ADVLOCK an a_op of
F_UNLCK, instead of F_SETLK like we expect. This causes afs_lockctl to
return EINVAL, since F_UNLCK isn't a normal fcntl lock op, and so
userspace requests to unlock fcntl-style locks always fail. This can
be seen, for example, when trying to use sqlite3 to access a database
that lives in afs.
This F_UNLCK behavior in FreeBSD seems a bit peculiar, but has been
around effectively forever (since 4.4BSD-Lite). So just work around
it.
[adeason@dson.org: minor style adjustments and commit message/comment
rewording.]
Reviewed-on: https://gerrit.openafs.org/12579
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f5acf1b1bfe940faf0a6f4bd11c55d6c90f60242)
Change-Id: I52d0c513aeabd54019fc6d7bb6c3b542e95b2dee
Reviewed-on: https://gerrit.openafs.org/14522
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 908be3fadb642578f1fb331d229910b386e559c9
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jun 23 17:48:53 2019 -0500
libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst
We rely on bsd.kmod.mk for our actual rules during 'make install', but
that tries to install our kernel module into $(DESTDIR)$(KMODDIR),
without creating it first. If the user tries to 'make install
DESTDIR=/some/path' and that path doesn't exist, we will fail with
something like:
make DESTDIR=/home/adeason/git/destdir single_instdir_libafs
/usr/bin/install -c -T release -o root -g wheel -m 555 libafs.ko /home/adeason/git/destdir/boot/modules/
install: /home/adeason/git/destdir/boot/modules/: No such file or directory
*** Error code 71
To avoid this, add a dependency on the 'install' target which causes
our target dir to be created.
Reviewed-on: https://gerrit.openafs.org/13653
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 99418024276c94da5982d7dad6126a8d53924d7e)
Change-Id: I439b7b9514b3ab060c887003e0af19557fd2c812
Reviewed-on: https://gerrit.openafs.org/14521
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8d0651efeb11b248a2d1b9a00b97c2de9724c3d1
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date: Fri Mar 22 12:46:17 2019 +0100
Add param.h files and sysnames for FreeBSD 11.2
Thanks to Måns Nilsson for filing the bug. Note that this change
differs from the proposed patch in the report, in that it
doesn't define the 10.4 symbols in the 11.2 param.h files.
FIXES 134850
Reviewed-on: https://gerrit.openafs.org/13534
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 2ee35afa339731f6a60f1e5e99ccaf63baa6c891)
Change-Id: I6ba8ba41df12f1a5977f5b530aa1353902de5ebe
Reviewed-on: https://gerrit.openafs.org/14520
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>
commit b7bddcf63339a15d0e4c5cd0d56b3b44c428ed54
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Tue May 31 16:23:41 2016 -0400
SOLARIS: provide cache manager stats via kstat
Provide statistical information via the solaris kstat framework. Data
can be examined with the kstat tool or the kstat userspace api.
The kstat module is called openafs. Three kstat names are provided. The
"param" name provides cache manager parameters as given by the cmdebug
-cache program.
# kstat -m openafs -n param
The "cache" name provides cache manager statistics as given by the
xstats plus some additional cache related stats. The "cache" name also
provides the libafs kernel module version string and the current local
cellname.
# kstat -m openafs -n cache
The "rx" name provides general rx statistics as given by rxdebug -rxstat.
# kstat -m openafs -n rx
Reviewed-on: https://gerrit.openafs.org/13170
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9338cb5fce2e38b864b8f957b6ea4c56c78d20f8)
Change-Id: Ic70d766d7a112d673b6c5898da43b3eea11b1065
Reviewed-on: https://gerrit.openafs.org/14518
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 4d768b764dbba492805d9e4a4af8474e1f7e0d2e
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Aug 9 17:40:09 2018 -0400
afs: consolidate duplicated wait-for-cache-drain code
Consolidate duplicated logic into a new routine
afs_MaybeWaitForCacheDrain().
Reviewed-on: https://gerrit.openafs.org/13278
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 23bd776b0140deb596287869872a41de555ba99a)
Change-Id: I31b04da2170dcdf795b8a50ea7ab78d964eeebf5
Reviewed-on: https://gerrit.openafs.org/14517
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit afa3802d065375f32876e150588cbce3b88c61e3
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Mon Jun 20 15:29:45 2016 -0400
afs: more cache truncation stats
Add counters for cache too full and waiting to drain occurrences. These
will be used in later commits to indicate how often the cache truncation
is required and how often the cache manager is waiting for cache
truncation to complete.
Reviewed-on: https://gerrit.openafs.org/13168
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 25792e246362a201743533a970f90dbc77d0ed5c)
Change-Id: I659cce58951c869ce40ff47b13aa79ab33cd26aa
Reviewed-on: https://gerrit.openafs.org/14516
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit eee6a0cddcd31dafb1c67b3cf909496c232bca09
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Aug 20 16:09:02 2020 -0400
vol: prevent salvage segfault for orphaned vnode with out-of-range parent
While salvaging a RW volume, salvager may segfault if it encounters an
orphaned directory with a parent vnode that does not exist. For
example, if the large vnode index contains a maximum vnode of 2901, any
parent vnode encountered that is larger than 2901 will result in an
out-of-bounds reference to our vnode essence array, leading to a
segfault or undefined behavior.
Modify the logic to check for out-of-bounds parent vnodes, and log them
rather than segfaulting.
Reviewed-on: https://gerrit.openafs.org/14385
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 750628da77bb71e24ed3061431bbb913ff8d5f72)
Change-Id: Ib0cabde440d59394704967dd3ab2eb73f07aec22
Reviewed-on: https://gerrit.openafs.org/14515
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 9e608659f67da53213f376623526638bc10743e5
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Fri Apr 20 00:57:28 2018 -0400
rx: prevent leakage of non-cached rx_connections (pthread)
The rxi_connectionCache (AFS_PTHREAD_ENV only) allows applications to
reuse rx_connection structs. Cached rx_connections are obtained via
rx_GetCachedConnection and released via rx_ReleaseCachedConnection.
This feature is used most heavily by libadmin and kauth, but there are
other users in the tree as well.
For instance, ubikclient routines ubik_ClientInit and ubik_ClientDestroy
call rx_ReleaseCachedConnections (if AFS_PTHREAD_ENV) when disposing of
their rx_connections. Unfortunately, in many cases these rx_connections
were obtained via rx_NewConnection, _not_ from the cache via
rx_GetCachedConnection. In those cases, rx_ReleaseCachedConnection will
not find the rx_connection in the rxi_connectionCache, and thus it
returns without doing anything.
Therefore, when ubik_ClientInit is passed an existing ubik_client (for
re-initialization) that contains rx_connections NOT allocated via
rx_GetCachedConnection, those connections are not destroyed, but will be
silently leaked. Similarly, ubik_ClientDestroy will leak its
rx_connections when it frees the ubik_client struct.
For example, the fileserver host package calls ubik_ClientInit (via
hpr_Initialize) and ubik_ClientDestroy (via hpr_End) to manage
connections to the ptserver. However, these connections were obtained
via rx_NewConnection, not rx_GetCachedConnection. If the fileserver has
a failed call to the ptserver that sets prfail=1, the next RPC scheduled
for that client (in CallPreamble) will refresh the thread's ubik_client
(viced_uclient_key) by calling hprEnd -> ubik_ClientDestroy ->
rx_ReleaseCachedConnection. The "released" connections will be leaked.
This problem exists in all versions of OpenAFS going back to IBM 1.0.
Starting with 1.8.x, many components that were formerly LWP-only are now
pthreaded and thus susceptible to this leak.
It seems difficult and error-prone to identify all possible code paths
that may pass a non-cached rx_connection to rx_ReleaseCachedConnection,
and convert them to obtain connections via rx_GetCachedConnection.
Instead, prevent all existing and future leaks by modifying the connection
cache to:
- flag all rx_connections it allocates
- correctly release any rx_connection it is passed, whether they came
from the cache or not.
Reviewed-on: https://gerrit.openafs.org/13042
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit bb5397e4c409e3c075ee73d6bf54a3b6eacc0060)
Change-Id: Ia48e29a53a83211c1011eba24c16f78f7253d84b
Reviewed-on: https://gerrit.openafs.org/14514
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 1e5496856b71dca6cc2fd0e54ea8dea4444e3867
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Apr 30 18:34:28 2018 -0400
rx: fix out-of-range value for RX_CONN_NAT_PING
Commit 496fb87372555f6acddd4fd88b03c94c85f48511 ("rx: avoid nat ping
until connection is attached") introduced functionality to defer turning
on NAT ping for server connections until after reachability had been
established for the client.
Unfortunately, this feature could never work correctly because it
assigned an out-of-range flag value of 256 (0x100) for the u_char flags
field. Instead of calling this out as an error, both gcc and Solaris cc
elide this flag so that it is never set in
rx_SetConnSecondsUntilNatPing(), Furthermore, the test in
rxi_ConnClearAttachWait() will always fail; therefore
rxi_ScheduleNatKeepAliveEvent is never called after attach wait has
ended.
Fortunately, this bug is currently moot - not actually exposed in
OpenAFS. (It was discovered by inspection). This is because there are
currently no rx_connection objects in the tree that have both NAT ping
and checkReach (rx_SetCheckReach) enabled. I also searched git history
and found no time when this bug could ever have been exposed. This does
raise the question of why the original commit was needed; but instead of
reverting the original commit, this commit attempts to fix it.
To prevent problems if NAT ping and checkReach are ever both enabled for
an rx_connection, enlarge the rx_connection flags member so that the
RX_CONN_NAT_PING value is no longer out of range.
Reviewed-on: https://gerrit.openafs.org/13041
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 55fca11421055d0bcee79f118ea2a035393cc6e5)
Change-Id: I9b02ff06d7bf6ba0dfa30ed5ca17ddb89b517987
Reviewed-on: https://gerrit.openafs.org/14513
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>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8453eada315a87ce8fa3cbd54abecb94ed99a947
Author: Andrew Deason <adeason@sinenomine.net>
Date: Wed Dec 23 12:44:35 2020 -0600
afs: Fix XBSD check for VNOVAL va_uid
Commit e86eb73e (obsd-vattrs-20040125) introduced an XBSD-specific
check to detect some unchanged attributes. But the #ifdef for XBSD for
the va_uid section was added in the middle of an HPUX-specific block
by mistake.
Move this #ifdef one level higher, so it's actually used on BSD
platforms.
Reviewed-on: https://gerrit.openafs.org/14473
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit cd35aa9e2aec16d622177eeea1e1b3ec8aacdd45)
Change-Id: I6a840cffc1e3dfc6df1237261aa3a21bb3b73fbc
Reviewed-on: https://gerrit.openafs.org/14512
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>
commit ee53dd3bc087a05e22fc4111297a51ddb30013f0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jan 22 07:57:55 2021 -0700
Linux 5.11: Test 32bit compat with in_compat_syscall
Linux 5.11 removed the TIF_IA32 thread flag with commit:
x86: Reclaim TIF_IA32 and TIF_X32 (8d71d2bf6efec)
The flag TIF_IA32 was being used by openafs to determine if the task was
handling a syscall request from a 32 bit process. Building against a
Linux 5.11 kernel results in a build failure as TIF_IA32 is undefined.
The function 'in_compat_syscall' was introduced in Linux 4.6 as
the preferred method to determine if a syscall needed to handle a
compatible call (e.g. 32bit application).
To resolve the build problem, use 'in_compat_syscall' if present (Linux
4.6 and later) to determine if the syscall needs to handle a
compatibility mode call.
Add autoconf check for in_compat_syscall.
Notes about in_compat_syscall:
In Linux 4.6 'in_compat_syscall' was defined for all architectures with
a generic return of 'is_compat_task', but allows architecture specific
overriding implementations (x86 and sparc).
At 4.6 (and later), the function 'is_compat_task' is defined only for
the following architectures to return:
Arch Returns
======= ==============================
arm64 test_thread_flag(TIF_32BIT);
mips test_thread_flag(TIF_32BIT_ADDR)
parisc test_ti_thread_flag(task_thread_info(t), TIF_32BIT)
powerpc is_32bit_task()
s390 test_thread_flag(TIF_31BIT)
sparc test_thread_flag(TIF_32BIT)
If the Linux kernel is not built with compat mode, is_compat_task and
in_compat_syscall is set to always return 0
Linux commit that introduced in_compat_syscall:
compat: add in_compat_syscall to ask whether we're in a compat syscall
(5180e3e24fd3e8e7)
Reviewed-on: https://gerrit.openafs.org/14499
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 78ef922612bef5f5fd6904896e84b9d2ea802404)
Change-Id: I4eca62f19ae58fd830915feff5098cec2825f099
Reviewed-on: https://gerrit.openafs.org/14511
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 4ad1057ab8fd206c9fa8d5e3bdde4f1a8417afdb
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jan 29 11:32:36 2021 -0700
Linux: Refactor test for 32bit compat
Refactor the preprocessor checks for determining the method to test for
32bit compatibility (64bit kernel performing work for a 32bit task) into
a common inline function, 'afs_in_compat_syscall' that is defined in
LINUX/osi_machdep.h. Update osi_ioctl.c and afs_syscall.c to use
afs_in_compat_syscall.
Add include afs/sysincludes into osi_machdep.h to ensure linux/compat.h
is pulled for the functions called in afs_in_compat_syscall.
Reviewed-on: https://gerrit.openafs.org/14500
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 32cc6b0796495e596262d84c428172a511f757c4)
Change-Id: I746e5777737d49381c4a74627b79d2a61cbd4f8e
Reviewed-on: https://gerrit.openafs.org/14510
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit aaa7043a154d35838e65bc28473355c452339bcc
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jan 28 16:59:47 2021 -0600
LINUX: Fix includes for fatal_signal_pending test
Commit 8b6ae289 (LINUX: Avoid lookup ENOENT on fatal signals) added a
configure test for fatal_signal_pending(). However, this check fails
incorrectly ever since Linux 4.11, because fatal_signal_pending() was moved
from linux/sched.h to linux/sched/signal.h in Linux commit 2a1f062a
(sched/headers: Move signal wakeup [...]). Fix this by including
linux/sched/signal.h if we have it during the configure test.
A false negative on this configure test doesn't break the build, but
it disables one of our safeguards preventing incorrect negative
dentries at runtime. The function fatal_signal_pending() hasn't
changed in quite some time (except for what header it lives in); it
was introduced in Linux 2.6.25 via Linux commit f776d12d (Add
fatal_signal_pending). So to try to avoid this mistake again in the
future, make it so a missing fatal_signal_pending() breaks the build
if we're on Linux 2.6.25+.
Reviewed-on: https://gerrit.openafs.org/14508
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0c1465e4f3310daa54f1e799f76237604222666d)
Change-Id: I1334c060f8ab5733461ebf7c191dffa7be830021
Reviewed-on: https://gerrit.openafs.org/14509
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 25d6d88dec67b3ab2a04a1f94baf04291fdb63d6
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Sep 19 12:18:08 2019 -0500
rx: Avoid new server calls for big-seq DATA pkts
We currently never open our receive window to more than 32 packets. If
we received a DATA packet for an unrecognized call with a seq of 33 or
more, the packet is almost certainly from a previously-running call
that we were restarted during.
As described in commit 7b204946 (rx: Avoid lastReceiveTime update for
invalid ACKs) and commit "rx: Avoid new server calls for non-DATA
packets", clients can get confused when we respond to calls in these
situations, so drop the packets instead.
Reviewed-on: https://gerrit.openafs.org/13876
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a36832e2d891caab8644a3b4641c7c94fab4105f)
Change-Id: I72f903b81a205bb3e64862da03f9c1c76cc37b75
Reviewed-on: https://gerrit.openafs.org/14507
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5bbbbe37ac7ffece710f55c471a34e5fc89543a8
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Thu Aug 8 18:18:22 2019 -0400
rx: Avoid new server calls for non-DATA packets
Normally, a client starts a new Rx call by sending DATA packets for
that call to a server, and rxi_ReceiveServerCall on the server creates
a new call struct for that call (since we don't recognize it as an
existing call).
Under certain circumstances, it's possible for a server to see a
non-DATA packet as the first packet for a call, and currently
rxi_ReceiveServerCall will create a new server call for any packet
type. The call cannot actually proceed until the server receives data
from the client (and goes through the challenge/response auth
handshake, if needed), but usually this is harmless, since the
existence of any packets for a particular call channel indicate that
the client is trying to run such a call. The server will respond to
the client with ACKs to indicate that it is missing the needed DATA
packet(s), and the client will send them and the call can proceed.
However, if a call is in the middle of running when the server is
restarted, the client may be sending ACKs for a pre-existing call that
the server doesn't know about. In this case, the server generates ACKs
that indicate the server has not received any DATA packets, which may
appear to violate the protocol, depending on the prior state of the
call (e.g. the server appears to try to move the window backwards).
Clients should be able to detect this and kill the call, but many do
not. For many OpenAFS releases before commit 7b204946 (rx: Avoid
lastReceiveTime update for invalid ACKs), the client will get confused
in this situation and will keep the call open forever, never making
progress.
There isn't any benefit to creating a new server call in these
situations, so just ignore non-DATA packets for unrecognized calls, to
avoid stalled calls from such clients. Those clients will not get a
response from the server, and so the call will eventually die from the
normal Rx call timeout.
Reviewed-on: https://gerrit.openafs.org/13758
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3f9a08db86f951df3f6f69f1143f17dd7b43b150)
Change-Id: Iaf8ee360f8aa634b5a7728866e41de267389e1f3
Reviewed-on: https://gerrit.openafs.org/14506
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit d5743ef92a92fe298d68ae4095bf4d4515971f7f
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Aug 27 22:58:23 2019 -0500
rx: Avoid lastReceiveTime update for invalid ACKs
Currently, we ignore ACK packets in a few cases:
- If the ACK appears to move the window backwards (if firstPacket is
smaller than call->tfirst).
- If the ACK appears to have been received out of order (if
previousPacket is smaller than call->tprev).
- If the ACK packet appears truncated.
In all of these cases, we ignore the ACK packet completely in our ACK
processing code (rxi_ReceiveAckPacket), but we still process the
packet at higher levels (rxi_ReceivePacket). Notably, this means we
update call->lastReceiveTime after rxi_ReceiveAckPacket returns, even
for ACK packets we haven't really looked at.
Normally this does not cause any noticeable problems, because such
packets should either never be encountered, or only consist of a small
number of packets that are mixed in with valid packets.
However, if our peer is a server, and it is restarted in the middle of
a call, our peer may exclusively send us packets that fall into the
above categories. (This does not happen if our peer is a client,
because clients just ignore packets for calls they do not recognize.)
For example:
Consider a call where a client is sending data to a server, and the
server restarts after the client has sent a DATA packet with sequence
number 1000. The server may then start responding to the client with ACKs
with firstPacket set to 1, since the restarted server has no knowledge
of the call's state.
In this case, a firstPacket of 1 is well below where our window was,
so all of the ACKs from the server are ignored. But we keep updating
call->lastReceiveTime for all of these packets, and so the call stays
alive forever until an idle-dead or hard-dead timeout activates (if
any are set).
As another example, consider the case where a client is sending data
to a server, and the server receives a full window of packets (say, 16
packets), has not yet passed any data to the application yet, and the
server restarts. The restarted server then starts responding to the
client with ACKs with firstPacket set to 1, and previousPacket set to
0. We also ignore all of the ACKs from the server in this case,
because even though firstPacket looks sane, it looks like
previousPacket has gone backwards. We still update
call->lastReceiveTime for each ignored ACK we get, keeping the call
alive.
Before commit 4e71409f (Rx: Reject out of order ACK packets) was
introduced in 1.6.0, neither of these issues could occur. That commit
introduced the issue specifically if previousPacket goes backwards;
that is, if the server restarts before firstPacket moves forwards.
Commit 8d359e6d (rx: Remove duplicate out of order ACK check) in 1.8.0
introduced the issue when 'firstPacket' goes backwards, since
previously the FIRSTACKOFFSET-based check caused us to ignore those
packets without updating call->lastReceiveTime. That is, if the server
restarts after firstPacket moves forwards.
In this commit, we still ignore packets in the above cases, but we
also avoid updating lastReceiveTime when we update such packets, to
make sure that we do not keep a call alive solely from receiving these
invalid packets.
Alternatively, we could change our logic to immediately abort calls
where firstPacket moves backwards (since this violates the Rx
protocol), or to not ignore some packets where previousPacket goes
backwards (since these calls may be recoverable). And we could also
skip updating lastReceiveTime for invalid packets of other types. But
for now, this commit just avoids updating lastReceiveTime for invalid
ACK packets, in order to just try to restore our behavior before
1.6.0, while still retaining the benefits of ignoring out-of-order
ACKs. Further changes in this area can potentially be handled
separately by future commits.
Also increment the spuriousPacketsRead counter for packets that we
ignore in this way (which we used to do for some packets before commit
8d359e6d), so we are not entirely silent about ignoring them.
Written in collaboration with mvitale@sinenomine.net.
Reviewed-on: https://gerrit.openafs.org/13875
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7b204946010673506e0f74991f59a0865292199c)
Change-Id: I8e0299bdeedb005fe49a2d1c4a00a21301fbbb04
Reviewed-on: https://gerrit.openafs.org/14505
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 49975e8b07c340cb675445015f41474dc39cd535
Author: Andrew Deason <adeason@sinenomine.net>
Date: Wed Aug 28 17:12:53 2019 -0500
rx: Introduce ack_is_valid
Take some of our existing logic for ignoring invalid ACK packets and
split it out into a separate function, ack_is_valid. This just makes
it easier to add more complex logic in here and write longer comments
explaining the decisions.
Note that the bug mentioned regarding the previousPacket field was
introduced in IBM AFS 3.5, and was fixed in OpenAFS in commit bbf92017
(rx: rxi_ReceiveDataPacket do not set rprev on drop), included in
OpenAFS 1.6.23.
This commit incurs no functional change; it is just code
reorganization.
Reviewed-on: https://gerrit.openafs.org/13874
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f6490629e1239c412002f316804c656c9be61400)
Change-Id: I5d0ee9b7fc56659e445705a01d5d90141eb8cfe2
Reviewed-on: https://gerrit.openafs.org/14504
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c32ad5017d48640ea7f6430f844324b3d7fd90b5
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Nov 2 13:52:25 2020 -0600
rx: For AFS_RXERRQ_ENV, retry sendmsg on error
When AFS_RXERRQ_ENV is defined, we currently end up doing something
like this for our sendmsg abstractions:
if (sendmsg(...) < 0) {
while (rxi_HandleSocketError(sock))
;
return error;
}
return success;
This means that when sendmsg() returns an error, we process the socket
error queue before returning an error.
The problem with this is that when we receive an ICMP error on our
socket, it creates a pending socket error that is returned for any
operation on the socket. So, if we receive an ICMP error after trying
to contact any peer, sendmsg() could return an error when trying to
send for any other peer. Even though there is no issue preventing us
from sending the packet, we'll fail to actually send the packet
because sendmsg() returned an error. This effectively causes an extra
outgoing packet drop, possibly delaying the related RPC.
To avoid this, change Rx to retry the sendmsg call when it returns an
error, since the error may be due to an unrelated ICMP error.
To avoid needing to implement this retry loop in multiple places, move
around our sendmsg code for AFS_RXERRQ_ENV, so that the higher-level
function rxi_NetSend performs the retry and checks for socket errors
(instead of the lower-level rxi_Sendmsg or osi_NetSend). Also change
our functions to process socket errors to be more consistent between
kernel and userspace: now we always have rxi_HandleSocketErrors, which
runs a loop around the platform-specific osi_HandleSocketError.
With this commit, osi_HandleSocketError is now required to be
implemented when AFS_RXERRQ_ENV is defined. We hadn't been
implementing this for UKERNEL, so just turn off AFS_RXERRQ_ENV for
UKERNEL.
Thanks to mbarbosa@sinenomine.net for discovering and providing
information about the relevant issue.
Reviewed-on: https://gerrit.openafs.org/14424
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 5c9234694543f206174d30e21886286d419fd8df)
Change-Id: I1b21ba4d2b98abae240cb683d6061462db028431
Reviewed-on: https://gerrit.openafs.org/14503
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit a6173b39a874d7cce3a826d7b4dce58ee6a48983
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Nov 2 13:16:41 2020 -0600
rx: Save errno in pthread rxi_Sendmsg
Currently, our pthread version of rxi_Sendmsg uses 'errno' in some
logic if sendmsg fails, but we do so after calling functions that
might alter errno (e.g. fflush).
To make sure we get the correct errno value, save the value of errno
right after sendmsg returns an error. Reorganize this function a bit
to help make the logic easier to follow.
Reviewed-on: https://gerrit.openafs.org/14423
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit eff7fa4b2eb9a3001dc18dca157ccbd5f19f89b6)
Change-Id: Ie761bf8fbf930718d933fdc2d0ad6961b2660607
Reviewed-on: https://gerrit.openafs.org/14502
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5b6ea9e9bd37d17b1cf29bb8ef377091ffccae69
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jan 9 12:38:45 2020 -0600
aklog: Make dummy write AIX-specific
This weird write() call exists to work around some old AIX-specific
bug. The ifdef looks like it is intended to restrict this to pre-5
AIX, but it also turns this on for all non-AIX platforms.
Make this area AIX-specific, to avoid this weird write on other
platforms that have nothing to do with the relevant workaround.
Reviewed-on: https://gerrit.openafs.org/14022
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6ee2d6de7d87c93c849f3afbe4326906e4c10852)
Change-Id: Iaa84f1c1df57f9b0749c2577e496fbf8740e48c1
Reviewed-on: https://gerrit.openafs.org/14483
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7d7b3f06bb72aa2969b164ff71d61d723628f52c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Aug 28 17:26:41 2019 +0530
aklog: avoid infinite lifetime tokens by default
Currently we get tokens for infinite lifetime using aklog impersonate
feature. Based on inputs from Ben, this was done for server to server
tickets to be valid forever. However on 1.8.x we have other
mechanisms that were usable for server-to-server authentication with
strong enctypes, so we do not need to provide user level akimpersonate
to generate tokens for infinite lifetime. For this we have added new
option -token-lifetime <hrs>, this can take values from 0 to 720
hours. If 0 is specified it means tokens will have infinite lifetime.
By default 10 hours will be token lifetime for akimpersonate tokens.
Reviewed-on: https://gerrit.openafs.org/13828
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1de602aaada15df1008140784092c2a76a2613a1)
Change-Id: I032431ab1b8b174ac8d80322b688dc2a7285b8fa
Reviewed-on: https://gerrit.openafs.org/14482
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 97400f8a8c1b5756f67cf5434a65faa9a5d3d22b
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Aug 28 17:04:31 2019 +0530
aklog: use any enctype in get_credv5
We currently always pass DES as the requested enctype to
get_credv5_akimpersonate, but this means we will fail to use our
service princ if we're using another enctype (say, AES) with rxkad-k5.
To allow this to work with any enctype, just don't pass any requested
enctypes, and just use the enctype inside the 'entry' returned to us
from krb5_kt_get_entry.
Remove all of the logic associated with the now-unused
"allowed_enctypes" argument. Also remove the logic handling the case
where "service_principal" is NULL (since no callers pass a NULL
service_principal), to make it easier to take out the allowed_enctypes
related code.
Reviewed-on: https://gerrit.openafs.org/13827
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 276bd5c7f8a2ec7673d2ad084566203eb2055938)
Change-Id: Ia4b2cab3b2cd81214683dc00d7092a302d5af1bd
Reviewed-on: https://gerrit.openafs.org/14481
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 93f21573642f01e906f6711bae13006cc708f0d3
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Aug 28 16:43:35 2019 +0530
aklog: retry getting tokens for KRB5_KT_NOTFOUND error
If we're creating tokens with -keytab and our AFS service principal is
afs@<cellname>, we'll first try creating tokens with
afs/<cellname>@<cellname> and krb5_kt_get_entry will fail with
KRB5_KT_NOTFOUND. Since we do not retry for KRB5_KT_NOTFOUND error, we
will not get tokens. So in order to get tokens for principal
afs@<cellname> we should retry for KRB5_KT_NOTFOUND error. Thanks to
jpjanosi@us.ibm.com for finding this issue and suggesting a fix.
Reviewed-on: https://gerrit.openafs.org/13826
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 7a13bce2513baf5a3a61db94f3d88232241cea5b)
Change-Id: I4f4dfb4c1372aef88a938d1b96d012a3f6bb4218
Reviewed-on: https://gerrit.openafs.org/14480
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 26c1720b2c18cdda1807424d96547342248aa64c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Aug 28 16:25:49 2019 +0530
aklog: Use HAVE_ENCODE_KRB5_ENC_TKT_PART for aklog impersonate
In get_credv5_akimpersonate we use HAVE_ENCODE_KRB5_ENC_TKT which is not
defined, due to this we always return -1 from this routine for non
Heimdal case. We have a another define i.e
HAVE_ENCODE_KRB5_ENC_TKT_PART which is defined if
encode_krb5_enc_tkt_part function is present. In current code
encode_krb5_enc_tkt_part is called from krb5_encrypt_tkt_part and
krb5_encrypt_tkt_part is called from get_credv5_akimpersonate for non
Heimdal case. So we should change HAVE_ENCODE_KRB5_ENC_TKT to
HAVE_ENCODE_KRB5_ENC_TKT_PART.
Also while we're here, add a declaration for the internal function
encode_krb5_ticket, so we can build this newly-enabled code without
warnings.
Reviewed-on: https://gerrit.openafs.org/13825
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit 6559297610de0f71c9050f3582d4d146e0cc1f3c)
Change-Id: Ia89cdbf23160c71e5b65b8220e1c1f73f1055064
Reviewed-on: https://gerrit.openafs.org/14479
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit e262f3a22d209b147d56e302634f95ffc37b007b
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Sat Aug 10 02:54:38 2019 +0530
aklog: Free client/server princs in get_credv5
Inside get_credv5, client_principal is static so the first time
get_credv5 runs we'll allocate memory for it, and on subsequent calls
we'll reuse the same value.
However, if we call get_credv5_akimpersonate, we'll free
client_principal and never change what client_principal points to. If we
need to call get_credv5 again (because we need to retry getting creds),
we'll reuse the old value for client_principal, but since it points to
free memory we'll segfault or cause other problems.
To avoid this, change get_credv5 so we allocate the client and server
principals on each invocation of get_credv5 and free them before
returning from get_credv5. Since we free the client and server
principals inside get_credv5, remove freeing the client and server
principals inside get_credv5_akimpersonate.
Reviewed-on: https://gerrit.openafs.org/13761
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 ab8b28540ef17d67db02d5dbcb7585443c164e45)
Change-Id: I818202660be4522bd49bf207c59d202ed8adf88d
Reviewed-on: https://gerrit.openafs.org/14478
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8e98d9c1cad3afef5508dcc16cc04946be43d9b8
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Sat Aug 10 02:41:01 2019 +0530
aklog: free kbr5_creds before returning from rxkad_get_token
rxkad_get_ticket allocates 'v5cred' which should be freed when we
return from rxkad_get_token.
Reviewed-on: https://gerrit.openafs.org/13760
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 130a92214cc0b9a8f4ea24a3dcd3ed04575e3c4e)
Change-Id: I02720f37c71ee56b4bd3d79d5f3e06c3ee647c9b
Reviewed-on: https://gerrit.openafs.org/14477
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 563f5b2915a4a43b2642dba8287b3d6d36d5b3c8
Author: Andrew Deason <adeason@sinenomine.net>
Date: Sat Jan 9 12:47:09 2021 -0600
WINNT: Restore missing '#ifdef PC'
Commit 339167ef (Remove dead code) meant to remove the '#ifdef notdef'
block in here, but we accidentally also removed the subsequent '#ifdef
PC'.
This file may not be very important, since WINNT still builds with
this mistake, but an unbalanced #ifdef is potentially super confusing,
so fix it.
Reviewed-on: https://gerrit.openafs.org/14487
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2971dcb3b4da04fff3f4bd9c3d3e3f0ab7a94cae)
Change-Id: I273ad30d38d7a41e7ec662994d91e084c24194bb
Reviewed-on: https://gerrit.openafs.org/14490
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 734c7650597b461848829f0706b6a5be29e9fbb9
Author: Andrew Deason <adeason@sinenomine.net>
Date: Wed Jul 10 15:14:28 2019 -0500
Remove dead code
There is a perhaps-surprisingly large amount of code disabled behind
directives like '#if 0', '#ifdef notdef', and '#ifdef notyet'. At
best, this code is clutter, and at worst some of it is
confusing/outdated, and/or confusingly nested inside other
preprocessor conditionals. Sometimes this disabled code shows up when
grepping the tree, and causes a nuisance when refactoring related
areas of code.
Get rid of all of it. If anyone ever wants this code back, it can
always be restored by reverting portions of this commit.
Also delete some comments that clearly refer to the disabled code, and
in some cases, adjust the adjacent comments to make sense accordingly.
This commit doesn't touch any files in src/external/.
Reviewed-on: https://gerrit.openafs.org/13683
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 339167ef1fda899655969f4572ff95271dfdb7cf)
Change-Id: I440b01de0fdb0ef2602557bf3fa35dcdf9a22cdc
Reviewed-on: https://gerrit.openafs.org/14476
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7e42148ee75ff523cd232658fd3f46945f5920ce
Merge: 5004f88 06b800f
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: Thu Jan 14 14:24:38 2021 -0800
Merge branch 'openafs-stable-1_8_7-branch' into openafs-stable-1_8_7
Record the history of the 1.8.7 emergency patch release.
Resolve the nominal conflict in configure.ac due to 1.8.7 bumping
the version and openafs-stable-1_8_x removing the LINUX_PKGREL variable.
Change-Id: Ifa719bcec3948b2634841fba90e835f9db088dd6
commit 06b800f6f1022fa4b86eb9023b75028f2e2cfeab
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: Thu Jan 14 13:08:41 2021 -0800
Make OpenAFS 1.8.7
Update version strings for the 1.8.7 emergency patch release.
Change-Id: I665bedad864b1c2cbbe55978d6b06e917ed26faa
commit f3b5c62660a48f693897d2faa1cecfd1c10307de
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: Thu Jan 14 13:06:18 2021 -0800
Update NEWS for 1.8.7
Add the release notes for the 1.8.7 emergency patch release.
Change-Id: I813f11e4e72c12cb927f66472b099febbf3d899f
commit 81a3600bfdcc122d43c75720e83317dcc2a9e6a1
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: Thu Jan 14 10:20:59 2021 -0800
Remove overflow check from update_nextCid
The rx_nextCid global has been an unsigned type since
http://gerrit.openafs.org/11106 (which was actually merged before
the refactoring of overflow check to avoid signed integer overflow)
and thus there is no need to avoid signed overflow. The per-connection
cid has been unsigned since the IBM import.
The natural unsigned behavior on overflow of wrapping is the desired
behvaior here, so just remove the extra logic and always increment.
Reviewed-on: https://gerrit.openafs.org/14496
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13)
Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d
Reviewed-on: https://gerrit.openafs.org/14497
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
(cherry picked from commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8)
commit 6f898c4c711d0aff7ea452670164802b5e423c18
Author: Jeffrey Altman <jaltman@auristor.com>
Date: Thu Jan 14 09:57:13 2021 -0500
rx: update_nextCid overflow handling is broken
The overflow handling in update_nextCid() produces a rx_nextCid
value of 0x80000001 which itself is out of the valid range. When
used to construct the first call of a new connection the connection
id for the call becomes 0x80000002, and all subsequent connections
also trigger the overflow handling and thus also receive connection
id 0x80000002.
If the same connection id is used for multiple connections from
the same endpoint the accepting rx peer will be very confused.
When authenticated connections are used, the CHALLENGE/RESPONSE
will fail because of a mismatch in the connection's callNumber
array.
If an initiator makes only a single connection to a given rx peer,
that connection would succeed, but once multiple connections are
initiated all communication from a broken initiator to any rx peer
will fail.
The incorrect overflow calculation was introduced by
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core").
This change corrects the overflow value to become
1 << RX_CIDSHIFT
Reviewed-on: https://gerrit.openafs.org/14492
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 2c0a3901cbfcb231b7b67eb0899a3133516f33c8)
Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d
Reviewed-on: https://gerrit.openafs.org/14494
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7)
commit 54c56dfa423bac14db117f5ec641ebe0eda705e3
Author: Jeffrey Altman <jaltman@auristor.com>
Date: Thu Jan 14 09:41:39 2021 -0500
rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core") introduced the use of RAND_bytes()
to generate the initial 'rx_nextCid' but failed to remove the
rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT;
assignment inherited from IBM/Transarc.
At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation
overflows the value CID range. This triggers broken overflow
logic in update_nextCid().
Reviewed-on: https://gerrit.openafs.org/14491
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473)
Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8
Reviewed-on: https://gerrit.openafs.org/14493
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit a41fe24be574f35ca852fc3ea9750e370cdb71d0)
commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: Thu Jan 14 10:20:59 2021 -0800
Remove overflow check from update_nextCid
The rx_nextCid global has been an unsigned type since
http://gerrit.openafs.org/11106 (which was actually merged before
the refactoring of overflow check to avoid signed integer overflow)
and thus there is no need to avoid signed overflow. The per-connection
cid has been unsigned since the IBM import.
The natural unsigned behavior on overflow of wrapping is the desired
behvaior here, so just remove the extra logic and always increment.
Reviewed-on: https://gerrit.openafs.org/14496
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13)
Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d
Reviewed-on: https://gerrit.openafs.org/14497
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7
Author: Jeffrey Altman <jaltman@auristor.com>
Date: Thu Jan 14 09:57:13 2021 -0500
rx: update_nextCid overflow handling is broken
The overflow handling in update_nextCid() produces a rx_nextCid
value of 0x80000001 which itself is out of the valid range. When
used to construct the first call of a new connection the connection
id for the call becomes 0x80000002, and all subsequent connections
also trigger the overflow handling and thus also receive connection
id 0x80000002.
If the same connection id is used for multiple connections from
the same endpoint the accepting rx peer will be very confused.
When authenticated connections are used, the CHALLENGE/RESPONSE
will fail because of a mismatch in the connection's callNumber
array.
If an initiator makes only a single connection to a given rx peer,
that connection would succeed, but once multiple connections are
initiated all communication from a broken initiator to any rx peer
will fail.
The incorrect overflow calculation was introduced by
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core").
This change corrects the overflow value to become
1 << RX_CIDSHIFT
Reviewed-on: https://gerrit.openafs.org/14492
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 2c0a3901cbfcb231b7b67eb0899a3133516f33c8)
Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d
Reviewed-on: https://gerrit.openafs.org/14494
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
commit a41fe24be574f35ca852fc3ea9750e370cdb71d0
Author: Jeffrey Altman <jaltman@auristor.com>
Date: Thu Jan 14 09:41:39 2021 -0500
rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid
39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
generation into the rx core") introduced the use of RAND_bytes()
to generate the initial 'rx_nextCid' but failed to remove the
rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT;
assignment inherited from IBM/Transarc.
At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation
overflows the value CID range. This triggers broken overflow
logic in update_nextCid().
Reviewed-on: https://gerrit.openafs.org/14491
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473)
Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8
Reviewed-on: https://gerrit.openafs.org/14493
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
commit b65b33da4e65e2c981ce264ef4fa4e3e4c94b732
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Mon Aug 17 15:44:55 2020 -0400
vldb_check: Check for volume lock inconsistencies
Verify the a lock timestamp is set if, and only if, a lock volume
operation flag is also set.
When running vldb_check with the -fix option, fix the inconsistent
entries by setting the lock timestamp to the current time if a lock flag
is set, or by setting the VLOP_DELETE flag if the lock timestamp is set
but no lock flags are set. (The VLOP_DELETE flag is the flag set by the
'vos lock command, and is shown in vos output as "delete/misc".)
Volume lock fields can be put into an inconsistent state, at least, by
interupted vos rename operations, due to bugs in vos rename. When the
volume lock timestamp and lock flags are in this inconsistent state, the
volume is locked, but that is not indicated by 'vos listvldb'. The
volume can be unlocked by issuing 'vos unlock'.
Reviewed-on: https://gerrit.openafs.org/14307
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
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 4c33820525af510a8a937289005e39d5b6683b19)
Change-Id: Ia894139145d92948b2af43bd115792556131cd5a
Reviewed-on: https://gerrit.openafs.org/14450
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 37187ba29454cba5a79eebff6251d6ff145907cf
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon May 18 12:09:38 2020 -0500
auth: Close fd on SetExtendedCellInfo write error
Currently, and since OpenAFS 1.0, if write() fails here, we leak the
file descriptor. A write() failure should be very unlikely, but close
the fd to make sure we avoid the leak.
Reviewed-on: https://gerrit.openafs.org/14213
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c81579dc7b0c0ac6bc34f63384d705a4445c2bbd)
Change-Id: I4dd96cca2fd9c01390fb508ab12d507ab1a56c8b
Reviewed-on: https://gerrit.openafs.org/14461
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit b201d2a3a97830d34ea5b76c9c2d5d3adc1a54a6
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jul 26 15:48:00 2018 -0500
Remove DUX/OSF code
Remove code for DUX/OSF platforms. DUX code was removed from the
libafs client in commit 392dcf67 ("Complete removal of DUX client
code") and the alpha_dux* param files were removed in dc4d9d64 ("afs:
Remove AFS_BOZONLOCK_ENV"). This code has always been disabled since
those commits, so remove any code referencing AFS_DUX*_ENV,
AFS_OSF_ENV, and related symbols.
Reviewed-on: https://gerrit.openafs.org/13260
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6534b10a4180ec10bceebbc11405718e7969fa21)
Change-Id: I632636fe6c5111b60c5b586c346ecc10ccfa8f3c
Reviewed-on: https://gerrit.openafs.org/14452
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c55607d732a65f8acb1dfc6bf93aee0f4409cecf
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Oct 26 12:35:32 2020 -0500
LINUX: Return errors in our d_revalidate
In our d_revalidate callback (afs_linux_dentry_revalidate), we
currently 'goto bad_dentry' when we encounter any error. This can
happen if we can't allocate memory or some other internal errors, or
if the relevant afs_lookup call fails just due to plain network
errors.
For any of these cases, we'll treat the dentry as if it's no longer
valid, so we'll return '0' and call d_invalidate() on the dentry.
However, the behavior of d_invalidate changed, as mentioned in commit
afbc199f1 (LINUX: Avoid d_invalidate() during
afs_ShakeLooseVCaches()). After a certain point in the Linux kernel,
d_invalidate() will also effectively d_drop() the given dentry,
unhashing it. This can cause getcwd() calls to fail with ENOENT for
those directories (as mentioned in afbc199f1), and can cause
bind-mount calls to fail similarly during a small window.
To avoid all of this, when we encounter an error that prevents us from
checking if the dentry is valid or not, we need to return an error,
instead of saying 'yes' or 'no'. So, change
afs_linux_dentry_revalidate to jump to the 'done' label when we
encounter such errors, and avoid calling d_drop/d_invalidate in such
cases. This also lets us remove the 'lookup_good' variable and
consolidate some of the related logic.
Important note: in older Linux kernels, d_revalidate cannot return
errors; callers just interpreted its return value as either 'valid'
(non-zero) or 'not valid' (zero). The treatment of negative values as
errors was introduced in Linux commit
bcdc5e019d9f525a9f181a7de642d3a9c27c7610, which was included in
2.6.19. This is very old, but technically still above our stated
requirements for the Linux kernel, so try to handle this case, by
jumping to 'bad_dentry' still for those old kernels. Just do this with
a version check, since no configure check can detect this (no function
signatures changed), and the only Linux versions that are a concern
are quite old.
Reviewed-on: https://gerrit.openafs.org/14417
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 78e5e1b0e54b31bb08b7578e86a6a2a95770d94c)
Change-Id: I9f9e2cd3a10cc8fa30a770cabd6ae9757f412ce5
Reviewed-on: https://gerrit.openafs.org/14451
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit dc5e7825fb166ecdb32fc7b63b4a5316037de652
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Apr 20 14:51:08 2020 -0400
vos: avoid 'half-locked' volume after interrupted 'vos rename'
Reported symptoms:
If a 'vos rename' is interrupted after it has locked the volume and
replaced the VLDB entry, but before it has unlocked the volume, the
volume will remain locked. However, the locked volume will NOT be
listed as locked in any vos commands that display locked status (see
below for details).
Background:
Most vos write operations lock the VLDB volume entry before proceeding,
then release the volume lock when finished. This is accomplished via
VL_SetLock and VL_ReleaseLock, respectively.
VL_SetLock always sets these members in the VLDB volume entry:
- flags is modified to set the required VLOP_* code bit as specified
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to the current time
VL_ReleaseLock always sets them as follows:
- flags is cleared of any VLOP_* code bit
- LockAFSid is set to 0 (never implemented)
- LockTimestamp is set to 0
VL_ReplaceEntry(N) may also optionally clear each of these members:
- flags operation bits may be explicitly cleared via LOCKREL_OPCODE
- LockAFSid may be explicitly cleared via LOCKREL_AFSID
- LockTimestamp may be explicitly cleared via LOCKREL_TIMESTAMP
When all 3 options are specified, VL_ReplaceEntry also does the
functional equivalent of a VL_ReleaseLock. Most vos operations use this
method. However, when no lock release options are specified on
VL_ReplaceEntry(N), the VLDB entry is simply replaced with the supplied
entry. This includes whatever flags values are specified in the
supplied entry; therefore, this amounts to an additional, implicit way
to set or modify the flags.
Root cause:
'vos rename' (UV_RenameVolume) is the only vos operation that does all
of the following things:
- accepts a replacement volume entry that was obtained before VL_SetLock
(and thus does NOT have any lock flags set)
- issues VL_SetLock (which sets the lock flag in the VLDB)
- issues VL_ReplaceEntry(N) with the original unlocked entry, and with
no lock release options (thus with explicit intent to leave the lock
flag unchanged, but inadvertently doing an implicit clear of the lock
flag in the VLDB)
- (performs some additional volserver work)
- issues VL_ReleaseLock to release the volume lock
Therefore, if 'vos rename' is cancelled or killed before reaching the
final VL_ReleaseLock step, the VLDB entry is left with the lock flags
cleared but the LockTimestamp still set. As we will see below, this
'half-locked' state produces confusing results from other vos commands.
Detection of locked state:
The 'vos lock' command (and all other vos commands that issue
VL_SetLock) use the lock timestamp to determine if a volume is locked.
However, several other vos commands ('vos listvldb <vol>', 'vos examine
<vol>', 'vos listvldb -locked') use the VLDB entry's lock flags (not the
lock timestamp) to determine if the volume is locked. Therefore, if the
lock flags have been cleared but the lock timestamp is still set, these
commands fail to detect that the volume is still locked. Yet an
administrator's 'vos lock <volume>' will still fail with:
Could not lock VLDB entry for volume <volume>
VLDB: vldb entry is already locked
This is the external manifestation of the 'half-locked' state.
Workaround and fix:
This scenario has a simple workaround: 'vos unlock <volume>'. However,
to avoid this confusing outcome in the first place, modify the 'vos
rename' logic so that the lock flags are no longer inadvertently
cleared. Now, if the 'vos rename' is interrupted before the volume is
unlocked, it will still appear locked in normal vos command output.
Change-Id: Iefc6ef54ea4b0e95e3ae8e8a43d3ded0f15af0fa
Reviewed-on: https://gerrit.openafs.org/14157
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-on: https://gerrit.openafs.org/14449
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit a518b0c439b40886dcb2337919d49b3009a00b4d
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Thu Nov 5 13:50:59 2020 -0700
vos: Cleanup function definitions
The functions defined within vos.c are not referenced outside of vos.c
but are not declared as static.
Convert the functions within vos.c to static declarations.
Reviewed-on: https://gerrit.openafs.org/14009
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 56aa396d8359276d778d41aa509041c8c75b4e96)
Change-Id: Idca045431959bb3e4b31d12ef754a883d4118a89
Reviewed-on: https://gerrit.openafs.org/14448
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ab30c00f6ab663e0907830e76e76b44710712a07
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Thu Nov 5 13:49:54 2020 -0700
vos: Remove dead code
Clean out dead code from vos.c
GetVolumeType - not referenced anywhere
CompareVLDBEntry - commented out since 1st git commit
osi_audit - Comment indicates this might have been needed at one point.
Builds without it. Does not look like the vos executable
is pulling in any of the audit code.
RestoreVolume - remove stale comment about typo previous to openafs 1.0
RemoveSite - remove commented out partition check
Reviewed-on: https://gerrit.openafs.org/14008
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a3be2c74a95489f63837840af8ec42049ce021bf)
Change-Id: I71a78d2a46b8d64cdde9db05a0079e9db954d191
Reviewed-on: https://gerrit.openafs.org/14447
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 00095ea2eff4d8570af78044b88c2b2877ce4e2a
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Tue Nov 10 09:17:16 2020 -0700
vos: Cleanup indentation whitespace
Fix the indentation whitespace in vos.c, and remove double blank
lines. No functional change.
Reviewed-on: https://gerrit.openafs.org/14007
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c17c157641d83226fee5bc20f588f14bb132bb68)
Change-Id: Iecde7505a3f59c4b6e59d4644b7a1e56127c272d
Reviewed-on: https://gerrit.openafs.org/14446
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ebbeb69286ae408b59878074d06bc350001ad669
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri Dec 27 11:53:05 2019 -0500
vsprocs: Remove dead code
Remove the dead code in UV_VolumeMove() commented out with the macro
ENABLE_BUGFIX_1165.
Remove two commented out lines of code in UV_ConvertRO().
Reviewed-on: https://gerrit.openafs.org/14004
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 6779e30d372b2cd5e7995da23ed5e2971124b79c)
Change-Id: Ibeddebdf24ca50341bba3031c6f8548cab245b8a
Reviewed-on: https://gerrit.openafs.org/14445
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 32742e3171e32970ee86449ef41d04df388a37f4
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Tue Oct 6 10:18:11 2020 -0400
bozo: defer audit open until log dir is created and current
On a new OpenAFS install where the log directory has not yet been
created. 'bosserver -auditlog /usr/afs/logs/<auditlog>' (absolute path)
fails with ENOENT because the log directory doesn't exist yet.
Furthermore, 'bosserver -auditlog <auditlog>' (relative path) succeeds,
but the audit file is created in the current working directory when
bosserver was started, not in the expected log directory (Transarc
/usr/afs/logs).
Both problems have been present since bosserver audit log support was
introduced by commit 16d67791dce45e5d4ee9b854c796492ffcde2113
'auditlogs-for-everyone-20050702'.
Reorder the bosserver initialization steps to ensure that the log
directory has been created and is the current working directory, before
creating and opening the audit log.
Reviewed-on: https://gerrit.openafs.org/14381
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f372ec041a83288a5d096360f0ad8589e4db666a)
Change-Id: I14a0a4a2a23c8e9b3b658d52511872ecaa4010af
Reviewed-on: https://gerrit.openafs.org/14444
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 2473cfb5b98a0226c79e25649cb5cc52b9aea09b
Author: Andrew Deason <adeason@sinenomine.net>
Date: Sat Oct 17 20:51:51 2020 -0500
bozo: Properly detect presence of -auditlog
cmd_OptionAsString returns non-zero if the given option _isn't_ given
(CMD_MISSING), so we need to call osi_audit_file only when
cmd_OptionAsString returns 0. Since commit
f6cdf71 (bozo: Use libcmd for command line options), this causes
bosserver to complain on startup if no -auditlog was given:
$ bosserver
Warning: auditlog (null) not writable, ignored.
To fix this, skip calling osi_audit_file if -auditlog was not given.
While we're changing this anyway, change our processing of our
audit-related options to more closely match what other daemons do,
like ptserver or viced, so it's easier to see if we're doing the right
thing. That is, just call cmd_OptionAsString() without a conditional,
and just test if auditFileName is non-NULL later on, after options
processing.
Reviewed-on: https://gerrit.openafs.org/14402
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 87041d676c93dfe35a085b9b5aaa73e74c08bc90)
Change-Id: Ic05e5453c28b4c408300ea35439a519adc282486
Reviewed-on: https://gerrit.openafs.org/14443
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 633712a321f4cf51ffc6f97d2f9fabbb59b32a09
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Aug 21 12:53:30 2020 -0600
bozo: Use libcmd for command line options
Update bosserver to use libcmd for command line parsing.
Reviewed-on: https://gerrit.openafs.org/13845
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit f6cdf7165b4e66772ee06314658b7c209928d611)
Change-Id: I8fdf27d099f81c08a37db728846bd7596a8cf62e
Reviewed-on: https://gerrit.openafs.org/14442
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit de0ec465625f18668325dfbe29337650ed98b560
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Fri Oct 28 18:12:19 2016 -0400
afs: prevent double release of global lock afs_xvcb
afs_GetServer calls ReleaseWriteLock(&afs_xvcb) twice within a few
lines. The second one is spurious.
Commits b18653de7ae90491c2e75f4a98410581655d776c 'xserver lock order
violation' and f2bf60ed4f1323cd6f74f2f01114f7e4f714db53 'xvcb lock order
violation' were written by the same author at the same time and
apparently were victims of a bad merge.
Discovered during a lock audit project as a panic during afsd startup:
assertion failed: (&afs_xvcb)->excl_locked == WRITE_LOCK, file:
/home/mvitale/src/sna-openafs/src/afs/afs_server.c, line: 2089
afs_GetServer is called frequently by many threads and so this bug could
easily have released another thread's write lock on afs_xvcb.
Remove the spurious second release.
Reviewed-on: https://gerrit.openafs.org/14411
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e8702e6a615a160cdbe464f76bd6f100667720d2)
Change-Id: I3165a63e774296b97e09c374b068b012224776e1
Reviewed-on: https://gerrit.openafs.org/14441
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit b33c832facc53ff966071fd3ff0e5d6b33deb9cb
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Sep 18 19:45:10 2017 -0400
stats: incorrect clock square algorithm
Since the original IBM code import, OpenAFS has an algorithm for
squaring clock values, implemented identically in three different
places. This algorithm does not account correctly for microsecs
overflow into seconds, resulting in incorrect "sum-of-squares" values
for queue and execution time in several OpenAFS performance utilities.
Specifically, this code:
t1.tv_usec += (2 * t2.tv_sec * t2.tv_usec) % 1000000 \
+ (t2.tv_usec / 1000)*(t2.tv_usec / 1000) \
+ 2 * (t2.tv_usec / 1000) * (t2.tv_usec % 1000) / 1000 \
+ (((t2.tv_usec % 1000) > 707) ? 1 : 0); \
Can allow for the tv_usec field to be increased by a theoretical max
of around:
t1.tv_usec += 999998 \
+ 999*999 \
+ 2 * 999 * 999 / 1000 \
+ 1; \
Or:
t1.tv_usec += 1999996; \
If t1.tv_usec is already 999999, after this calculation its value
could be as high as 2999995. So just checking once if t1.tv_usec is
over 1000000 is not sufficient, since the resulting value (1999995) is
still over 1000000.
Correct all implementations by repeatedly checking if tv_usec is over
1000000 after the above calculation:
macro affected utility
===================== ============================
afs_stats_SquareAddTo xstat_cm_test
fs_stats_SquareAddTo xstat_fs_test
clock_AddSq rxstat_get_process and _peer
Reviewed-on: https://gerrit.openafs.org/14376
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e1e5df918fee00d4d9152c31c24cc1e7f23b71a6)
Change-Id: I4055ed61311ed7d6ac435b8660d5b7c55f467699
Reviewed-on: https://gerrit.openafs.org/14440
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 489308de9f62a3f881cd5f89d648c168a488c4d7
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Sep 28 16:35:38 2020 -0400
rxstats: correctly report vlserver VL_* RPC stats
Since the original IBM code import, rxstat_get_process and
rxstat_get_peer have reported vlserver VL_* RPC stats as for the
"volserver interface".
Correct this to read "vlserver interface".
Reviewed-on: https://gerrit.openafs.org/14375
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e985d43d99d93172b5608a3c73fd3201d3b3a212)
Change-Id: Ifbbe4df8ede22b287ab7c67d20e9ccd951367765
Reviewed-on: https://gerrit.openafs.org/14439
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ffc5b608ab3e99d654561b1a3f4b3a873a6af1c0
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Sep 28 15:40:34 2020 -0400
rxstats: correctly distinguish client and server stats
Commit d3eaa39da3693bba708fa2fa951568009e929550 'rx: Make the rx_call
structure private' inadvertently caused all rxstats (aka rpcstats) to be
recorded as client stats by hardcoding the value for isServer to 1.
Therefore, when peer or process rxstats are enabled for a OpenAFS
component, the rxstat_get_process and rxstat_get_peer utilities will
erroneously report both client and server stats as "accessed as a client".
This is particularly problematic for ubik VOTE_* and DISK_* RPC stats,
for which a given ubik server may be both client and server over time.
In this case, both client and server stats are conflated into the same
"accessed as a client" counters.
Instead, properly pass the value of isServer from
rx_RecordCallStatistics through to rxi_IncrementTimeAndCount.
Note to maintainers:
This bug is only in master and all 1.8.x releases; no 1.6.x releases are
affected.
Note:
Confusingly, isServer=1 indicates client stats and isServer=0 indicates
server stats. However, this is a quirk of the original implementation
and wire format of the RXSTATS_* RPCs and cannot be changed. isServer
is actually shorthand for "remote is server"; thus all RPC client stubs
record their rxstats with isServer == 1, and all RPC server stubs record
their rxstats with isServer == 0.
Reviewed-on: https://gerrit.openafs.org/14374
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 18c345a9f8ee9b2ff73f23dae68757b19d3283f5)
Change-Id: I6d41d015803967363f3702f5dda7083ccbf7508a
Reviewed-on: https://gerrit.openafs.org/14438
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5d863b4f6e817b1cc2615265c7747e17a2037ae6
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Oct 26 12:19:19 2020 -0500
afs: Log pid with disk cache read errors
Log the current pid (and procname) when we complain about an error
when reading from CacheItems in afs_UFSGetDSlot. These errors can
result in confusing situations, so it can be helpful to know at least
what process saw the error.
Our logic for logging this information is getting a bit large, so also
move this to a new function, LogCacheError.
Reviewed-on: https://gerrit.openafs.org/14416
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 1caeeea43c038011306dd1c391680c24fc318e3d)
Change-Id: Ia159eeea47191f71fc5892cbc54af79b55bf4828
Reviewed-on: https://gerrit.openafs.org/14437
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c7c8f75ebf812f1943aa9efd76dde26be99c96b1
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Nov 12 15:06:09 2018 -0600
vlserver: Return VL_DBBAD on unhash failure
If we try to delete a vlentry, and the vlentry cannot be found on one
of its hash chains, we cannot unhash the vlentry properly and the
operation fails with VL_NOENT. This results in the following error
messages to the user:
$ vos delentry 123456
Could not delete entry for volume 123456
You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
VLDB: no such entry
Deleted 0 VLDB entries
This is confusing, because VL_NOENT can also occur if the user
specifies a volume that does actually not exist. This situation is
indicative of database corruption, usually because of a ubik
transaction that was only half-applied, or because of other ubik bugs
in the past.
The situation can only really be fixed by repairing the database, so
return VL_DBBAD in this case instead, to more clearly indicate that
something is wrong with the database, and not a problem with the
arguments the caller provided.
Reviewed-on: https://gerrit.openafs.org/13384
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit fd6add0aca03a5a17f7109c785b6027a76f13cdf)
Change-Id: Ib1cf72b7f0d6c65e37c13f00d6f6049a3049b644
Reviewed-on: https://gerrit.openafs.org/14436
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 751aa775da1c76a495cf1b0754185cb4cdc23fbe
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Nov 12 14:41:44 2018 -0600
vlserver: Add VL_DBBAD error code
The VL_ error table currently doesn't have an error code to indicate
that an operation cannot succeed because the database is corrupted.
There are a few error codes for specific cases of errors that are
probably the result of corruption (like VL_IDALREADYHASHED, or
VL_EMPTY), but these are only for specific cases and indicate rather
low-level internal problems.
There are some instances where the real problem preventing an
operation from succeeding is that the database is just corrupt or
inconsistent in some way, and the administrator must repair the
database before it can succeed. And we currently don't have any way of
indicating that situation via an error code.
So, introduce the VL_DBBAD code, to indicate this situation. Error
codes already exist in other tables for similar situations, such as
PRDBBAD, and KADATABASEINCONSISTENT.
This commit does not use the new error code anywhere; we just
introduce it into the VL_ error table, so comerr-using applications
will be able to interpret it.
Note that the VL_DBBAD error code has been recognized by the AFS
Assigned Numbers Registry as recorded in the ticket history of
<https://rt.central.org/rt/Ticket/Display.html?id=134817>
Reviewed-on: https://gerrit.openafs.org/13383
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 878d27c845157bb64c32bbd6c3cacce17c681d70)
Change-Id: I93b4916890ec9e4f6f5453ecf28c8a8ce04af7ea
Reviewed-on: https://gerrit.openafs.org/14435
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 27a2cdadd221d4a870d5ce9b936bb103c605cafb
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Nov 12 15:01:18 2018 -0600
vlserver: Warn when we cannot unhash deleted entry
If we are trying to delete an entry from the vldb, we fail with
VL_NOENT if we cannot find the given entry on one of its hash chains.
This is indicative of corruption in the vldb (since we have an entry
not on a hash chain), but we don't really indicate this clearly. There
are no log messages, and the user running 'vos' only sees an error
like this:
$ vos delentry 123456
Could not delete entry for volume 123456
You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
VLDB: no such entry
Deleted 0 VLDB entries
Which is the exact same error message if the user tries to delete a
volume that does not actually exist.
We currently do not have an error code that clearly says that the
database appears corrupted and needs to be fixed, but we can at least
log an error in VLLog for this case, to give the administrator a
chance at fixing the situation. So, log a message in this situation.
Reviewed-on: https://gerrit.openafs.org/13382
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3e3fce24da31a31ca9a3f4ad356c4e4eaf0ad897)
Change-Id: Ia76c5d7a19c3d21a89fc502e14922672afd8a84f
Reviewed-on: https://gerrit.openafs.org/14434
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 757b90ef33f7d5f00c4b1990c2300f6502a3b74a
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Thu Sep 3 23:57:34 2020 +0000
volser: take RO volume offline during convertROtoRW
The vos convertROtoRW command converts a RO volume into a RW volume.
Unfortunately, the RO volume is not checked out from the fileserver
during this process. As a result, accesses to the volume being converted
can leave volume objects in an inconsistent state.
Moreover, consider the following scenario:
1. Create a volume on host_b and add replicas on host_a and host_b.
$ vos create host_b a vol_1
$ vos addsite host_b a vol_1
$ vos addiste host_a a vol_1
2. Mount the volume:
$ fs mkmount /afs/.mycell/vol_1 vol_1
$ vos release vol_1
$ vos release root.cell
3. Shutdown dafs on host_b:
$ bos shutdown host_b dafs
4. Remove RO reference to host_b from the vldb:
$ vos remsite host_b a vol_1
5. Attach the RO copy by touching it:
$ fs flushall
$ ls /afs/mycell/vol_1
6. Convert RO copy to RW:
$ vos convertROtoRW host_a a vol_1
Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving
the volume object for the RO copy set as VOL_STATE_ATTACHED (on success,
this volume should be set as VOL_STATE_DELETED).
7. Add replica on host_a:
$ vos addsite host_a a vol_1
8. Wait until the "inUse" flag of the RO entry is cleared (or force this
to happen by attaching multiple volumes).
9. Release the volume:
$ vos release vol_1
Failed to start transaction on volume 536870922
Volume not attached, does not exist, or not on line
Error in vos release command.
Volume not attached, does not exist, or not on line
Notice that this happens because we cannot mark an attached volume as
destroyed (FSYNC_com_VolDone).
To avoid the problem mentioned above and to prevent accesses to the
volume being converted, take the RO volume offline before converting it
to RW.
Reviewed-on: https://gerrit.openafs.org/14340
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 45a69b61133ae8ca8e49a002ddc1895386796d51)
Change-Id: I94e08d09d5044f3c0cac7c700f26ec6e7b111d6f
Reviewed-on: https://gerrit.openafs.org/14433
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 199d485ee862c21c43008e1fd4b226517d20068c
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Thu Sep 3 20:11:34 2020 +0000
volser: Close dirp on error in ConvertROtoRW
Currently, if SAFSVolConvertROtoRWvolume cannot create a new transaction
for the volume to be converted, it returns without closing the directory
stream opened by it. To prevent this leak, go through a new 'goto done'
destructor if NewTrans fails.
Reviewed-on: https://gerrit.openafs.org/14342
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f18b58f8227df2ab420d69eb5937a99f747c7692)
Change-Id: I81b5f7a330548eaecba1acfdc7231d2a953a365b
Reviewed-on: https://gerrit.openafs.org/14432
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit cc6b15564eaf94bcb41f930f396f1c1e4804fa18
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Thu Apr 16 16:29:09 2020 -0400
vlserver: fix missing read-only entries from ListAttributesN2
The ListAttributesN2() RPC can fail to list read-only entries under
certain circumstances. This RPC is used by the `vos listvldb` command to
retrieve vldb entries (unless the -name option is given). The `vos
listvldb` command fails to list volume entries when run with the
'-server' option for volumes that have read-only replicas, but have not
been released.
Consider the following example volume:
$ vos create fs1.example.com a test
$ vos addsite fs1.example.com a test
$ vos addsite fs2.example.com a test
$ vos listvldb
...
test
RWrite: 536870921
number of sites -> 3
server fs1.example.com partition /vicepa RW Site
server fs1.example.com partition /vicepa RO Site -- Not released
server fs2.example.com partition /vicepa RO Site -- Not released
`vos listvldb` fails to find the volume when the search is limited to
server 'fs2':
$ vos listvldb -server fs2.example.com
VLDB entries for server fs2.example.com
Total entries: 0
Instead of the expected results:
$ vos listvldb -server fs2.example.com
test
RWrite: 536870921
number of sites -> 3
server fs1.example.com partition /vicepa RW Site
server fs1.example.com partition /vicepa RO Site -- Not released
server fs2.example.com partition /vicepa RO Site -- Not released
This situation makes it difficult to remove old server addresses from
the vldb. In this situation, 'vos remaddrs' and 'vos changeaddr
-remove' commands will complain the server addresses are still in use by
volume entries, however running 'vos listvldb -server' will not show
which volumes entries are in use.
The entries are not listed for unreleased volumes because the
ListAttributesN2() RPC is currently checking the volume VLF_ROEXISTS
flag, instead of the server site flags (serverFlags) to determine when
the entry is a read-only site. The volume VLF_ROEXISTS flag is set when
a volume is released.
To fix this, make ListAttributesN2 check for the VLSF_ROVOL site flag,
instead of the VLF_ROEXISTS entry flag.
Reviewed-on: https://gerrit.openafs.org/14154
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 904f5bd398db248c11b30ef7e360ce5141dcd1f3)
Change-Id: Iea4bbbc9fb0c42ac5e109ee94688436fdcc42a67
Reviewed-on: https://gerrit.openafs.org/14427
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>
commit b7ddd1262117332871e7cd537aa6065b78a41bb2
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jun 18 21:16:09 2020 -0500
LINUX: Close cacheFp if no ->readpage in fastpath
In afs_linux_readpage_fastpath, if we discover that our disk cache fs
has no ->readpage function, we'll 'goto out', but we never close our
cacheFp. To make sure we close it, add a filp_close() call to the
'goto out' cleanup code.
Reviewed-on: https://gerrit.openafs.org/14252
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit f9d20c631d7280ce00125a1208331931a6e3f31c)
Change-Id: If409c50e5515cd80f77171a90fd96e2d3fb575a8
Reviewed-on: https://gerrit.openafs.org/14421
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 610e50b70c666f72a6d8b02e1759ac1dece10dd3
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri Aug 28 11:24:10 2020 -0400
bozo: Log each dir and file with bad access rights
The bosserver directory and file access check stops after finding one
directory or file with incorrect permissions or owner. A log message is
written for this first one found, but more than one directory or file
may have incorrect access rights.
Instead check all of them so the bosserver logs a warning message for
each incorrect director or file permission found. This should make it
easier to fix all of the file permission problems at once.
Reviewed-on: https://gerrit.openafs.org/14330
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 47d809d4434f6724d0b6fbe2dcb54749486eeddb)
Change-Id: Ieffac018628e1b3a1ad930b72312f596ee452b43
Reviewed-on: https://gerrit.openafs.org/14420
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 712ef18ac1902fabc540883827b1925769e0a050
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri Aug 28 11:23:00 2020 -0400
bozo: Add KeyFileExt and rxkad.keytab to access rights check
When the KeyFileExt and rxkad.keytab were added to OpenAFS, they were
not added to the bosserver's access rights check. Add these files to the
bosserver access checks, with the same access rights needed for the
original KeyFile.
Also, add the full path for KeyFileExt to the dirpath package (not just
the filename), which was not done when the KeyFileExt was introduced.
This is needed to perform the access checks.
Reviewed-on: https://gerrit.openafs.org/14329
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a6b14ea90259fbc4ead62f5f4288e435801db81e)
Change-Id: I94d9027f9455ee8a8f307864ffa49debaf579e71
Reviewed-on: https://gerrit.openafs.org/14419
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 62beb979b4e43c361db54fbf3084f876fd2c11da
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Jul 16 16:53:34 2018 -0500
afs: Skip bulkstat if stat cache looks full
Currently, afs_lookup() will try to prefetch dir entries for normal
dirs via bulkstat whenever multiple pids are reading that dir.
However, if we already have a lot of vcaches, ShakeLooseVCaches may be
struggling to limit the vcaches we already have. Entering
afs_DoBulkStat can make this worse, since we grab afs_xvcache
repeatedly, we may kick out other vcaches, and we'll possibly create
30 new vcaches that may not even be used before they're evicted.
To try to avoid this, skip running afs_DoBulkStat if it looks like the
stat cache is really full.
Reviewed-on: https://gerrit.openafs.org/13256
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9ff45e73cf3d91d12f09e108e1267e37ae842c87)
Change-Id: I1b84ab3bb918252e8db5e4379730a517181bc9d8
Reviewed-on: https://gerrit.openafs.org/14400
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 28794011085d35b293d5e829adadb372b2a2b3fd
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Jul 16 16:44:14 2018 -0500
afs: Log warning when we detect too many vcaches
Currently, afs_ShakeLooseVCaches has a kind of warning that is logged
when we fail to free up any vcaches. This information can be useful to
know, since it may be a sign that users are trying to access way more
files than our configured vcache limit, hindering performance as we
constantly try to evict and re-create vcaches for files.
However, the current warning is not clear at all to non-expert users,
and it can only occur for non-dynamic vcaches (which is uncommon these
days).
To improve this, try to make a general determination if it looks like
the stat cache is "stressed", and log a message if so after
afs_ShakeLooseVCaches runs (for all platforms, regardless of dynamic
vcaches). Also try to make the message a little more user-friendly,
and only log it (at most) once per 4 hours.
Determining whether the stat cache looks stressed or not is difficult
and arguably subjective (especially for dynamic vcaches). This commit
draws a few arbitrary lines in the sand to make the decision, so at
least something will be logged in the cases where users are constantly
accessing way more files than our configured vcache limit.
Reviewed-on: https://gerrit.openafs.org/13255
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0532f917f29bdb44f4933f9c8a6c05c7fecc6bbb)
Change-Id: Ic7260f276e00f3e34541207955df841d4ed27844
Reviewed-on: https://gerrit.openafs.org/14399
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 47ab46e1e9fe56b5bf8147eab0b652e74078cbe7
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Jul 16 16:08:13 2018 -0500
afs: Split out bulkstat conditions into a function
Our current if() statement for determining whether we should run
afs_DoBulkStat to prefetch dir entries is a bit large, and grows over
time. Split this logic out into a separate function to make it easier
to maintain, and add some comments to help explain each condition.
This commit should have no visible effects; it's just code
reorganization.
Reviewed-on: https://gerrit.openafs.org/13254
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 19cd454f11997d286bc415e9bc9318a31f73e2c6)
Change-Id: Ida322c518d11787fd794df7534135fbc2dec2935
Reviewed-on: https://gerrit.openafs.org/14398
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 738eb3e4976947657f877ec107d517d63a66a907
Author: Andrew Deason <adeason@sinenomine.net>
Date: Sun Jul 8 15:00:02 2018 -0500
afs: Bound afs_DoBulkStat dir scan
Currently, afs_DoBulkStat will scan the entire directory blob, looking
for entries to stat. If all or almost all entries are already stat'd,
we'll scan through the entire directory, doing nontrivial work on
each entry (we grab afs_xvcache, at least). All of this work is pretty
pointless, since the entries are already cached and so we won't do
anything. If many processes are trying to acquire afs_xvcache, this
can contribute to performance issues.
To avoid this, provide a constant bound on the number of entries we'll
search through: nentries * 4. The current arbitrary limits cap
nentries at 30, so this means we're capping the afs_DoBulkStat search
to 120 entries.
Reviewed-on: https://gerrit.openafs.org/13253
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ba8b92401b8cb2f5a5306313c2702cb36cba083c)
Change-Id: Icf82f88328621cb5a9e0ad52f873b8a7d74b1f3a
Reviewed-on: https://gerrit.openafs.org/14397
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fbba8e4cbf00f32181b5075e8d7a876cccd2a046
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jul 13 17:40:36 2017 -0500
afs: Avoid needless W-locks for afs_FindVCache
The callers of afs_FindVCache must hold at least a read lock on
afs_xvcache; some hold a shared or write lock (and set IS_SLOCK or
IS_WLOCK in the given flags). Two callers (afs_EvalFakeStat_int and
afs_DoBulkStat) currently hold a write lock, but neither of them need
to.
In the optimal case, where afs_FindVCache finds the given vcache, this
means that we unnecessarily hold a write lock on afs_xvcache. This can
impact performance, since afs_xvcache can be a very frequently
accessed lock (a simple operation like afs_PutVCache briefly holds a
read lock, for example).
To avoid this, have afs_DoBulkStat hold a shared lock on afs_xvcache,
upgrading to a write lock when needed. afs_EvalFakeStat_int doesn't
ever need a write lock at all, so just convert it to a read lock.
Reviewed-on: https://gerrit.openafs.org/12656
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6c808e05adb0609e02cd61e3c6c4c09eb93c1630)
Change-Id: Id517d1098b4c3a02db646b2a74535f77cb684ec3
Reviewed-on: https://gerrit.openafs.org/14396
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5c476b91fd2259e9c34070be8ba201dd471ad974
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Jul 13 17:40:21 2017 -0500
afs: Change VerifyVCache2 calls to VerifyVCache
afs_VerifyVCache is a macro that (on most platforms) effectively
expands to:
if ((avc->f.states & CStatd)) {
return 0;
} else {
return afs_VerifyVCache2(...);
}
Some callers call afs_VerifyVCache2 directly, since they already check
for CStatd for other reasons. A few callers currently call
afs_VerifyVCache2, but without guaranteeing that CStatd is not set.
Specifically, in afs_getattr and afs_linux_VerifyVCache, CStatd could
be set while afs_CreateReq drops GLOCK. And in afs_linux_readdir,
CStatd could be cleared at multiple different points before the
VerifyVCache call.
This can result in afs_VerifyVCache2 acquiring a write-lock on the
vcache, even when CStatd is already set, which is an unnecessary
performance hit.
To avoid this, change these call sites to use afs_VerifyVCache instead
of calling afs_VerifyVCache2 directly, which skips the write lock when
CStatd is already set.
Reviewed-on: https://gerrit.openafs.org/12655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a05d5b7503e466e18f5157006c1de2a2f7d019f7)
Change-Id: I05bdcb7f10930ed465c24a8d7e51077a027b1a4b
Reviewed-on: https://gerrit.openafs.org/14395
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 150ee65f286409e37fcf94807dbeaf4b79ab0769
Author: Andrew Deason <adeason@sinenomine.net>
Date: Sun Apr 26 17:26:02 2020 -0500
rx: Use _IsLast to check for last call in queue
Ever since commits 170dbb3c (rx: Use opr queues) and d9fc4890 (rx: Fix
test for end of call queue for LWP), rx_GetCall checks if the current
call is the last one on rx_incomingCallQueue by doing this:
opr_queue_IsEnd(&rx_incomingCallQueue, cursor)
But opr_queue_IsEnd checks if the given pointer is the _end_ of the
last; that is, if it's the end-of-list sentinel, not an item on the
actual list. Testing for the last item in a list is what
opr_queue_IsLast is for. This is the same convention that the old Rx
queues used, but 170dbb3c just accidentally replaced queue_IsLast with
opr_queue_IsEnd (instead of opr_queue_IsLast), and d9fc4890 copied the
mistake.
So because this is inside an opr_queue_Scan loop, opr_queue_IsEnd will
never be true, so we'll never enter this block of code (unless we are
the "fcfs" thread). This means that an incoming Rx call can get stuck
in the incoming call queue, if all of the following are true:
- The incoming call consists of more than 1 packet of incoming data.
- The incoming call "waits" when it comes in (that is, there are no
free threads or the service is over quota).
- The "fcfs" thread doesn't scan the incoming call queue (because it
is idle when the call comes in, but the relevant service is over
quota).
To fix this, just use opr_queue_IsLast here instead of
opr_queue_IsEnd.
Reviewed-on: https://gerrit.openafs.org/14158
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit befc72749884c6752c7789479343ba48c7d5cea1)
Change-Id: If724245414798ae7a86dfa048cf99863317aef8e
Reviewed-on: https://gerrit.openafs.org/14394
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 12aed9ef2988a69187910bada5ba7325cb6144ab
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 21 18:48:51 2019 -0500
rx: Avoid osi_NetSend during rx shutdown
Commit 8d939c08 (rx: avoid nat ping during shutdown) added a call
to shutdown_rx() inside the DARWIN shutdown sequence, before the rx
socket was closed. From the commit message, it sounds like this was
done to avoid NAT pings from calling osi_NetSend during the shutdown
sequence after the rx socket was closed; calling shutdown_rx() before
closing the socket would cause any connections we had to be destroyed
first, avoiding that.
The problem with this is that this means shutdown_rx() is called when
osi_StopNetIfPoller is called, which is much earlier than some other
portions of the shutdown sequence; some of which may hold references
to e.g. rx connections. If we try to, for instance, destroy an rx
connection after shutdown_rx() is called, we could panic.
An earlier version of that commit (gerrit PS1) just tried to insert a
check before the relevant osi_NetSend call, making us just skip the
osi_NetSend if the shutdown sequence had been started. So to avoid the
above issue, try to implement that approach instead. And instead of
doing it just for NAT pings, we can do it for almost all osi_NetSend
calls (besides those involved in the shutdown sequence itself), by
checking this in rxi_NetSend. Also return an error (ESHUTDOWN) if we
skip the osi_NetSend call, so we're not completely silent about doing
so.
This means we also remove the call to shutdown_rx() inside DARWIN's
osi_StopNetIfPoller(). This allows us to interact with Rx objects
during more of the shutdown process in cross-platform code.
Reviewed-on: https://gerrit.openafs.org/13718
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 9866511bb0a5323853e97e3ee92524198813776e)
Change-Id: Ie62c1a68d8a8889f7a8aa3eff3973c219b45a95c
Reviewed-on: https://gerrit.openafs.org/14393
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7f59989cf84df1e2077f4fcf5649c9624e79a5d2
Author: Andrew Deason <adeason@dson.org>
Date: Sun Jul 21 18:31:53 2019 -0500
rx: Introduce rxi_NetSend
Introduce a small wrapper around osi_NetSend, called rxi_NetSend. This
small wrapper allows future commits to change the code around our
osi_NetSend calls, without needing to change every single call site,
or every implementation of osi_NetSend.
Change most call sites to use rxi_NetSend, instead of osi_NetSend. Do
not change a few callers in the platform-specific kernel shutdown
sequence, since those call osi_NetSend for platform-specific reasons.
This commit on its own does not change any behavior with osi_NetSend;
it is just code reorganization.
Reviewed-on: https://gerrit.openafs.org/13717
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2a33a80f7026df6b5e47e42319c55d8b7155675a)
Change-Id: I6af8541953a582d044fb668eb4a91720536bc8e1
Reviewed-on: https://gerrit.openafs.org/14392
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 38f613f5e15552938cb425c68b22c166e35284be
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Oct 13 20:18:59 2020 -0500
ubik: Remove unused sampleName
The RPC-L type sampleName and related constant UMAXNAMELEN are not
referenced by anything, and have been unused since OpenAFS 1.0. Remove
the unused definitions.
Reviewed-on: https://gerrit.openafs.org/14386
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 83ce8d41c68a5ebcc84132d77af9024c6d285e05)
Change-Id: I1d6c583d9c630fc9704578ba3329132e16b3a803
Reviewed-on: https://gerrit.openafs.org/14401
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit f7374a883505aa34a3db34ddd1163367c544bb0c
Author: Andrew Deason <adeason@dson.org>
Date: Sat May 2 23:54:55 2020 -0500
afs: Drop GLOCK for RXAFS_GetCapabilities
We are hitting the net here; we certainly should not be holding
AFS_GLOCK while waiting for the server's response.
Found via FreeBSD WITNESS.
Reviewed-on: https://gerrit.openafs.org/14181
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 44b7b93b593371bfdddd0be0ae603f4f8720f78b)
Change-Id: I186e08c89136cc3109fd2519bb0d2abbb52f9ba0
Reviewed-on: https://gerrit.openafs.org/14391
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 02fb067d3fded0eee5c9326c56e66b512a75d71c
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Mon Mar 23 09:46:05 2020 -0400
build: remove unused LINUX_PKGREL from configure.ac
This change removes the unused LINUX_PKGREL definition from the
configure.ac file.
Commit 6a27e228bac196abada96f34ca9cd57f32e31f5c converted the setting of
the RPM package version and release values in the openafs.spec file from
autoconf to the makesrpm.pl script. That commit left LINUX_PKGREL in
configure.ac because it was still referenced by the Debian packaging,
which was still in-tree at that time.
Commit ada9dba0756450993a8e57c05ddbcae7d1891582 removed the last trace
of the Debian packaging, but missed the removal of the LINUX_PKGREL.
Reviewed-on: https://gerrit.openafs.org/14117
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8ae4531c5720baff9e11e4b05706eab6c82de5f9)
Conflicts:
configure.ac
Change-Id: I69925f89c52aef32aea5bc308140936517b1aeb0
Reviewed-on: https://gerrit.openafs.org/14363
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>
commit 2f2cbff766650e7c25eb332d5385f4a3fca8676d
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Apr 20 13:03:15 2020 -0500
ubik: Avoid unlinking garbage during recovery
In urecovery_Interact, if any of our operations fail around
calling DISK_GetFile, we will jump to FetchEndCall and eventually
unlink 'pbuffer'. But if we failed before opening our .DB0.TMP file,
the contents of 'pbuffer' will not be initialized yet.
During most iterations of the recovery loop, the contents of 'pbuffer'
will be filled in from previous loops, and it should always stay the
same, so it's not a big problem. But if this is the first iteration of
the loop, the contents of 'pbuffer' may be stack garbage.
Solve this in two ways. To make sure we don't use garbage contents in
'pbuffer', memset the whole thing to zeroes at the beginning of
urecovery_Interact(). And then to make sure we're not reusing
'pbuffer' contents from previous iterations of the loop, also clear
the first character to NUL each time we arrive at this area of the
recovery code. And avoid unlinking anything if pbuffer starts with a
NUL.
Commit 44e80643 (ubik: Avoid unlinking garbage) fixes the same issue,
but only fixed it in the SDISK_SendFile codepath in remote.c.
Reviewed-on: https://gerrit.openafs.org/14153
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 98b5ffb52117aefac5afb47b30ce9b87eb2fdebf)
Change-Id: I5cadb88e466ddd326ef1e4138d5b1bf89fdb27dc
Reviewed-on: https://gerrit.openafs.org/14365
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 8993e35578e4ae51dd5e8941f77c18bb975e51af
Author: Andrew Deason <adeason@sinenomine.net>
Date: Fri Sep 18 14:03:37 2020 -0600
WINNT: Make opr_threadname_set a no-op
We don't supply an implementation for opr_threadname_set for WINNT;
don't pretend that we do.
Reviewed-on: https://gerrit.openafs.org/13817
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f895a9b51671ffdc920fd9b4284337c5b737a0ef)
Change-Id: Ie8df82550f5420e2b024dea29aae0e39e3ee506f
Reviewed-on: https://gerrit.openafs.org/14369
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 045a97dfbc8dd6a2794b74e16f47984dc5f8eccf
Author: Andrew Deason <adeason@sinenomine.net>
Date: Fri Sep 18 12:11:36 2020 -0600
Move afs_pthread_setname_self to opr
Move the functionality in afs_pthread_setname_self from libutil to
opr, in a new function opr_threadname_set. This allows us to more
easily use the routine in more subsystems, since most code already
uses opr.
Reviewed-on: https://gerrit.openafs.org/13655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9d28f7390332c92b3d9e863c6fe70c26db28b5ad)
Change-Id: Ic6bbb615bc3494a7a114a0f4cae711b65ebec111
Reviewed-on: https://gerrit.openafs.org/14368
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 41f4bb48741065da6a69ffcb05e451e5c7dac757
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Mon Aug 31 19:56:56 2020 +0000
Revert "vos: take RO volume offline during convertROtoRW"
This reverts commit 32d35db64061e4102281c235cf693341f9de9271. While that
commit did fix the mentioned problem, depending on "vos" to set the
volume to be converted as "out of service" is not ideal. Instead, this
volume should be set as offline by the SAFSVolConvertROtoRWvolume RPC,
executed on the volume server.
The proper fix for this problem will be introduced by another commit.
Reviewed-on: https://gerrit.openafs.org/14339
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 85893ac3df0c2cb48776cf1203ec200507b6ce7d)
Change-Id: Ie125d2dae1301ca5a4f8323099e6e42bc57b6d28
Reviewed-on: https://gerrit.openafs.org/14361
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>
commit 29cdc0af10cb2a0f4cb4d1b05e72d6f066a1a7a5
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Apr 15 05:33:00 2020 -0500
LINUX: Always crref after _settok_setParentPag
Commit b61eac78 (Linux: setpag() may replace credentials) changed
PSetTokens2 to call crref() after _settok_setParentPag(), since
changing the parent PAG may change our credentials structure. But that
commit did not update the old pioctl PSetTokens, so -setpag
functionality remained broken on Linux for utilities that called the
old pioctl ('klog' is one such utility).
To fix this, we could copy the same code from PSetTokens2 into
PSetTokens. But instead just move this code into _settok_setParentPag
itself, to avoid code duplication. This commit also refactors
_settok_setParentPag a little to make the platform-specific ifdefs a
little easier to read through.
Reviewed-on: https://gerrit.openafs.org/14147
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
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 8002a46125e8224ba697c194edba5ad09e4cfc44)
Change-Id: I6a9d10428fe470cb38e3ca669f273dde0fa9c875
Reviewed-on: https://gerrit.openafs.org/14328
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>
commit 9553128008c7656d78759aa685a574906d352f3c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Apr 15 05:33:00 2020 -0500
LINUX: Copy session keys to parent in SetToken
Commit 48589b5d (Linux: Restore aklog -setpag functionality for kernel
2.6.32+) added code to SetToken() to copy our session keyring to the
parent process, in order to implement -setpag functionality. But this
was removed from SetToken() in commit 1a6d4c16 (Linux: fix aklog
-setpag to work with ktc_SetTokenEx), when the same code was moved to
ktc_SetTokenEx().
Add this code back to SetTokens(), so -setpag functionality can work
again with utilities that use older functions like ktc_SetToken, like
'klog'.
Reviewed-on: https://gerrit.openafs.org/14146
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 826bb826274e48c867b41cb948d031a423373901)
Change-Id: I1ae90d92efa27bce2ff59ff9b9dcca370eaf4730
Reviewed-on: https://gerrit.openafs.org/14327
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>
commit 01dfdf2608c5643714da61950637c1e7d1994023
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Fri Aug 21 01:54:00 2020 +0530
afs: Avoid NatPing event on all connection
Inside release_conns_user_server, connection vector is traversed and after
destroying a connection new eligible connection is found on which NatPing
event will be set. Ideally there should be only one connection on which
NatPing should be set but in current code while traversing all connection
of server a NatPing event is set on all connections to that server. In
cases where we have large number of connection to a server this can lead
to huge number of “RX_PACKET_TYPE_VERSION” packets sent to a server.
Since this happen during Garbage collection of user structs, to simulate
this issue below steps were tried
- had one script which “cd” to a volume mount and then script sleeps for
large time.
- Ran one infinite while loop where above script was called using PAG
based tokens (As new connection will be created for each PAG)
- Instrumented the code, so that we hit above code segment where NatPing
event is set. Mainly reduced NOTOKTIMEOUT to 60 sec.
To fix this issue set NatPing on one connection and once it is set break
from “for” loop traversing the server connection.
Reviewed-on: https://gerrit.openafs.org/14312
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit b968875a342ba8f11378e76560b46701f21391e8)
Change-Id: I8c70108ab3eb73ed1d9e598381bc29b87ca42aa0
Reviewed-on: https://gerrit.openafs.org/14364
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>
commit e4103743d91bcdba1c57c850eb07b0b03abe72d6
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Jun 22 22:54:52 2020 -0500
volser: Don't NUL-pad failed pread()s in dumps
Currently, the volserver SAFSVolDump RPC and the 'voldump' utility
handle short reads from pread() for vnode payloads by padding the
missing data with NUL bytes. That is, if we request 4k of data for our
pread() call, and we only get back 1k of data, we'll write 1k of data
to the volume dump stream followed by 3k of NUL bytes, and log
messages like this:
1 Volser: DumpFile: Error reading inode 1234 for vnode 5678
1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960
This can happen if we hit EOF on the underlying file sooner than
expected, or if the OS just responds with fewer bytes than requested
for any reason.
The same code path tries to do the same NUL-padding if pread() returns
an error (for example, EIO), padding the entire e.g. 4k block with
NULs. However, in this case, the "padding" code often doesn't work as
intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k
in this example), like so:
if (n < howMany)
Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and
so compilers will promote 'n' to the unsigned type, causing this
conditional to fail when n is -1. As a result, all of the relevant log
messages are skipped, and the data in the dumpstream gets corrupted
(we skip a block of data, and our 'howFar' offset goes back by 1). So
this can result in rare silent data corruption in volume dumps, which
can occur during volume releases, moves, etc.
To fix all of this, remove this bizarre NUL-padding behavior in the
volserver. Instead:
- For actual errors from pread(), return an error, like we do for I/O
errors in most other code paths.
- For short reads, just write out the amount of data we actually read,
and keep going.
- For premature EOF, treat it like a pread() error, but log a slightly
different message.
For the 'voldump' utility, the padding behavior can make sense if a
user is trying to recover volume data offline in a disaster recovery
scenario. So for voldump, add a new switch (-pad-errors) to enable the
padding behavior, but change the default behavior to bail out on
errors.
Reviewed-on: https://gerrit.openafs.org/14255
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4498bd8179e5e93a33468be3c8e7a30e569d560a)
Change-Id: Idf89d70c9d4d650dbf7b73e67c5b71b9bab7c3f4
Reviewed-on: https://gerrit.openafs.org/14367
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 9947625a1d67b4ffdc0582e9081000e34be2b46b
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri May 15 12:01:44 2020 -0400
vos: avoid CreateVolume when restoring over an existing volume
Currently, the UV_RestoreVolume2 function always attempts to create a
new volume, even when doing a incremental restore over an existing
volume. When the volume already exists, the volume creation operation
fails on the volume server with a VVOLEXISTS error. The client will then
attempt to obtain a transaction on the existing volume. If a transaction
is obtained, the incremental restore operation will proceed. If a full
restore is being done, the existing volume is removed and a new empty
volume is created.
Unfortunately, the failed volume creation is logged to by the volume
server, and so litters the log file with:
Volser: CreateVolume: Unable to create the volume; aborted, error code 104
To avoid polluting the volume server log with these messages, reverse
the logic in UV_RestoreVolume2. Assume the volume already exists and try
to get the transaction first when doing an incremental restore. Create a
new volume if the transaction cannot be obtained because the volume is
not present. When doing a full restore, remove the existing volume, if
one exists, and then create a new empty volume.
Reviewed-on: https://gerrit.openafs.org/14208
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
Tested-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f5051b87a56b3a4f7fd7188cbd16a663eee8abbf)
Change-Id: I422b81e0c800ff655ac8851b2872f4d7160d79a8
Reviewed-on: https://gerrit.openafs.org/14326
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>
commit 967aa95fe23f98c911b8a618132442159eda3f77
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Wed Apr 29 05:10:05 2020 +0000
rxkad: Use krb5_enctype_keysize in tkt_DecodeTicket5
Inside tkt_DecodeTicket5 (rxkad/ticket5.c) function, keysize is calculated
using krb5_enctype_keybits and then dividing number of bits by 8. For 3DES
number of keybits are 168, so keysize comes out to 21(168/8). However
actual keysize of 3DES key is 24. This keysize is passed to
_afsconf_GetRxkadKrb5Key where keysize comparison happens, since there is
keysize mismatch it returns AFSCONF_BADKEY.
To fix this issue get keysize from krb5_enctype_keysize function instead
of krb5_enctype_keybits. Thanks to John Janosik (jpjanosi@us.ibm.com)
for analyzing and fixing this issue.
Reviewed-on: https://gerrit.openafs.org/14203
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5d53ed0bdab6fea6d2426691bdef2b6f9cb7f2fe)
Change-Id: I16cd7a803a139802671a8045dac09e10ef4ad6cb
Reviewed-on: https://gerrit.openafs.org/14325
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>
commit 28e96b954fe17810d1ebdd9fdd4702511e870a67
Author: Jan Iven <iven.jan@gmail.com>
Date: Tue Sep 1 14:51:25 2020 +0200
ptserver: Remove duplicate ubik_SetLock in listSuperGroups
It looks like a call to ubik_SetLock(.. LOCKREAD) was left in
place in listSuperGroups after locking was moved to ReadPreamble
in commit a6d64d70 (ptserver: Refactor per-call ubik initialisation)
When compiled with 'supergroups', and once contacted by
"pts mem -expandgroups ..", ptserver will therefore abort() with
Ubik: Internal Error: attempted to take lock twice
This patch removes the superfluous ubik_SetLock.
FIXES 135147
Reviewed-on: https://gerrit.openafs.org/14338
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 696f2ec67b049639abf04905255a7d6173dbb19e)
Change-Id: I62bfe44e374b398278658b61f2ecf9a66fab18ae
Reviewed-on: https://gerrit.openafs.org/14345
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit c7a3154382376ca2e5effdfed2c447c86b9f6eed
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Wed Jul 1 21:50:09 2020 -0400
redhat: Add make to the dkms-openafs pre-requirements
If `make` is not installed before dkms-openafs, the OpenAFS kernel
module is not built during the dkms-openafs package installation.
The failure happens in the "checking if linux kernel module build works"
configure step, which invokes `make` to check the linux buildsystem.
configure fails when `make` is not available, and gives the unhelpful
suggestion (in this case) of configuring with --disable-kernel module.
Running the configure.log in the dkms build directory shows:
configure:7739: checking if linux kernel module build works
make -C /lib/modules/4.18.0-193.6.3.el8_2.x86_64/build M=/var/lib/dkms/openafs/...
./configure: line 7771: make: command not found
configure: failed using Makefile:
Avoid this build failure by adding `make` to the list of dkms-openafs
package pre-requirements.
Reviewed-on: https://gerrit.openafs.org/14266
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e61ab9353e99d3298815296abf6b02c50ebe3df0)
Change-Id: I9b2bb73acabfabc1cf8b5514c8aa66572cc96066
Reviewed-on: https://gerrit.openafs.org/14314
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ddaf6a74ff3e0aeb4c8b2b15886eaa5c90db59bf
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Aug 28 10:32:01 2020 -0600
INSTALL: document the minimum Linux kernel level
The change associated with gerrit #14300 removed support for older
Linux kernels (2.6.10 and earlier).
The commit 'Import of code from autoconf-archive' (d8205bbb4) introduced
a check for Autoconf 2.64. Autoconf 2.64 was released in 2009.
The commit 'regen.sh: Use libtoolize -i, and .gitignore generated
build-tools' (a7cc505d3) introduced a dependency on libtool's '-i'
option. Libtool supported the '-i' option with libtool 1.9b in 2004.
Update the INSTALL instructions to document a minimum Linux kernel
level and the minimum levels for autoconf and libtool.
Notes: RHEL4 (EOL in 2017) had a 2.6.9 kernel and RHEL5 has a 2.6.18
kernel. RHEL5 has libtool 1.5.22 and autoconf 2.59, RHEL6 has libtool
2.2.6 and autoconf 2.63, and RHEL7 has libtool 2.4.2 and autoconf 2.69.
Reviewed-on: https://gerrit.openafs.org/14305
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 16bae98ec525fa013514fb46398df682d7637ae0)
Change-Id: I7aaf434928204df77851dd2d651d43b86f5b53d2
Reviewed-on: https://gerrit.openafs.org/14331
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fee39617c350623dc659e7a21287a1791bdff5d2
Author: Andrew Deason <adeason@sinenomine.net>
Date: Wed Apr 1 22:59:38 2020 -0500
vos: Print "done" in non-verbose 'vos remsite'
Currently, 'vos remsite' always prints the message "Deleting the
replication site for volume %lu ...", and then calls VDONE if the
operation is successful. VDONE prints the trailing "done", but only if
-verbose is turned on, and so if -verbose is not specified, the output
of 'vos remsite' looks broken:
$ vos remsite fs1 vicepa vol.foo
Deleting the replication site for volume 1234 ...Removed replication site fs1 /vicepa for volume vol.foo
To fix this, unconditionally print the trailing "done", instead of
going through VDONE, so 'vos remsite' output now looks like this:
$ vos remsite fs1 vicepa vol.foo
Deleting the replication site for volume 1234 ... done
Removed replication site fs1 /vicepa for volume vol.foo
Reviewed-on: https://gerrit.openafs.org/14127
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f16d40ad26df3ec871f8c73952594ad2e723c9b4)
Change-Id: I4cd7cb2156391004e57cd42437d7174a6bd70992
Reviewed-on: https://gerrit.openafs.org/14311
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ff5b64d074376992d0be02e19b4da789c20d6bab
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date: Thu Feb 13 00:39:00 2020 -0300
vos: take RO volume offline during convertROtoRW
The vos convertROtoRW command converts a RO volume into a RW volume.
Unfortunately, the RO volume in question is not set as "out of service"
during this process. As a result, accesses to the volume being converted
can leave volume objects in an inconsistent state.
Consider the following scenario:
1. Create a volume on host_b and add replicas on host_a and host_b.
$ vos create host_b a vol_1
$ vos addsite host_b a vol_1
$ vos addiste host_a a vol_1
2. Mount the volume:
$ fs mkmount /afs/.mycell/vol_1 vol_1
$ vos release vol_1
$ vos release root.cell
3. Shutdown dafs on host_b:
$ bos shutdown host_b dafs
4. Remove RO reference to host_b from the vldb:
$ vos remsite host_b a vol_1
5. Attach the RO copy by touching it:
$ fs flushall
$ ls /afs/mycell/vol_1
6. Convert RO copy to RW:
$ vos convertROtoRW host_a a vol_1
Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving
the volume object for the RO copy set as VOL_STATE_ATTACHED (on success,
this volume should be set as VOL_STATE_DELETED).
7. Add replica on host_a:
$ vos addsite host_a a vol_1
8. Wait until the "inUse" flag of the RO entry is cleared (or force this
to happen by attaching multiple volumes).
9. Release the volume:
$ vos release vol_1
Failed to start transaction on volume 536870922
Volume not attached, does not exist, or not on line
Error in vos release command.
Volume not attached, does not exist, or not on line
To fix this problem, take the RO volume offline during the vos
convertROtoRW operation.
Reviewed-on: https://gerrit.openafs.org/14066
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 32d35db64061e4102281c235cf693341f9de9271)
Change-Id: Ie4cfab2f04a8859ddfcaece371198ac544066770
Reviewed-on: https://gerrit.openafs.org/14310
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 696d9ce83e3556bda2d3945326937c63dd3560ed
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Tue Apr 19 20:46:33 2016 -0400
ubik: positional io for db reads and writes
The ubik library was written before positional i/o was available and
issues an lseek system call for each database file read and write. This
change converts the ubik database accesses to use positional i/o on
platforms where pread and pwrite are available, in order to reduce
system call load.
The new inline uphys_pread and uphys_pwrite functions are supplied on
platforms which do not supply pread and pwrite. These functions fall
back to non-positional i/o. If these symbols are present in the database
server binary then the server process will continue to call lseek before
each read and write access of the database file.
This change does not affect the whole-file database synchronization done
by ubik during database recovery (via the DISK_SendFile and DISK_GetFile
RPCs), which still uses non-positional i/o. However, that code does not
share file descriptors with the phys.c code, so there is no possibility
of mixing positional and non-positional i/o on the same FDs.
Reviewed-on: https://gerrit.openafs.org/12272
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit f62fb17b3cf1c886f8cfc2fabe9984070dd3eec4)
Change-Id: Iccc8f749c89659f4acebd74a1115425f69610ba8
Reviewed-on: https://gerrit.openafs.org/14142
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fffd6e07c87e36cd9a4a36858c3df0c282622195
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Wed Apr 20 18:17:16 2016 -0400
ubik: remove unnecessary lseeks in uphys_open
The ubik database file access layer has a file descriptor cache to avoid
reopening the database file on each file access. However, the file
offset is reset with lseek on each and every use of the cached file
descriptor, and the file offset is set twice when reading or writing
data records.
This change removes unnecessary and duplicate lseek system calls to
reduce the system call load.
Reviewed-on: https://gerrit.openafs.org/12271
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 6892bfbd701899281b34ee337637d438c7d8f8c6)
Change-Id: I5ea7857796d94eb5b659d868e79b9fea2411f301
Reviewed-on: https://gerrit.openafs.org/14141
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 438bc2c4caf96485e12eda9e7591fc4bd887ebad
Author: Andrew Deason <adeason@sinenomine.net>
Date: Thu Nov 9 12:47:57 2017 -0600
asetkey: Add new 'delete' command variants
The current 'delete' command from asetkey only lets the user delete
old-style rxkad keys. Add a couple of new variants to allow specifying
the key type and subtype, so the user can delete specific key types
and enctypes if they want.
Reviewed-on: https://gerrit.openafs.org/12767
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 5120409cc998284f2fb0467c2f88030976140341)
Change-Id: I8c762839b50f4faf5e583fb5c510bf2ff9dd2259
Reviewed-on: https://gerrit.openafs.org/14293
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 1c395cd1bcf5770f70dce36ef29f9bd7ba98acaa
Author: Kailas Zadbuke <kailashsz@in.ibm.com>
Date: Thu May 7 23:55:39 2020 -0400
salvaged: Fix "-parallel all<number>" parsing
In salavageserver -parallel option takes "all<number>" argument.
However the code does not parse the numeric part correctly. Due
to this, only single instance of salvageserver process was running
even if we provide the larger number with "all" argument.
With this fix, numeric part of "all" argument will be parsed
correctly and will start required number of salvageserver instances.
Reviewed-on: https://gerrit.openafs.org/14201
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4512d04a9b721cd9052c0e8fe026c93faf6edb9e)
Change-Id: I8910fb514986a404b22256e8a514955a684c8a27
Reviewed-on: https://gerrit.openafs.org/14285
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 38f7e123c33c1c11eb275e0619080ee874244afd
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Tue Jun 16 15:20:20 2020 -0600
tests: Use usleep instead of nanosleep
Commit "Build tests by default" 68f406436cc21853ff854c514353e7eb607cb6cb
changes the build so tests are always built.
On Solaris 10 the build fails because nanosleep is in librt, which we do
not link against.
Replace nanosleep with usleep. This avoids introducing extra configure
tests just for Solaris 10.
Note that with Solaris 11 nanosleep was moved from librt to libc, the
standard C library.
Reviewed-on: https://gerrit.openafs.org/14244
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 22a66e7b7e1d73437a8c26c2a1b45bc4ef214e77)
Change-Id: Ic24c5a149451955b5c130e7b36cec27e02688d83
Reviewed-on: https://gerrit.openafs.org/14291
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 264d6b786c2fd0aff0e4abe835e42868f936afce
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Mar 24 11:59:48 2020 -0500
tests: Wait for server start in auth/superuser-t
The auth/superuser-t test runs an Rx server and client in two child
processes. If the client process tries to contact the server before
the server has started listening on its port, some tests involving
RPCs can fail (notably test 39, "Can run a simple RPC").
Normally if we try to contact a server that's not there, Rx will try
resending its packets a few times, but on Linux with AFS_RXERRQ_ENV,
if the port isn't open at all, we can get an ICMP_PORT_UNREACH error,
which causes the relevant Rx call to die immediately with
RX_CALL_DEAD.
This means that if the auth/superuser-t client is only just a bit
faster than the server starting up, tests can fail, since the server's
port is not open yet.
To avoid this, we can wait until the server's port is open before
starting the client process. To do this, have the server process send
a SIGUSR1 to the parent after rx_Init() is called, and have the parent
process wait for the SIGUSR1 (waiting for a max of 5 seconds before
failing). This should guarantee that the server's port will be open by
the time the client starts running.
Note that before commit 086d1858 (LINUX: Include linux/time.h for
linux/errqueue.h), AFS_RXERRQ_ENV was mistakenly disabled on Linux
3.17+, so this issue was probably not possible on recent Linux before
that commit.
Reviewed-on: https://gerrit.openafs.org/14109
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
(cherry picked from commit 66d0f91791695ac585f0511d0dadafd4e570b1bf)
Change-Id: Ia6c06ca9a05e33b3bc35238d9c0d18e7ff339438
Reviewed-on: https://gerrit.openafs.org/14290
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit eaa552d27074cd7e1c862d606916b063e6d89a27
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Dec 31 12:04:48 2019 -0600
tests: Introduce afstest_GetProgname
Currently, in tests/volser/vos-t.c we call afs_com_err as
"authname-t", which is clearly a mistake during some code refactoring
(introduced in commit 2ce3fdc5, "tests: Abstract out code to produce a
Ubik client").
We could just change this to "vos-t", but instead of specifying
constant strings everywhere, change this to figure out what the
current command is called, and just use that. Put this code into a new
function, afstest_GetProgname, and convert existing tests to use that
instead of hard-coding the program name given to afs_com_err.
Reviewed-on: https://gerrit.openafs.org/13991
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a21a2f8edb79d6190976e920a9a90d0878411146)
Change-Id: I3d410d6de132f8a0fffeb9cce32a912fe3bbdc20
Reviewed-on: https://gerrit.openafs.org/14289
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fe57174d84cab19a13eea9a8f31f0ac71c8cf838
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Wed Aug 5 09:23:36 2020 -0600
butc: fix int to float conversion warning
Building with clang-10 results in 2 warnings/errors associated with
with trying to convert 0x7fffffff to a floating point value.
tcmain.c:240:18: error: implicit conversion from 'int' to 'float'
changes value from 2147483647 to 2147483648 [-Werror,
-Wimplicit-int-float-conversion]
if ((total > 0x7fffffff) || (total < 0)) /* Don't go over 2G */
and the same conversion warning on the statement on the following line:
total = 0x7fffffff;
Use floating point and decimal constants instead of the hex constants.
For the test, use 2147483648.0 which is cleanly represented by a float.
Change the comparison in the test from '>' to '>='.
If the total value exceeds 2G, just assign the max value directly to the
return variable.
Reviewed-on: https://gerrit.openafs.org/14277
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 37b55b30c65d0ab8c8eaabfda0dbd90829e2c46a)
Change-Id: I16e0acd893049b01a2c5e4c7e71de3fa40e28d3e
Reviewed-on: https://gerrit.openafs.org/14299
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit e7902252f15acfc28453c531f6fa3b29c9c91b92
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Aug 21 10:37:51 2020 -0600
LINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL
Linux-5.9-rc1 commit 'fs: remove the HAVE_UNLOCKED_IOCTL and
HAVE_COMPAT_IOCTL defines' (4e24566a) removed the two referenced macros
from the kernel.
The support for unlocked_ioctl and compat_ioctl were introduced in
Linux 2.6.11.
Remove references to HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL using
the assumption that they were always defined.
Notes:
With this change, building against kernels 2.6.10 and older will fail.
RHEL4 (EOL in March 2017) used a 2.6.9 kernel. RHEL5 uses a 2.6.18
kernel.
In linux-2.6.33-rc1 the commit messages for "staging: comedi:
Remove check for HAVE_UNLOCKED_IOCTL" (00a1855c) and "Staging: comedi:
remove check for HAVE_COMPAT_IOCTL" (5d7ae225) both state that all new
kernels have support for unlocked_ioctl/compat_ioctl so the checks can
be removed along with removing support for older kernels.
Reviewed-on: https://gerrit.openafs.org/14300
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 13a49aaf0d5c43bce08135edaabb65587e1a8031)
Change-Id: I6dc5ae5b32031641f4a021a31630390a91d834fe
Reviewed-on: https://gerrit.openafs.org/14315
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 99232fa48020bde90f6b245da4374bc63399654f
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Wed Aug 5 09:19:02 2020 -0600
afs: Set AFS_VFSFSID to a numerical value
Currently when UKERNEL is defined, AFS_VFSFSID is always set to
AFS_MOUNT_AFS, which is a string for many platforms for UKERNEL.
Update src/afs/afs.h to insure that the define for AFS_VFSFSID is a
numeric value when building UKERNEL.
Clean up the preprocessor indentation in src/afs/afs.h in the area
around the AFS_VFSFSID defines.
Thanks to adeason@sinenomine.net for pointing out a much easier solution
for resolving this problem.
Reviewed-on: https://gerrit.openafs.org/14279
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 446457a1240b88fd94fc34ff5715f2b7f2f3ef12)
Change-Id: Ic0f9c2f1f4baeb9f99da19e1187f1bc9f5d7f824
Reviewed-on: https://gerrit.openafs.org/14297
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 7e2a62fb594a7713a5c694b9e0401b5e3c2648c8
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Wed Aug 5 09:18:49 2020 -0600
afs: Avoid using logical OR when setting f_fsid
Building with clang-10 produces the warning/error message
warning: converting the result of '<<' to a boolean always evaluates
to true [-Wtautological-constant-compare]
for the expression
abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;
The message is because a logical OR '||' is used instead of a bitwise
OR '|'. The result of this expression will always set the f_fsid
member to a 1 and not the intended value of AFS_VFSMAGIC combined with
AFS_VFSFSID.
Update the expression to use a bitwise OR instead of the logical OR.
Note: This will change value stored in the f_fsid that is returned from
statfs.
Using a logical OR has existed since OpenAFS 1.0 for hpux/solaris and in
UKERNEL since OpenAFS 1.5 with the commit 'UKERNEL: add uafs_statvfs'
b822971a.
Reviewed-on: https://gerrit.openafs.org/14292
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c56873bf95f6325b70e63ed56ce59a3c6b2b753b)
Change-Id: I2e3fe6a84ef6ce73fff933f137d4806efefa5949
Reviewed-on: https://gerrit.openafs.org/14298
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit fc32922236122b9013ed9bdedda8c54c2e8c75d8
Author: Andrew Deason <adeason@sinenomine.net>
Date: Fri May 1 15:02:08 2020 -0500
vlserver: Return error when growing beyond 2 GiB
In the vlserver, when we add a new vlentry or extent block, we grow
the VLDB by doing something like this:
vital_header.eofPtr += sizeof(item);
Since we don't check for overflow, and all of our offset-related
variables are signed 32-bit integers, this can cause some odd behavior
if we try to grow the database to be over 2 GiB in size.
To avoid this, change the two places in vlserver code that grow the
database to use a new function, grow_eofPtr(), which checks for 31-bit
overflow. If we are about to overflow, log a message and return an
error.
See the following for a specific example of our "odd behavior" when we
overflow the 2 GiB limit in the VLDB:
With 1 extent block, we can create 14509076 vlentries successfully. On
the 14509077th vlentry, we'll attempt to write the entry to offset
2147483560 (0x7FFFFFA8). Since a vlentry is 148 bytes long, we'll
write all the way through offset 2147483707 (0x8000003B), which is
over the 31-bit limit.
In the udisk subsystem, this results in writing to page numbers
2097151, and -2097152 (since our ubik pages are 1k, and going over the
31-bit limit causes us to treat offsets as negative). These pages
start at physical offsets 2147482688 (0x7FFFFC40) and -2147483584
(-0x7FFFFFC0) in our vldb.DB0 (where offset is page*1024+64).
Modifying each of these pages involves reading in the existing page
first, modifying the parts we are changing, and writing it back. This
works just fine for 2097151, but of course fails for -2097152. The
latter fails in DReadBuffer when eventually our pread() fails with
EINVAL, and causes ubik to log the message:
Ubik: Error reading database file: errno=22
But when DReadBuffer fails, DReadBufferForWrite assumes this is due to
EOF, and just creates a new buffer for the given page (DNewBuffer).
So, the udisk_write() call ultimately succeeds.
When we go to flush the dirty data to disk when committing the
transaction, after we have successfully written the transaction log,
DFlush() fails for the -2097152 page when the pwrite() call eventually
fails with EINVAL, causing ubik to panic, logging the messages:
Ubik PANIC:
Writing Ubik DB modifications
When the vlserver gets restarted by bosserver, we then process the
transaction log, and perform the operations in the log before starting
up (ReplayLog). The log records the actual data we wrote, not split
into pages, and the log-replaying code writes directly to the db
usying uphys_write instead of udisk_write. So, because of this, the
write actually succeeds when replaying the log, since we just write
148 bytes to offset 2147483624 (0x7FFFFFE8), and no negative offsets
are used.
The vlserver will then be able to run, but will be unable to read that
newly-created vlentry, since it involves reading a ubik page beyond
the 31-bit boundary. That means trying to lookup that entry will fail
with i/o errors, and as well as any entry on the same hash chains as
the new entry (since the new entry will be added to the head of the
hash chain). Listing all entries in the database will also just show
an empty database, since our vital_header.eofPtr will be negative, and
we determine EOF by comparing our current blockindex to the value in
eofPtr.
Reviewed-on: https://gerrit.openafs.org/14180
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
(cherry picked from commit d01398731550b8a93b293800642c3e1592099114)
Change-Id: I72302a8c472b3270e99e58a573f5cf25dd34b9c5
Reviewed-on: https://gerrit.openafs.org/14288
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 03979eaa174de0cff188af451806fb7ae10d3a62
Author: Andrew Deason <adeason@sinenomine.net>
Date: Tue Apr 7 13:15:31 2020 -0500
vlserver: Correctly pad nvlentry for "O" RPCs
For our old-style "O" RPCs (e.g. VL_CreateEntry, instead of
VL_CreateEntryN), vlserver calls vldbentry_to_vlentry to convert to
the internal 'struct nvlentry' format. After all of the sites have
been copied to the internal format, we fill the remaining sites by
setting the serverNumber to BADSERVERID. For nvldbentry_to_vlentry, we
do this for NMAXNSERVERS sites, but for vldbentry_to_vlentry, we do
this for OMAXNSERVERS.
The thing is, both functions are filling in entries for a 'struct
nvlentry', which has NMAXNSERVERS 'serverNumber' entries. So for
vldbentry_to_vlentry, we are skipping setting the last few sites
(specifically, NMAXNSERVERS-OMAXNSERVERS = 13-8 = 5).
This can easily cause our O-style RPCs to write out entries to disk
that have uninitialized sites at the end of the array. For example, an
entry with one site should have server numbers that look like this:
serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255}
That is, one real serverid (a '1' here), followed by twelve
BADSERVERIDs.
But for a VL_CreateEntry call, the 'struct nvlentry' is zeroed out
before vldbentry_to_vlentry is called, and so the server numbers in
the written entry look like this:
serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0}
That is, one real serverid (a '1' here), followed by seven
BADSERVERIDs, followed by five '0's.
Most of the time, this is not noticeable, since our code that reads in
entries from disk stops processing sites when we encounter the first
BADSERVERID site (see vlentry_to_nvldbentry). However, if the entry
has 8 sites, then none of the entries will contain BADSERVERID, and so
we will actually process the trailing 5 bogus sites. This would appear
as 5 extra volume sites for a volume, most likely all for the same
server.
For VL_CreateEntry, the vlentry struct is always zeroed before we use
it, so the trailing sites will always be filled with 0. For
VL_ReplaceEntry, the trailing sites will be unchanged from whatever
was read in from the existing disk entry.
To fix this, just change the relevant loop to go through NMAXNSERVERS
entries, so we actually go to the end of the serverNumber (et al)
array.
This may appear similar to commit ddf7d2a7 (vlserver: initialize
nvlentry elements after read). However, that commit fixed a case
involving the old vldb database format (which hopefully is not being
used). This commit fixes a case where we are using the new vldb
database format, but with the old RPCs, which may still be used by old
tools.
Reviewed-on: https://gerrit.openafs.org/14139
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7e41ee0bd50d39a356f0435ff370a0a7be40306f)
Change-Id: I68ecc41e7268efd0424e6c129aa914cd04115b59
Reviewed-on: https://gerrit.openafs.org/14287
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 986ee1fd422d1608553af5a6a02bd60349b864ac
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jun 19 08:01:14 2020 -0600
afs: Avoid panics on failed return from afs_CFileOpen
afs_CFileOpen is a macro that invokes the open "method" of the
afs_cacheOps structure, and for disk caches the osi_UFSOpen function is
used.
Currently osi_UFSOpen will panic if there is an error encountered while
opening a file.
Prepare to handle osi_UFSOpen function returning a NULL instead of
issuing a panic (future commit).
Update callers of afs_CFileOpen to test for an error and to return an
error instead of issuing a panic.
While this commit eliminates some panics, it does not address some of the
more complex cases associated with errors from afs_CFileOpen.
Reviewed-on: https://gerrit.openafs.org/14241
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d2d27f975df13c3833898611dacff940a5ba3e2a)
Change-Id: Ia30711748b3cffd56eb3120961aa1747dfae0f23
Reviewed-on: https://gerrit.openafs.org/14286
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit a00fe9fd4253b2436ae649b05b329d0d52c8b6f6
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date: Thu Mar 5 07:21:55 2020 +0000
LINUX: Initialize CellLRU during osi_Init
When OpenAFS kernel module gets loaded, it will create certain entries
in "proc" filesystem. One of those entries is "CellServDB", in case
we read "/proc/fs/openafs/CellServDB" without starting "afsd" it will
result in crash with NULL pointer deref. The reason for crash is
CellLRU has not been initialized yet (since "afsd" is not started)
i.e afs_CellInit is not yet called, because of this "next" and "prev"
pointers will be NULL. Inside "c_start()" we do not check for NULL
pointer while traversing CellLRU and this causes crash.
To avoid this initialize CellLRU during module intialization.
Reviewed-on: https://gerrit.openafs.org/14093
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8d90a9d27b0ef28ddcdd3eb041c8a9d019b84b50)
Change-Id: I9ed97d3751943331c9d9bc9dfc73acc24231187b
Reviewed-on: https://gerrit.openafs.org/14284
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 6824d45c2ab83e52350c3f366e4cb6f1eb263088
Author: Kailas Zadbuke <kailashsz@in.ibm.com>
Date: Wed Jun 3 15:44:08 2020 +0530
util: Handle serverLogMutex lock across forks
If a process forks when another thread has serverLogMutex locked, the
child process inherits the locked serverLogMutex. This causes a deadlock
when code in the child process tries to lock serverLogMutex, since we
can never unlock serverLogMutex because the locking thread no longer
exists. This can happen in the salvageserver, since the salvageserver
locks serverLogMutex in different threads, and forks to handle salvage
jobs.
To avoid this deadlock, we register handlers using pthread_atfork()
so that the serverLogMutex will be held during the fork. The fork will
be blocked until the worker thread releases the serverLogMutex. Hence the
serverLogMutex will be held until the fork is complete and it will be
released in the parent and child threads.
Thanks to Yadavendra Yadav(yadayada@in.ibm.com) for working with me
on this issue.
Reviewed-on: https://gerrit.openafs.org/14239
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit e44d6441c8786fdaaa1fad1b1ae77704c12f7d60)
Change-Id: I09c04c0bd99b10433857ccdaeb4ee6a4cd50f768
Reviewed-on: https://gerrit.openafs.org/14283
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 179a418ea5063785a23e4faf35134f063a6f3e1c
Author: Andrew Deason <adeason@sinenomine.net>
Date: Fri Mar 13 13:00:35 2020 -0500
LINUX: Properly revert creds in osi_UFSTruncate
Commit cd3221d3 (Linux: use override_creds when available) caused us
to force the current process's creds to the creds of afsd during
osi_file.c file ops, to avoid access errors in some cases.
However, in osi_UFSTruncate, one code path was missed to revert our
creds back to the original user's creds: when the afs_osi_Stat call
fails or deems the truncate unnecessary. In this case, the calling
process keeps the creds for afsd after osi_UFSTruncate returns,
causing our subsequent access-checking code to think that the current
process is in the same context as afsd (typically uid 0 without a
pag).
This can cause the calling process to appear to transiently have the
same access as non-pag uid 0; typically this will be unauthenticated
access, but could be authenticated if uid 0 has tokens.
To fix this, modify the early return in osi_UFSTruncate to go through
a 'goto done' destructor instead, and make sure we revert our creds in
that destructor.
Thanks to cwills@sinenomine.net for finding and helping reproduce the
issue.
Reviewed-on: https://gerrit.openafs.org/14098
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Cheyenne Wills <cwills@sinenomine.net>
(cherry picked from commit 57b4f4f9be1e25d5609301c10f717aff32aef676)
Change-Id: I714eb2dea9645ffe555f26b5d69707a7afbe8d81
Reviewed-on: https://gerrit.openafs.org/14099
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ee578e92d9f810d93659a9805d0c12084fe2bb95
Author: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Thu May 2 16:02:47 2019 -0400
Linux: use override_creds when available
Linux may perform some access control checks at the time of an I/O
operation, rather than relying solely on checks done when the file is
opened. In some cases (e.g. AppArmor), these checks are done based on
the current tasks's creds at the time of the I/O operation, not those
used when the file was open.
Because of this, we must use override_creds() / revert_creds() to make
sure we are using privileged credentials when performing I/O operations
on cache files. Otherwise, cache I/O operations done in the context of
a task with a restrictive AppArmor profile will fail.
Reviewed-on: https://gerrit.openafs.org/13751
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit cd3221d3532a28111ad22d4090ec913cbbff40da)
Change-Id: I8955ff6150462fecba9a10a8f99bce9ee8163435
Reviewed-on: https://gerrit.openafs.org/14082
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit facff58b840a47853592510617ba7a1da2e3eaa9
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jul 3 10:35:06 2020 -0600
LINUX 5.8: use lru_cache_add
With Linux-5.8-rc1 commit 'mm: fold and remove lru_cache_add_anon() and
lru_cache_add_file()' (6058eaec), the lru_cache_add_file function is
removed since it was functionally equivalent to lru_cache_add.
Replace lru_cache_add_file with lru_cache_add.
Introduce a new autoconf test to determine if lru_cache_add is present
For reference, the Linux changes associated with the lru caches:
__pagevec_lru_add introduced before v2.6.12-rc2
lru_cache_add_file introduced in v2.6.28-rc1
__pagevec_lru_add_file replaces __pagevec_lru_add in v2.6.28-rc1
vmscan: split LRU lists into anon & file sets (4f98a2fee)
__pagevec_lru_add removed in v5.7 with a note to use lru_cache_add_file
mm/swap.c: not necessary to export __pagevec_lru_add() (bde07cfc6)
lru_cache_add_file removed in v5.8
mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
(6058eaec)
lru_cache_add exported
mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
(6058eaec)
Openafs will use:
lru_cache_add on 5.8 kernels
lru_cache_add_file from 2.6.28 through 5.7 kernels
__pagevec_lru_add/__pagevec_lru_add_file on pre 2.6.28 kernels
Reviewed-on: https://gerrit.openafs.org/14249
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7d85ce221d6ccc19cf76ce7680c74311e4ed2632)
Change-Id: Iba6ef4441687dbf60d227a708e2a032c2c0dc79f
Reviewed-on: https://gerrit.openafs.org/14269
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 335f37be13d2ff954e4aeea617ee66502170805e
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jul 3 10:34:42 2020 -0600
LINUX 5.8: do not set name field in backing_dev_info
Linux-5.8-rc1 commit 'bdi: remove the name field in struct
backing_dev_info' (1cd925d5838)
Do not set the name field in the backing_dev_info structure if it is
not available. Uses an existing config test
'STRUCT_BACKING_DEV_INFO_HAS_NAME'
Note the name field in the backing_dev_info structure was added in
Linux-2.6.32
Reviewed-on: https://gerrit.openafs.org/14248
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d8ec294534fcdee77a2ccd297b4b167dc4d5573d)
Change-Id: I3d9e18092db998a4c4f26bd63ee3b75383a53d4c
Reviewed-on: https://gerrit.openafs.org/14268
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit d7fc5bf9bf031089d80703c48daf30d5b15a80ca
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri Jul 3 10:33:51 2020 -0600
LINUX 5.8: Replace kernel_setsockopt with new funcs
Linux 5.8-rc1 commit 'net: remove kernel_setsockopt' (5a892ff2facb)
retires the kernel_setsockopt function. In prior kernel commits new
functions (ip_sock_set_*) were added to replace the specific functions
performed by kernel_setsockopt.
Define new config test 'HAVE_IP_SOCK_SET' if the 'ip_sock_set' functions
are available. The config define 'HAVE_KERNEL_SETSOCKOPT' is no longer
set in Linux 5.8.
Create wrapper functions that replace the kernel_setsockopt calls with
calls to the appropriate Linux kernel function(s) (depending on what
functions the kernel supports).
Remove the unused 'kernel_getsockopt' function (used for building with
pre 2.6.19 kernels).
For reference
Linux 2.6.19 introduced kernel_setsockopt
Linux 5.8 removed kernel_setsockopt and replaced the functionality
with a set of new functions (ip_sock_set_*)
Reviewed-on: https://gerrit.openafs.org/14247
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c48072b9800759ef1682b91ff1e962f6904a2594)
Change-Id: I2724fad06b1882149d2066d13eced55eff5ee695
Reviewed-on: https://gerrit.openafs.org/14267
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 0f67e733e82a9001f3f9253c5e1880be845d537b
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Thu Apr 2 13:27:50 2020 -0600
LINUX: Include linux/time.h for linux/errqueue.h
The configuration test for errqueue.h fails with an undefined structure
error on a Linux 3.17 (or higher) system. This prevents setting
HAVE_LINUX_ERRQUEUE_H, which is used to define AFS_RXERRQ_ENV.
Linux commit f24b9be5957b38bb420b838115040dc2031b7d0c (net-timestamp:
extend SCM_TIMESTAMPING ancillary data struct) - which was picked up in
linux 3.17 added a structure that uses the timespec structure. After
this commit, we need to include linux/time.h to pull in the definition
of the timespec struct.
Reviewed-on: https://gerrit.openafs.org/13950
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 086d185872da5f19447cf5ec7846e7ce5104563f)
Change-Id: I67d01b11c5ea95b8b87832fc833f8fc850ade684
Reviewed-on: https://gerrit.openafs.org/14130
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 5a14bd0abe83b580f0cc7a200ae963399ab7de5f
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Tue May 26 12:11:28 2020 -0600
vol: Fix format-truncation warning with gcc-10.1
Building with gcc-10.1 produces a warning (error if --enable-checking)
in vol-salvage.c
error: ‘%s’ directive output may be truncated writing up to 755 bytes
into a region of size 255 [-Werror=format-truncation=]
809 | snprintf(inodeListPath, 255, "%s" OS_DIRSEP "salvage.inodes.%s.%d", tdir, name,
Use strdup/asprintf to allocate the buffer dynamically instead of using
a buffer with a hardcoded size.
Reviewed-on: https://gerrit.openafs.org/14207
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d73680c5f70ee5aeb634a9ec88bf1097743d0f76)
Change-Id: I8d3bf244a70f723f585738905deea7ddfb1bb862
Reviewed-on: https://gerrit.openafs.org/14232
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit d5fc5283e91ea94a67df8364a5b8bf8970ffe934
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Mon Oct 9 22:16:09 2017 -0400
afsmonitor: remove unused LWP_WaitProcess
Remove the unimplemented once-only flag and the unused LWP_WaitProcess
call.
Reviewed-on: https://gerrit.openafs.org/12745
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7c27365ea24aed5787f6fc03f30f6085c78ece51)
Change-Id: I3b61f9fb4f45564304b0e35878d3535a10e31d02
Reviewed-on: https://gerrit.openafs.org/14226
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>
commit a2eec64374d6b754b29c509b554573cb6e53eb46
Author: Cheyenne Wills <cwills@sinenomine.net>
Date: Fri May 22 12:16:48 2020 -0600
Avoid duplicate definitions of globals
GCC 10 changed a default flag from -fcommon to -fno-common. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 for some background.
The change in gcc 10 results in build link-time errors. For example:
../../src/xstat/.libs/liboafs_xstat_cm.a(xstat_cm.o):(.bss+0x2050):
multiple definition of `numCollections';
Ensure that only one definition for global data objects exist and change
references to use "extern" as needed.
To ensure that future changes do not introduce duplicated global
definitions, add the -fno-common flag to XCFLAGS when using the
configure --enable-checking setting.
[cwills@sinenomine.net: Note for 1.8.x: renamed terminationEvent
to cm_terminationEvent/fs_terminationEvent instead of deleting it.]
Reviewed-on: https://gerrit.openafs.org/14106
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0e2072ae386d4111bef161eb955964b649c31386)
Change-Id: I54ca61d372cf763e4a28c0b0829ea361219f6203
Reviewed-on: https://gerrit.openafs.org/14217
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit 278592ef2d766c77de821b9da80359f24fec5b62
Author: Mark Vitale <mvitale@sinenomine.net>
Date: Mon Jan 27 12:26:41 2020 -0500
uss: more gcc9 truncation warning appeasement
uss_procs_PickADir needs a larger buffer to avoid a truncation warning.
While here, replace some magic numbers with existing symbols.
Reviewed-on: https://gerrit.openafs.org/14049
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6c54bc9e121b923ec5fdd60ee510171987e55017)
Change-Id: I5cb76a8a9b2a9b342a1ddae2f41ecab82f762326
Reviewed-on: https://gerrit.openafs.org/14140
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
commit ff07fa706e00f6dde13c58588d2f75e7fc26ecf5
Author: Michael Meffie <mmeffie@sinenomine.net>
Date: Fri Jan 10 09:06:38 2020 -0500
tests: do not resolve addresses in vos/vl test
The vos-t test adds a set of 10.* test addresses to a test vlserver and
runs vos to read them back. When the test is run in an environment
where hosts have been assigned in the 10.* internal network, vos will resolve
the addresses to hostnames and the test fails. Pass the -noresolve
option to vos for this test when checking for the expected list of
addresses.
Example test output before this commit:
./vos-t
...
# seen: 10.0.0.0
10.0.0.1
myhost.example.com
10.0.0.3
...
not ok 5 - vos output matches
Reviewed-on: https://gerrit.openafs.org/14020
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dcf44ab5fc5c1f5e2e759ea4b6156f7e1faa4b7a)
Change-Id: Ie2a6d97070fe47886a1ccf8c0ddf03012f805beb
Reviewed-on: https://gerrit.openafs.org/14105
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reference in New Issue View Git Blame Copy Permalink