pool/openafs
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5f80e8fd08
openafs/ChangeLog

1912 lines
84 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 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>
Reference in New Issue View Git Blame Copy Permalink