If we encounter a preattached volume during GetVolume, we currently
ignore vp->specialStatus before trying to attach. However, we will
generally always fail to attach due to a conflicting vol op, but even
if we don't, GetVolume always returns an error later on if
vp->specialStatus is set. So, same some processing and attempted
attachments by bailing out sooner if vp->specialStatus is set.
Change-Id: Id5df08fe31073485e4d733c42310b42090ee8e7b
Reviewed-on: http://gerrit.openafs.org/4874
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Not every field in the summary header in RecordHeader is set, leaving
some used uninitialized when we copy to the given volumeSummaryp (like
'deleted'). Zero out the header before we do anything.
Change-Id: I94f6e5c8b8c60675de25eb6f8290de9545ff4dd0
Reviewed-on: http://gerrit.openafs.org/4876
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently dasalvager links to vlib.a. But vlib.a is built without any
DAFS defines, and so the size of a struct DiskPartition64 is different
(since dasalvager is built with AFS_DEMAND_ATTACH_UTIL). Build our own
copies of the volume package files instead, with
AFS_DEMAND_ATTACH_UTIL defined.
Change-Id: I7b9f965fc18b6e6b71275912684ad041aaef19f4
Reviewed-on: http://gerrit.openafs.org/4875
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
DRead was missing a return statement in one of the cases where we
found the buffer we were looking for, so we locked the buffer but kept
looking. Return it instead.
Change-Id: If72a0ba3ce60a847f2796b51a82f0f473bbc608a
Reviewed-on: http://gerrit.openafs.org/4877
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
attach2 wants to set specialStatus to VBUSY in certain conditions
(such as, it discovers a conflicting vol op where VVolOpSetVBusy_r is
true). However, specialStatus may already be set to something else,
like VMOVED if the volume is being moved off of the server. This can
happen if the volserver has checked out and FSYNC_VOL_MOVE'd a
preattached volume but hasn't deleted or checked the volume back in
yet.
So, if specialStatus is already set, don't touch it, so we don't start
reporting VBUSY errors to clients when we should be reporting VMOVED,
or some other error code previously set.
Change-Id: Icb2895036620f186230e1558b8bc04d18cc45c86
Reviewed-on: http://gerrit.openafs.org/4873
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The current code only exits fast restart when we receive an ACK
packet that contains no missing chunks at all. On a network that is
dropping a reasonable chunk of its packets, this means that we spend
most of the call in fast recovery. (I originally found this by running
with the intentionally drop packets feature set to 10%)
TCP's fast retransmit behaviour is that we stay in fast recovery until
we receive our first non-duplicate acknowledgement. In TCP that means an
acknowledgement that moves the window. In RX, it is an acknowledgment
that ACKs a new packet.
Change-Id: If8e461dd91315be845397dd1bf42771c9223d156
Reviewed-on: http://gerrit.openafs.org/4869
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The RX transmit engine limits the number of packets sent whilst in
loss recovery to one per invocation of the transmit engine. As the
engine cannot be called by the application thread whilst in recovery,
this means that we end up being limited to one packet per ACK received,
which means that despite a growing congestion window we'll only send
one packet per RTT (in effect, a congenstion window of 1).
This will remain the case until we exit recovery, and all of a sudden
can send a large number of packets. If this is larger than the current
capacity of the network, we'll probably end straight back in recovery
again.
Let the congestion window do its job, by removing this arbitrary limit.
Change-Id: I9f21138662b0918d6d2b885f0fb5ada7fa4c79ec
Reviewed-on: http://gerrit.openafs.org/4868
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Two different threads can cause a call to enter recovery. The event
thread will move a call into recovery as a result of a timeout, or
the listener thread will move it there following a fast retransmit.
In both of these cases, recovery looks different. In the case of
a timeout, we enter slow start, starting as if we were begininning
transmission for the first time. Following fast retransmit, we enter
fast recovery, with different starting parameters than those coming
from slow start.
As a reslt, the current behaviour, where either call sitting in
FAST_RECOVERY_WAIT causes the other to simply return is inappropriate.
Further investigation indiciates that FAST_RECOVER_WAIT is actually
uncessary. There is no harm caused to a thread which is currently
blocked on the network in the middle of a transmit, in adjusting the
window size underneath it. As both of these states collapse the window,
that thread will simply cease sending earlier.
So, simplify the code, and remove the potential race between event and
listener by removing the FAST_RECOVER_WAIT state.
Change-Id: Ic2e7606136ca04c869685345b63101c346ce702b
Reviewed-on: http://gerrit.openafs.org/4867
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Since I mistakenly wrote commit 36e2d13b, RX hasn't entered congestion
avoidance when a loss event occurs. This is bad, because on todays
networks the majority of packet losses are due to some form of
congestion.
Now that the timeout code has been restructured, the chances of entering
the retransmit routine in error are much much smaller, so this code
needs to be restored.
This change reverts 36e2d13b55. However,
the original RX code has the problem that it assumes that all forms of
fast recovery are the same - in particular, that the call settings that
result from entering fast recovery due to a fast retransmit are
identical to those resulting from a timeout. This is not the case, and
this will be fixed in a later change.
Change-Id: Iedb34437db9fcfbc90307b01e566a8d089eef4bb
Reviewed-on: http://gerrit.openafs.org/4866
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When we retransmit a packet, we may be doing so because the RTT of the
connection has grown dramatically larger than earlier within the call.
However, RX doesn't permit all ACKs to retransmitted packets to be
counted within the RTT calculation.
So, adopt the same approach as Karn developed for TCP, and as described
in detail in RFC2988. When a retransmit event occurs, backoff the
connection RTT by doubling its value, and hold at this doubled value
until either another retransmit occurs (in which case we back off again,
up to a predetermined ceiling), or we receive an ACK packet which we
can use within the RTT calculation, in which case we drop back down to
the newly measured value.
This change replaces the per-packet backoff strategy originally
implemented in RX (which, whilst allowing resent packets more chance of
arriving, doesn't help with computing a correct RTT).
Change-Id: I715dc673a0b379733e3be26fa594ea13f492a58f
Reviewed-on: http://gerrit.openafs.org/4865
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
With the existing clock_Add code, the following:
struct clock a = {2, 800000};
clock_Add(&a, &a);
gives a clock value of {6, 600000}, rather than the expected {5, 60000}.
This is because the ordering of instructions leads it to double count
the carry on the seconds field. Reorder the instructions so that the
carry is correctly applied.
Change-Id: Ia71b387ce521a11e4caf9ec200907efe1d2be8ff
Reviewed-on: http://gerrit.openafs.org/4864
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Create a new function, rxi_Resend, which is the entry point to running
the transmit queue as a result of a resend event. This concentrates all
of the resend logic into one place, removes the need for
rxi_StartUnlocked, and means that rxi_Start's arguments don't need to
match those of an event handler.
Change-Id: I550ebbbae63b7d659bb980eea709a14882038914
Reviewed-on: http://gerrit.openafs.org/4863
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
RX maintains a retryTime for every packet that it has transmitted,
which is held as the time that that packet was sent, plus the smoothed
RTT of the connection. If a packet is in the queue with a retryTime
older than the current time, then it is resent at the first opportunity.
In some circumstances, this first opportunity will be as a result of
the resend event timer expiring, in others it will happen as part of
a normal queue run.
There are a number of problems with this approach on congested networks.
Firstly, on a network with a large window size, which is in "normal"
flow, it means that we will never actually perform fast retransmit as
the timeout for this packet will have expired before we have received
any further ACKs. This is because, on a network with a relatively stable
RTT the ACK for packet n+1, n+2, or n+3 cannot arrive before the
expected time of arrival of the ACK for packet n. As we retry
immediately this expected time of arrival has passed, we never have the
opportunity of using these later ACKs to learn that packet n is lost.
Secondly, the fact that we may resend packets from a "normal" queue run,
rather than as a result of a resend event, means that there is no clear
entry point for resends. As resends should be assumed to be a result of
network congestion, and result in both the call throttling back, and the
RTT being increased, this lack of a clean entry point makes things
tricky.
As a solution, this patch changes the way in which retransmit times are
applied to use the algorithm described in RFC2988.
*) Whenever we send a new packet, we start a timer for the current call
rto value if one isn't already running.
*) Whenever we receive an ACK that acknowledges new data, and we have
packets that are sent but not yet acknowledged, we restart the
retransmit timer using the current rto value.
This alogrithm solves the first problem, as it means that if the
connection is still flowing, we will continue to receive ACKs, and we
can enter fast retransmit.
In implementation terms, we longer track a retryTime per packet, and
instead simply record if a packet has been sent or not. Packets which
have been sent may only be resent as a result of a resend timer
expiring, or of entering fast retransmit, so solving the second issue.
Change-Id: Ic1e2b32876197f8a1fb620b7d70c0c3ec3f6bb88
Reviewed-on: http://gerrit.openafs.org/4862
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
RX uses the TCP RTT smoothing algorithm as described in RFC2988.
However, the TCP algorithm is designed to accept samples from a
single connection, accepting a new sample once per RTT.
RFC2988 suggests that "when multiple samples are taken
per RTT the [ alogrithm ] may keep an inadequate RTT history."
In RX's implementation, we use a single instance of this alogrithm
per peer, and input all of the samples from all of the active calls
and connections into this same instance. This leads to us taking
a significantly (potentially many magnitudes) larger number of samples
per RTT, and rapidly losing the RTT history. With RX's implementation,
short lived network events may easily bias the RTT, and cause large
numbers of packets to time out.
This change fixes this by moving the RTT calculation onto a per call
basis. We still update the peer with our caclulated value, so that new
calls may be created with an RTT corresponding to the current value for
the connection, rather than having to start high and converge downwards.
Change-Id: I2ed6bce63adf160c03518686ec25cbecc5084f5f
Reviewed-on: http://gerrit.openafs.org/4861
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
The "testclient" utility is built as part of the build on Windows.
Fix it so that it actually builds on Unix, so we can test changes to
testclient there.
Change-Id: I751e905f6d9676598e3b7be9ccaf321250804f11
Reviewed-on: http://gerrit.openafs.org/4872
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Currently, the rx server thread idle queue is used in an LRU manner.
This means that we round robin requests between all of the threads
configured on a given system, which means that we end up thrashing
CPU caches on machines whose workload doesn't require that all of
the configured threads be used.
Change this so that we always use the most recently idle thread. This
isn't as "fair" to all of our waiting threads, but should mean that we
scale better on SMP machines, as a thread that is recently idle is
likely to have been recently scheduled.
Performance numbers to follow ...
Change-Id: I6072183b5ca72754755c3ac854e30a064c4187e5
Reviewed-on: http://gerrit.openafs.org/4871
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
include our shared libraries in the package when we have them
Change-Id: I18a38c69410a7fded361b05479c93698e3d618e2
Reviewed-on: http://gerrit.openafs.org/4870
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
The ACK packet handling routine contains code which causes the
RTT to backoff if the selective ACK response indicates that there is
a missing packet. The comment justifies this code as being in line
with Phil Karn's work on TCP.
However, the TCP behaviour is that we backoff when we enter resend. Both
TCP and RX have difficulty computing RTTs for resent packets due to the
ambiguous ACK problem. Whilst RX is slightly better than TCP in this
regard, we can't always tell whether an ACK refers to the original, or
resent packet, so resent packets are unable to contribute to the RTT.
This means that if the RTT ends up too low for the connection, and we
start resending every packet, the RTT will never grow to account for
this, as we never feed it any packet samples.
Karn's solution to this was to backoff (double) the RTT value when we
resend a packet, and then to not drop it back down until we receive an
ACK that we can count. This means that we will always get a new sample
for the connection, and the RTT will grow again.
The original author confirms that the current behaviour in RX is
incorrect, so simply remove it with this patchset.
Change-Id: I0f4af56601c43b72394d7903cacc3fc19bc9d046
Reviewed-on: http://gerrit.openafs.org/4860
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
RX currently only soft ACKs every second packet, therefore a soft ACK
may be delayed by a period of time (currently 100ms, although RX did
expose this as a public variable in earlier versions).
RTT values are computed using only non-delayed ACKs, so the timeout
is a smoothed average of the exact time taken to send and directly
ACK a packet. Therefore, if the peer ends up using a delayed ACK for
the packet, using just the RTT will cause that packet to be timed out.
A while ago, this was dealt with by padding the calculated RTT with an
additional 350ms. This was then removed, and changed to a 350ms minimum
value. When this caused large numbers of spurious resends, the padding
was restored, but with a 20ms default value. As noted above, 20ms is
too low, as we may wait for up to 100ms before sending an ACK.
This patch changes minPeerTimeout so that it does what it says on
the tin - sets a minimum value below which the peer timout may not
fall. It then adds to either this value, or the calculated one, 200ms
of padding. This makes our padding identical to TCPs, and allows some
future leway as to the softAckDelay value.
Change-Id: I48ab28e03bb7c0a49fe21c21f83adbb02b7665f2
Reviewed-on: http://gerrit.openafs.org/4859
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The values of these two parameters directly affect the modifiers
that are needed in the peer's RTT calculations, and so can not
arbitrarily be changed by applications.
lastAckDelay has been 400ms since the first OpenAFS release, and
that value is used as a modifier when computing the timeout of the
last packet. It is likely that any change which made this value
longer than 400ms would have detrimental effects on deployed clients
softAckDelay has been 100ms for a similar time period. We have
chopped and changed the value of minPeerTimeout, so it is unclear
what the maximal value for this parameter is. For much of OpenAFS's
life, minPeerTimeout was a 350ms padding value, which suggests that
copying TCP, and setting the maximal value at 200ms would be a safe
option. For now, however, leave it at 100ms to avoid unexpected
side effects.
hardAckDelay is not addressed by this patch set, as all ACK packets
sent from the application thread are marked as delayed, and so
currently have no part in computing RTT times. It is likely, however,
that any changes to the hard ACK timeout should be very carefully
considered.
Change-Id: Ibdeae4577b09d120f22bb922697f92d63aaf0dff
Reviewed-on: http://gerrit.openafs.org/4858
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Culled info from commit 21592fe6 by Kris Hees. These allow
one to specify how to set the creation date and last update
date at volume restore.
Change-Id: I6cfebb41c18e1acca5bbb70e3ee179c8ee976be3
Reviewed-on: http://gerrit.openafs.org/4852
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Simon Wilkinson <sxw@inf.ed.ac.uk>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
In normal operation, any AFS vcache with associated data will have
an associated vnode, which will be on the list of vnodes associated
with the /afs mountpoint. We already call FreeBSD's vflush() in
our afs_unmount, which walks the list of vnodes associated with the
mountpoint and calls vgonel() on them, which calls VOP_CLOSE and
VOP_RECLAIM on the vnode. Our implementation of VOP_RECLAIM already
calls FlushVCache, so in normal operation, FlushAllVCaches() will
be a no-op.
However, in the presence of bugs, it is actively harmful, causing
panics. For example, if a vnode has been reclaimed but FlushVCache
failed (which we cannot report back since the VFS will panic in this
case), and we attempt to flush it again, the associated vnode has
already been cleaned up and we will panic. Likewise if our list of
vcaches becomes corrupt and has a vcache with bad or missing vnode
for some other reason, we will panic.
Since there is no gain in normal operation and abnormal operation
is more likely to panic than save data, skip the extra flush.
Change-Id: Id227ca74f4036c1c1f40a41a922e73198f16f958
Reviewed-on: http://gerrit.openafs.org/4847
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Since it's just an empty file, installing it is rather silly.
Change-Id: I93279c5d7b0e5262bfdb68cdbd92c49e1984fa97
Reviewed-on: http://gerrit.openafs.org/4849
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Remove the "typedef" from the structure element configure test
comment. The typedef version of the macro is used by the more
general element test, so the comment should be more general.
This affects comments in src/config/afsconfig.h
Change-Id: If5b748e1a63de83e15906fc16e7c94b357c4363c
Reviewed-on: http://gerrit.openafs.org/4836
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
we need roken and hcrypto to build the bits we need to build the
compiler tools on master. do so.
Change-Id: I3e974a5d94bdfdf3e89f3d18aed55ed586b0034d
Reviewed-on: http://gerrit.openafs.org/4835
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
avoid conflicting with heimdal in environments where we might
need bits of their asn1 library also
Change-Id: Ib76c158297a331fcaf650c435c5696e5b5aaab8c
Reviewed-on: http://gerrit.openafs.org/4834
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
des is in the generated targets. kill it.
Change-Id: Ifb4ad48b0f57e95842411046cb79b589669265b7
Reviewed-on: http://gerrit.openafs.org/4833
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
simply compile lwp process assembler for both arm arches.
Change-Id: Ie09ec1e3684656a492373f86e4c8be71e6abfabd
Reviewed-on: http://gerrit.openafs.org/4832
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
* Remove several files from the packaging manifest that are no longer
generated or included in the distribution, such as the DES header
files.
* Exclude the aklog_dynamic_auth man page, since it is AIX-only
* Add new files that have appeared in the distribution, such as the
'afsio' binary.
* Add librokenafs.so.1 and libafshcrypto.so.1 to the base package,
because many of the binaries in the base package are linked against
librokenafs and the 'butc' binary is linked against libafshcrypto.
* Move the librokenafs.{so,a} and libafshcrypto.{so,a} to the -devel
package instead of the authlibs-devel package, now that the .so.1
library is part of the base package.
* Set the executable bits on the libraries installed in libdir. This
change is important because it causes 'rpmbuild' to generate Provide
tag metadata for the libraries in the package, which is necessary now
that some binaries in other packages have generated Requires tags for
libraries packaged in the base package. 'rpmbuild' will not generate
the Provides tag if the libraries lack executable permission.
Change-Id: I8f66cf882008b5576528ccc0f4a9694015db85bb
Reviewed-on: http://gerrit.openafs.org/4814
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
On Linux and IRIX, fail gracefully when we fail to open /etc/mtab,
instead of segfaulting. Move strdup'ing cacheMountDir until after
opening /etc/mtab, to simplify the error handling.
Change-Id: I58d64548303f25a51753d093a733608fea1282e1
Reviewed-on: http://gerrit.openafs.org/4825
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
PrintFileNames only exists on namei, so make sure it's inside a namei
ifdef.
Change-Id: I65867b54e3747b6f3a26cdfd70ab84ed7fe4e44d
Reviewed-on: http://gerrit.openafs.org/4830
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Clear dirHeader->hashTable via memset instead of via a loop. This is
more efficient, and avoids the loop getting optimized into an unusable
_memset call on recent versions of Solaris Studio when building for
the kernel.
Thanks to Jeff Blaine for reporting the issue with Solaris Studio.
Change-Id: Ibaa5140d510c2df7e1129352a6677594785b42b4
Reviewed-on: http://gerrit.openafs.org/4829
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Change-Id: I458a6b50fee4ed41dd512e23de6b4e516e0ddc93
Reviewed-on: http://gerrit.openafs.org/4828
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Tested-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
A todo item was in the "Known Problems" list, but the work was
already completed. Cleared this item from the list (klog man
page info about krb5, klog.krb5, fakeka)
Change-Id: I9dbff50afd7bbaa6f5d20f7d4acfc796731b9c2d
Reviewed-on: http://gerrit.openafs.org/4826
Reviewed-by: Russ Allbery <rra@stanford.edu>
Tested-by: Russ Allbery <rra@stanford.edu>
Since the shell extension is multithreaded and it is possible
for more than one thread to be executing in the gui2fs.cpp module
at a time, it is not safe to use a single static 'space' buffer
by more than one thread at a time. Move the buffer into the
stack of each function that uses it so that we have thread safety.
Change-Id: Idbec3e0027fc7e3c43b503c55c1b479bcb5984bc
Reviewed-on: http://gerrit.openafs.org/4819
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
"Empty" <anchor> entities seem to trigger a bug in fop. These are
easily converted to reference on the containing block. Additionally,
<indexterm>'s seem to need to be inside a non-structural entity (like
a <para>) in order to determine their page number/location correctly.
Change-Id: I2ab577f6ba8989685257fb9429e00a71dd51075c
Reviewed-on: http://gerrit.openafs.org/4812
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
The change gerrit/4760 enabled the use of gencat to actually build
this file, but failed to also change installation logic, so it was
sitting unused in the build tree. Fix this, and install the file.
This allows us to remove a shell case statement which had formerly
been needed to enforce this restriction.
Change-Id: I7f9e94b09c504193084e1e04ae137df08b27b447
Reviewed-on: http://gerrit.openafs.org/4815
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
There were no users within the code of the rx connection maxSerial
element, and maintaining it required locking on a critical path. So,
get rid of it.
Change-Id: Ied5653b6f01b78525091d8bf09bdc454002eedc0
Reviewed-on: http://gerrit.openafs.org/4797
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
The transmit queue is stored in the order that we transmitted the
packets (by sequence number). This means that we can do all of the
ACK processing by just doing a single walk of this queue, rather
than having to walk the queue multiple times, once for each type of
ACK.
This clarifies the queue processing, and should reduce the amount of
time that we spending iterating large transmit queues.
Change-Id: I59578956e81197bbea7ce496e2f520a2995a3e95
Reviewed-on: http://gerrit.openafs.org/4796
Tested-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
3cd3715e60 modified rxi_ReceiveDataPacket
to send an ACKALL whenever RX_CALL_RECEIVE_DONE is set on the call.
This produced the potential for a race with ACKs that set the
firstPacket value to 'rnext' when the receive queue for the call
has yet to be emptied. From the perspective of receiver the ACK
was already processed and does not require a response since the
previously received ACKALL acknowledged the delivery of all data
packets to the application. When sending ACKs after ACKALL it is
therefore required that firstPacket be set to the sequence number
after the last unprocessed packet in the receive queue.
Thanks to Simon Wilkinson for his extensive assistance in identifying
the problem and the development of this patchset.
Change-Id: I3bdf0c8f297b1d91b1a2bf3284adfeb9301874eb
Reviewed-on: http://gerrit.openafs.org/4798
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
rxi_ReceiveDataPacket() calls rxi_AckAll() when the call reaches
the RX_CALL_RECEIVE_DONE state to permit the caller to empty the
transmit queue. That reduces the memory consumption of the caller
and avoids unnecessary retransmits which the call is in process.
If the call data consists of a single packet it is possible that
Ping ACK packets sent as part of connection establishment could
race with the ACKALL and be delivered out of order. If the Ping
ACK is delivered second, it will be ignored by the peer forcing
a two second delay in connection establishment. To avoid the race
do not send an ACKALL for a single packet call.
Change-Id: I69d967b3b2e9ee77636ca12bc7ade4896bb8a071
Reviewed-on: http://gerrit.openafs.org/4799
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
ugen_ClientInit permits the configuration directory to use to be
passed on the command line. However, it was then promptly overwritting
the supplied directory with the standard client (or server) directories,
depending on whether localauth was in use or not.
As a start to fixing this anti-social behaviour, modify ugen so that if
we're not doing localauth, and if the caller has passed us a config
directory, use that instead of the system default one. This allows us to
start creating test harnesses for our command line tools.
Change-Id: I6916389ce56df4cee62845a03282c5c10d3095eb
Reviewed-on: http://gerrit.openafs.org/4809
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
When creating the test CellServDB, use the IP address of the machine
that we are running on, rather than 127.0.0.1. This makes it possible
to actually start up ubik servers using this CellServDB.
Change-Id: Iec0be80921dd1f01825177562f8a3dcc59400b9a
Reviewed-on: http://gerrit.openafs.org/4808
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Make the code which adds a new (static) DES key to a cell's
configuration generally available, as this will also be useful in
constructing other tests
Change-Id: I5d284016628e9d25a198607ffd6f8f1a63ddf652
Reviewed-on: http://gerrit.openafs.org/4807
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Move code for faking up an OpenAFS configuration directory into its
own "common" directory, as it's going to be of use to more tests than
just those in auth.
Change-Id: I9c80dd66763e222deca98bc7744ff317111c6ed8
Reviewed-on: http://gerrit.openafs.org/4806
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
