No functional change. Separate the
if (locked && vcp->mvstat == 1) { ... }
conditional into
if (locked) {
if (vcp->mvstat == 1) { ... }
}
in preparation for another change.
Change-Id: I1fe42ed7771882ce365d9359a4e6187c283592a8
Reviewed-on: http://gerrit.openafs.org/11692
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The bosserver creates symlinks for the client CSDB and ThisCell config
files during initialization. Avoid exiting if the client CSDB or
ThisCell configuration already exists, otherwise the bosserver cannot be
restarted with bos restart.
This fixes an error introduced with commit
720363fa9b, Fix unchecked return values.
Change-Id: Ie6ecf126d1ed663f161c26da2a8c4d568369d99d
Reviewed-on: http://gerrit.openafs.org/11684
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
While reviewing gerrit 11678 I noticed the -n flag was
duplicated. Remove the duplicate flag.
Change-Id: I4a63a50199e1564a0b0394445e9dc1569bb08a0c
Reviewed-on: http://gerrit.openafs.org/11688
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
In several places in the code, we allocate a 'struct uio' on the
stack, or allocate one from non-zeroed memory. In most of these
places, we initialize the structure by assigning individual fields to
certain values. However, this leaves any remaining fields assigned to
random garbage, if there are any additional fields in the struct uio
that we don't know about.
One such platform is Solaris, which has a field called uio_extflg,
which exists in Solaris 11, Solaris 10, and possibly further back.
One of the flags defined for this field in Solaris 11 is UIO_XUIO,
which indicates that the structure is actually an xuio_t, which is
larger than a normal uio_t and contains additional fields. So when we
allocate a uio on the stack without initializing it, it can randomly
appear to be an xuio_t, depending on what garbage was on the stack at
the time. An xuio_t is a kind of extensible structure, which is used
for things like async I/O or DMA, that kind of thing.
One of the places we make use of such a uio_t is in afs_ustrategy,
which we go through for cache reads and writes on most Unix platforms
(but not Linux). When handling a read (reading from the disk cache
into a mapped page), a copy of our stack-allocated uio eventually gets
passed to VOP_READ. So VOP_READ for the cache filesystem will randomly
interpret our uio_t as an xuio_t.
In many scenarios, this (amazingly) does not cause any problems, since
generally, Solaris code will not notice if something is flagged as an
xuio_t, unless it is specifically written to handle specific xuio_t
types. ZFS is one of the apparent few filesystem implementations that
can handle xuio_t's, and will detect and specially handle a
UIOTYPE_ZEROCOPY xuio_t differently than a regular uio_t.
If ZFS gets a UIOTYPE_ZEROCOPY xuio_t, it appears to ignore the uio
buffers passed in, and supplies its own buffers from its cache. This
means that our VOP_READ request will return success, and act like it
serviced the read just fine. However, the actual buffer that we passed
in will remain untouched, and so we will return the page to the VFS
filled with garbage data.
The way this typically manifests is that seemingly random pages will
contain random data. This seems to happen very rarely, though it may
not always be obvious what is going on when this occurs.
It is also worth noting that the above description on Solaris only
happens with Solaris 11 and newer, and only with a ZFS disk cache.
Anything older than Solaris 11 does not have the xuio_t framework
(though other uio_extflg values can cause performance degradations),
and all known non-ZFS local disk filesystems do not interpret special
xuio_t structures (networked filesystems might have xuio_t handling,
but they shouldn't be used for a cache).
Bugs similar to this may also exist on other Unix clients, but at
least this specific scenario should not occur on Linux (since we don't
use afs_ustrategy), and newer Darwin (since we get a uio allocated for
us).
To fix this, zero out the entire uio structure before we use it, for
all instances where we allocate a uio from the stack or from
non-zeroed memory. Also zero out the accompanying iovec in many
places, just to be safe. Some of these may not actually need to be
zeroed (since we do actually initialize the whole thing, or a platform
doesn't have any additional unknown uio fields), but it seems
worthwhile to err on the side of caution.
Thanks to Oracle for their assistance on this issue, and thanks to the
organization experiencing this issue for their patience and
persistence.
Change-Id: I0eae0b49a70aee19f3a9ec118b03cfb3a6bd03a3
Reviewed-on: http://gerrit.openafs.org/11705
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Currently we pass a caller_context_t* to some of Solaris' VFS
functions (VOP_SETATTR, VOP_READ, VOP_WRITE, VOP_RWLOCK,
VOP_RWUNLOCK), but the pointer we pass is to uninitialized memory.
This code was added in commit 51d76681, and this particular argument
is mentioned in
<https://lists.openafs.org/pipermail/openafs-info/2004-March/012657.html>,
where the author doesn't really know what the argument is for.
Over 10 years later, it's still not obvious what this argument does,
since I cannot find any documentation for it. However, browsing
publicly-available Illumos/OpenSolaris source suggests this is used
for things like non-blocking operations for network filesystems, and
is only interpreted by certain filesystems in certain codepaths.
In any case, it's clear that we're not supposed to be passing in an
uninitialized structure, since the struct has actual members that are
sometimes interpreted by lower levels. Other callers in
Illumos/OpenSolaris source seem to just pass NULL here if they don't
need any special behavior. So, just pass NULL.
I am not aware of any issues caused by passing in this uninitialized
struct, and browsing Illumos source and discussing the issue with
Oracle engineers suggest there would currently not be any issues with
the cache filesystems we would be using.
However, it's always possible that issues could arise from this in the
future, or there are issues we don't know about. Any such issues would
almost certainly appear to be non-deterministic and be a nightmare to
track down. So just pass NULL, to avoid the potential issues.
Change-Id: I41babe520530ba886d1877de99eb1644c1b9f699
Reviewed-on: http://gerrit.openafs.org/11704
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
This patch modifies a patch committed as 1e6fb1b7b7, the dumpTimes.to is now
set to creationDate for R/O volumes. The old value copyDate is wrong, if the
R/O volumes is re-cloned. This does not happen with "vos dump -clone", but
may happen with dumping a R/O volume directly: "vos dump <R/O volume>".
Change-Id: Ia3ae7e1ae4a22aa47f0f28fac45077ff6789e720
Reviewed-on: http://gerrit.openafs.org/11468
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The LK_CANRECURSE and LK_RECURSEFAIL flags in the call to lockmgr()
are mutually exclusive. Previous version of OpenBSD didn't really
check well for this but more recent versions look for the conflict
and take a kernel panic when they're both set.
The OpenBSD kernel module currently just blindly sets the
LK_CANRECURSE flag in its call to lockmgr(). This patch changes
that behaviour so that it checks to make sure that the LK_RECURSEFAIL
flags is not set before it actually applies the LK_CANRECURSE flag.
That removes the kernel panics that have started to arise.
This behaviour is more consistent with other OpenBSD code that makes
use of the LK_CANRECURSE flag.
Change-Id: Ie435559f4b88195136e09c6184543861f06257da
Reviewed-on: http://gerrit.openafs.org/11699
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The second parameter in the call to osi_VM_FlushVCache() in the kernel
module is obsolete and has been removed. However, one call in the
OpenBSD module still contains that parameter in its call. This patch
removes it, eliminating the compile error.
Change-Id: Ia3f79c74e86b8038301459e1adbf17a58056e8b1
Reviewed-on: http://gerrit.openafs.org/11698
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
d_splice_alias now drops the inode reference on error, so we
need to grab an extra one to make sure that the inode doesn't
go away, and release it when done if there was no error.
For kernels that may not drop the reference, provide an
additional iput() within an ifdef. This could be hooked up
to a configure option to allow building a module for a kernel
that is known not to drop the reference on error. That hook
is not provided here. Affected kernels should be the early
3.17 ones (3.17 - 3.17.2); 3.16 and older kernels should not
return errors here.
[kaduk@mit.edu add configure option to control behavior, which
is mandatory on non-buildbot linux systems]
Change-Id: Id1786ac2227b4d8e0ae801fe59c15a0ecd975bed
Reviewed-on: http://gerrit.openafs.org/11643
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Get the rest of them all at once.
Change-Id: Ife9920f00ec8eea953929a76a30f86d958d55f9c
Reviewed-on: http://gerrit.openafs.org/11590
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This will record the caller as well as the fact that we received
a GetXStats call.
Change-Id: I101b9fcea37e26e031efa4a8cf74df8351866dcf
Reviewed-on: http://gerrit.openafs.org/11620
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The calls in AFSVolClone to AssignVolumeName are unnecessary, because
the volume name is overwritten few lines later with strcpy.
Change-Id: If5031271b9ade08ae248703c8a72f3a083fd4fce
Reviewed-on: http://gerrit.openafs.org/11432
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The MT_LIBS library list already includes XLIBS, so there's no need
to specify both on a link line.
Change-Id: I8594b1b6e1a16af741b40822cbce49e846b26f49
Reviewed-on: http://gerrit.openafs.org/8904
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Make sure we don't continue on if we have unbalanced locks and
unlocks. Having a negative refcount is a serious internal error, and
they are difficult to fix unless we assert right away.
Change-Id: Ib9b5b3f209635e0365df96c79ea8bf49c765008b
Reviewed-on: http://gerrit.openafs.org/2594
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
When we VRequestSalvage_r a volume, normally the header is freed when
the volume goes offline. This happens when we VOfflineForSalvage_r,
either via VCheckSalvage when nUsers drops to 0, or in
VRequestSalvage_r itself if nUsers is already 0. We cannot free the
header under normal circumstances, since someone else may have a ref
on vp, which implies that the vol header object is okay to use.
However, for VOL_SALVAGE_NO_OFFLINE, we skip all of that. For
VOL_SALVAGE_NO_OFFLINE, the volume has only been partially attached,
so it does not go through the full offlining process, so we don't ever
hit the normal VPutVolume_r handlers etc. So, in the current code, we
don't free the header. But our nUsers drops to 0 anyway, and when
nUsers is 0, our header is supposed to be on the LRU (if we have one).
"oops"
Rectify this by freeing the volume header when VOL_SALVAGE_NO_OFFLINE
is set. Add some comments to try to be very clear about what's going
on.
Note that similar behavior was removed in commit
4552dc5526 via a similar flag called
VOL_SALVAGE_INVALIDATE_HEADER. I believe now that this is the same
scenario that VOL_SALVAGE_INVALIDATE_HEADER was trying to solve.
However, VOL_SALVAGE_INVALIDATE_HEADER was not always used correctly,
and its purpose was not really adequately explained, which contributed
to the idea that its very existence was buggy.
Previously, when VOL_SALVAGE_INVALIDATE_HEADER existed, it was used
incorrectly in the VRequestSalvage_r calls in GetVolume,
VForceOffline_r, and VAllocBitmapEntry_r. All of these call sites
could have a vp with other references held on it, and so invalidating
the header there can cause segfaults when the header is freed. So
ideally, commit 4552dc5526 would have
just removed the flag from those call sites.
This change effectively restores the behavior that
VOL_SALVAGE_INVALIDATE_HEADER provided. But no new flags are gained,
since this behavior is what we want for the VOL_SALVAGE_NO_OFFLINE
flag. This is not a coincidence; for the 'normal' case, we will free
the header whenever we offline the volume. But for the 'do not
offline' case, obviously that will never happen, so we need to do it
separately. So, these two flags are really the same thing.
Change-Id: Ia369850a33c0e781a3ab2f22017b8559410ff8bf
Reviewed-on: http://gerrit.openafs.org/8204
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Currently, it's not really 'safe' in ihandle to issue an IH_OPEN
against an IHandle_t when an IH_REALLYCLOSE is running at the same
time. The reasons for this are explained a bit in ticket 131530 and
related commits, but briefly:
Say IH_OPEN runs, and drops IH_LOCK to open a new fd on disk. Then
IH_REALLYCLOSE runs and closes all fds, or marks them as needing
close. The running IH_OPEN then acquires IH_LOCK again and puts the
newly-opened fd onto the per-IH list of fds. We now have an fd that
effectively "survives" across the IH_REALLYCLOSE; effectively
IH_REALLYCLOSE did not close all fds for the ih.
This is possibly fixable by maintaining some extra information in
IHandle_t's, but this is only a problem if we allow IH_OPEN calls to
happen simultaneously with IH_REALLYCLOSE calls. Ever since
ih_sync_thread was removed (or changed to not call IH_OPEN), there
should be no cases where this is possible. All instances of
IH_REALLYCLOSE happen during error recovery for a newly-created file,
or happen under a per-vnode write lock, or for volume metadata files
only happens when the ref count for a volume drops to zero when we're
offlining the volume.
So, do not bother trying to fix this, since doing so is currently a
waste of time and the resulting complexity could introduce bugs. But
in case someone ever tries to do something resulting in IH_OPEN calls
executing outside the normal threads of execution, add a comment
around the IH_REALLYCLOSE explanations to try and briefly explain that
this cannot currently be done.
Change-Id: I989806635f3b048b0c084480a4b02dc1902ba031
Reviewed-on: http://gerrit.openafs.org/9709
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Provide opr implementations of ffs(), fls(), ffsll(), and flsll().
There is no need to provide the 'long' form, since int is 32 bits
and long long is 64 bits.
These functions return the index of the first (or last) bit set
in a given (long long) word, or zero if no bits are set.
Change-Id: I126000f8b650f41d67567a9af659e0805478af2d
Reviewed-on: http://gerrit.openafs.org/11671
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
The size of the dcache hash table is automatically determined
from the size of the vcache hash table size, since even before
the initial OpenAFS 1.0 release. AFS 3.3 had constants
DCHASHSIZE and DVHASHSIZE which were used to size the respective
hash tables, but DCSIZE was unused even there.
Change-Id: I1f4e278eacb881b60a457fa9871225de7ce0f9f8
Reviewed-on: http://gerrit.openafs.org/11672
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Currently 'cacheout' will always utilize an unauthenticated connection
when talking to the VDLB, even if it uses an authenticated connection
when talking to fileservers. This is regardless of any tokens
retrieved or command-line parameters, etc.
Using an authenticated connection to the VLDB can be useful, since a
user may want to encrypt the VLDB communication, or require stronger
guarantees of data consistency. So, just use the same security class
information for our VLDB communication as for our fileserver
communication.
'scnull' is now not used anywhere after this commit, so get rid of it.
Change-Id: I1e8a440ea7427399a3b219246e4c3623a603c35e
Reviewed-on: http://gerrit.openafs.org/11637
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Several uuid fields as well as the ip addreses in the sysid file are in
network byte order. Fix the check_sysid utility to decode these fields
properly. In addition, print the server uuid in the common string
format used to display uuids, instead of by individual uuid fields.
Change-Id: I9688e9117490d0ef0eb6dd5af417222482322e0c
Reviewed-on: http://gerrit.openafs.org/11603
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Presumably these checks were different at some point in the past.
Change-Id: I0fb8737404a3c4fa786ab7965b60d35328d0bf32
Reviewed-on: http://gerrit.openafs.org/11632
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
AFS_ADAPT_PMTU is only defined on linux26, so anything which is
conditional on both AFS_ADAPT_PMTU and AFS_SUN5_ENV being set is
dead code.
This seems to have been dead code since its introduction in
commit 1206e7538b.
Change-Id: I9bb6ff40de87a7f2d8d953ef7583c6c2b090ab48
Reviewed-on: http://gerrit.openafs.org/11631
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
When we store MTUs (peer->ifMTU, peer->natMTU, etc.), we store the
maximum transport unit usable by RX, i.e., excluding the IP and UDP
headers, but including the RX header. Contrariwise, when we track the
size of packets we've sent (conn->lastPacketSize, peer->maxPacketSize),
we track logical packet lengths which exclude the RX header (and the IP
and UDP headers). However, the consumers of lastPacketSize and
maxPacketSize were not always interpreting their values correctly as
excluding the RX (and other) headers.
Add comments to these fields in their respective structure definitions
to help make clear what they contain (and the difference between them).
Correct several checks which were using the wrong constant for
correcting between these two worldviews (and the wrong sign). Modernize
the style of lines that are touched.
The lastPacketSize and maxPacketSize variables are only accessed from
five places: while sending packets, while processing acks, while sending
acks, while handling growMTU events, and in rxi_CheckCall(). They are
used to track the size of packets that have been successfully sent (and
thus, indirectly, to control the size of packets we send). The
maxPacketSize is only set once we have received an ack from the peer for
a packet of that size, and lastPacketSize tracks the size of a
speculative packet larger than that size, until it is acked.
When sending packets, we check if the size of the packet we are sending
exceeds the recorded maxPacketSize, and if so, record that speculative
size in the lastPacketSize variable, along with the sequence number of
that packet in lastPacketSizeSeq.
Correspondingly, when processing acks, if the packet tracked in
lastPacketSizeSeq is being acked, we know that our speculative large
packet was successfully received, and can attempt to update the recorded
maxPacketSize for the peer. This is done through an intermediate
variable, 'pktsize', which holds either the value of lastPacketSize or
lastPingSize, without adjustment for the size of any headers.
The ack processing has a bit of code to handle the case where
maxPacketSize has been reset to zero, initializing it to a small value
which should be expected to always work. The intention seems to have
been to initialize maxPacketSize to the smallest permitted value (since
RX_MIN_PACKET_SIZE is amount of data available to RX in the smallest
permitted IP packet), but the old code was actually initializing
maxPacketSize from zero to something a bit larger than the minimum, by
RX_IPUDP_SIZE + RX_HEADER_SIZE. This over-large initialization was
mostly harmless, see below. After this potential initialization,
'pktsize' was incorrectly used to set a new ifMTU and natMTU for the
peer. It correctly determined that a packet larger than the previous
maxPacketSize had been acked, but then set the peer's ifMTU and natMTU
to smaller values than the acked packet actually indicates. (It is
careful to only increase the ifMTU, though.) The actual peer->MTU is
*not* updated here, but will presumably trickle through eventually via
rxi_Resend() or similar. It is possible that this code should be using
rxi_SetPeerMtu() or similar logic, but that might involve locking issues
which are outside the scope of this analysis.
The over-large initialization of maxPacketSize (from zero) was
fortuitously mostly harmless on systems using minimum-sized IP packets,
since a correspondingly wrong check was used to detect if a new MTU
invalidates this maxPacketSize, with the constants offsetting.
Likewise, the checks in rxi_SendAck() had the wrong constants, but they
offset to produce the correct boundary between small and large packets
while trying to grow the MTU. Unfortunately, the old behavior in the
"small" case is not correct, and the grow MTU event would try to send a
packet with more padding than was intended. In networks allowing
packets slightly larger than the minimum (but not much larger than the
minimum), the old code may have been unable to discover the true MTU.
In the main (MTU-related) logic of rxi_SendAck, a variable 'padbytes' is
set to a small increment of maxPacketSize in the "small" case, and a
larger increment of maxMTU in the "large" case. There is a floor for
padbytes based on RX_MIN_PACKET_SIZE, which ended up being larger than
intended in the old code by approximately the size of the rx header.
(Some of the adjustments performed are rather opaque, so the motivations
are unclear.)
The more interesting places where accesses to lastPacketSize and
maxPacketSize happen are during the MTU grow events and in
rxi_CheckCall().
In rxi_CheckCall(), the packet size variables are only accessed if
the connection has the msgsizeRetryErr flag set, the call is not timed
out (whether for idleness or during active waiting), and the call has
actually received data. In this case, we conclude that sending packets
failed and decrease the MTU. The old code was quite broken in this
regard, with a reversed sense of conditional for whether a speculative
large packet was outstanding, and a rather large decrease in MTU size
of effectively 128 + RX_HEADER_SIZE + RX_IPUDP_SIZE = 212, when only
a decrease of 128 was intended. The new code corrects the sense of
the conditional and sets the decrease in MTU to the intended value of 128.
With respect to MTU grow events, this change only touches
rxi_SetPeerMtu(), to correct the conditional on whether the MTU update
invalidates/overrides the cached maxPacketSize. There is a window of
values which could cause the old code to incorrectly fail to invalidate
the cached maxPacketSize. Values in this window could result in the old
code being stuck on a bad MTU guess, but should not cause an actual
failure to communicate. That conditional zeroing of maxPacketSize is
the only access to the PacketSize variables in rxi_SetPeerMtu().
maxPacketSize is also checked in rxi_GrowMTUEvent(), but only against
zero to avoid sending RX_ACK_MTU packets needlessly, so it is unaffected
by the issue at hand.
In summary, in certain network conditions, the old code could fail
to find an optimum MTU size, but would always continue to operate.
The new code is more likely to find a better MTU size, and the old
and the new code should interoperate fine with both each other and
themselves.
[kaduk@mit.edu add a few missed cases; expound on analysis in commit message]
Change-Id: I7494892738d38ffe35bdf1dfd483dbf671cc799a
Reviewed-on: http://gerrit.openafs.org/8111
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Currently we panic if we detect an undercount on an afs_conn
structure, as this is a serious bug and can cause corruption and other
issues. But an overcount is never noticed, until the refCount
overflows and looks negative. Log a warning if the refCount gets
really high, so an administrator has a chance at noticing and
notifying a developer before the machine actually panics.
[kaduk@mit.edu use the %p format specifier, mandated by C89]
Change-Id: Ifc291fc10959e4e1c60115813d82a09e5a65ef75
Reviewed-on: http://gerrit.openafs.org/11465
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
The 'indexvalid' and 'datavalid' parameters were really representing 3
different scenarios, not 2 different values with 2 possibilities each.
Change these to a single parameter, 'type', with 3 different values:
DSLOT_NEW, DSLOT_UNUSED, and DSLOT_VALID. Hopefully this will make the
relevant code paths easier to understand.
This should incur no functional change; it is just code
reorganization.
Change-Id: Iac921e74532de89121b461fa0f53ddb778735e0c
Reviewed-on: http://gerrit.openafs.org/9834
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
For Linux, fix_bad_parent (and in 1.6 and earlier, check_bad_parent)
served the purpose of fixing mvid if it was "wrong", for volume-root
vcaches (mvstat == 2).
However, in modern Linux, we never really use mvid for root vcaches.
This would normally be used for looking up ".." entries in the root
dir, but Linux handles that for us.
Specifically, the only times an "mvstat == 2" mvid is used are:
- afs_lookup(), where we specifically check for a ".." lookup. Linux
cannot give us a lookup for "..", since Linux itself services ".."
lookups through the dcache.
- afs_readdir_move(), where we look for ".." entries. Linux does not
use this function, since Linux reimplements afs_readdir() in
afs_linux_readdir(), and so this function is never called.
Of course, mvid is used in many other locations, mostly for "mvstat ==
1" vcaches (mountpoints) and a few other special cases. But these are
the instances where mvid is relevant for root dirs.
So, since mvid is never really used for "mvstat == 2" vcaches on
Linux, don't bother trying to keep it up-to-date. Doing so is just
needless waste, and causes problems when there are bugs in
fix_bad_parent. The mvid field is still updated in cross-platform code
from time to time; removing that would be more complex and possibly
not worth the effort.
Change-Id: I5011ba069e5c8ed947ab6ff8d8dd393241d9c4bf
Reviewed-on: http://gerrit.openafs.org/11615
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Contrast with AFSCONF_NOCELL, which is for when no cell configuration
information is available at all (i.e., a struct afsconf_dir* was NULL) --
this code is used when there is some cell configuration available, but
that configuration does not include the cell name.
Replace the only existing use of AFSCONF_UNKNOWN with this more-informative
error code, leaving AFSCONF_UNKNOWN free for use in other situations.
Change-Id: I989756a960e5377545af43f8e9414d1f2d6476b4
Reviewed-on: http://gerrit.openafs.org/11628
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
With kernel 3.19 struct nameidata becomes opaque. As a result
we cannot rely on STRUCT_NAMEIDATA_HAS_PATH being true for
new kernels.
Rework the conditions here so that STRUCT_NAMEIDATA_HAS_PATH
is only tested when we're using a nameidata structure and
the result matters.
Also modify a configure test to use a nameidata pointer
instead of an actual structure.
Change-Id: I0d71fca44a67570ac3b86151c70f2969dc463f4f
Reviewed-on: http://gerrit.openafs.org/11648
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Back in kernel 2.6 .20 struct file lost its f_dentry field
which was replaced by f_path.To ease transition f_dentry
was defined as f_dpath.dentry in the same header.This
define finally gets removed with kernel 3.19.
Keep using f_dentry in the code, but add a configure test
for the presence of f_path and the absence of the f_dentry
macro so we can add it if its missing.
Change - Id:I8e8a7e4d3ddd861018de50af1eb7315e730ad529
Change-Id: I4b05aa3d37f01e0e675c420cbf941d682c49c69c
Reviewed-on: http://gerrit.openafs.org/11646
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The fields in struct dentry are re-arranged so that d_alias
shares space wth d_rcu inside the d_u union. Some references
need to change from d_alias to d_u.d_alias.
The kernel change was introduced for 3.19 but was also backported
to the 3.18 stable series in 3.18.1, so this commit is required
for 3.19 and current 3.18 kernels.
Change-Id: I711a5a3a89af6e0055381dfd4474ddca2868bb9c
Reviewed-on: http://gerrit.openafs.org/11642
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
namelist and idlist are used as IN parameters to ptserver RPCs that
can be issued by unauthenticated clients. Not having a length limit on
them means anyone can use up a ton of ptserver memory by just issuing
those RPCs with a very large length.
So, put a limit on them. PR_MAXLIST is a constant that already exists,
but is small enough to potentially limit real use, so define a new
OpenAFS-internal value for this purpose.
prlist and prentries are returned from the ptserver to clients, so
also limit them in the same way.
Change-Id: Iaf45639bbae401093354adbfb4daa172fe97ede1
Reviewed-on: http://gerrit.openafs.org/9588
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Revert change Ibab1dd189e7fbc41ca01e7ef7479421c056999f5 since uss
should always be safe to build now that its parser symbols are private.
Change-Id: I65fd2008b037dd36a2c7d3ef8817d4d7dda689d7
Reviewed-on: http://gerrit.openafs.org/11653
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Not all sed versions support inplace editing, so do things ourselves.
Also use the sed version found by configure for consistency.
Change-Id: I6194b8dd6b7abf88d0b0fa36ba871e0ba092ce1e
Reviewed-on: http://gerrit.openafs.org/11655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Move the Linux specific bit of code to reset the root to
afs/LINUX platform specific files. Things that play with
the Linux vfs internals should not be exposed here.
No functional change, but this helps cleanup some ifdef
mess.
Change-Id: Ia27fca3d8052ead45783cb2332c04fe6e99e5d9f
Reviewed-on: http://gerrit.openafs.org/11641
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
This change fixes numerous places where the return values of various
system calls and standard library routines are not checked. In
particular, this fixes occurrances called out when building on Ubuntu
12.10, with gcc 4.7.2 and eglibc 2.15-0ubuntu20.1, when the possible
failure is one we actually do (or should) care about. This change
does not consider calls where the failure is one we deliberately
choose to ignore.
Change-Id: Id526f5dd7ee48be2604b77a3f00ea1e51b08c21d
Reviewed-on: http://gerrit.openafs.org/9979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Change the volUpdateCounter volume macro name to be
consistent with the volume header name.
Change-Id: I55f55f2c084135e9598c194ed9081fce800ddfe9
Reviewed-on: http://gerrit.openafs.org/11318
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
In e34e0d1 the Debian packaging was removed. Some traces are still left, so
remove those as well.
Change-Id: I1d5c22181f59b2bee42dd34c9f3a043297d294a2
Reviewed-on: http://gerrit.openafs.org/11630
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
DAFS introduced the VSALVAGING error code which is returned when a vnode
cannot be put and a volume has been scheduled to be salvaged.
Update the afsfileprocs to not assert on VSALVAGING, as well as the
VSALVAGE error code.
For example, VPutVnode() and VVnodeWriteToRead() may call
VRequestSalvage_r() which will set the error code to VSALVAGING when a
salvage is requested.
This was noticed during a code inspection.
Change-Id: I6cacfe92347bc5af57defef17b8a2f98c5302f93
Reviewed-on: http://gerrit.openafs.org/10611
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
We clearly do not need to modify the format string; declare it const.
This makes the signature of bozo_Log identical to FSLog, which can
make it easier to use these functions interchangeably.
Change-Id: I89ae9babec2c4e8714019f58fe29dacc7283ae15
Reviewed-on: http://gerrit.openafs.org/10830
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
A valid fssync-debug query <volid> command issued against
a DAFS fileserver will produce the following error messages in FileLog:
SYNC_getCom: error receiving command
FSYNC_com: read failed; dropping connection (cnt=1)
Routine dafs_prolog() issues a tentative FSYNC_VOL_LISTVOLUMES operation
to test for the presence of a DAFS fileserver. If DAFS is detected,
we then call dafssync-debug for the original requested operation.
However, the FSYNC connection for the tentative LISTVOLUMES operation
is never closed. This results in the errors when the command completes.
Close the test connection.
Change-Id: I3c987289408407ba38cd184b7518e72ee1ae9cfc
Reviewed-on: http://gerrit.openafs.org/10476
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The volserver only needs vl_errors.c to be locally generated, not
vlserver.h; in fact, the only consumers of vlserver.h in src/volser/
consume it via afs/vlserver.h.
Instead of reaching over to ../volser for the generated volerr.c,
generate our own local copy, as well as the volser.h generated from
the same error table -- volser.h is included with double-quotes from
the volser sources.
Add the appropriate dependencies on volser.h, and remove the unneeded
dependencies on vlserver.h
Change-Id: Ic6e728fa455419cc8e95dc25c41ed6d6b7d20934
Reviewed-on: http://gerrit.openafs.org/11380
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Consider the following situation:
- A client sends a data packet to a server, using a security class
that requires a challenge
- The server responds with a challenge
- The server is restarted
- The client responds to the challenge with a response
In that situation, the server will process the response, but since the
server was restarted, it has no knowledge of the challenge that was
sent. This generally means that we error the connection, since the
given response is not valid. For rxkad with modern endpoints, this
results in an RXKADPACKETSHORT error, since we interpret the response
as an 'old' response, but it's actually a 'v2' response, so we
interpret the fields in the response as garbage.
This means that the client gets a connection error when the client did
nothing wrong, and there's no way for the client to distinguish this
from a real connection error.
One way to solve this would be to send a Challenge packet to the
client immediately when we detect that this situation has occurred.
However, if we do that, then we never see a data packet with a
checksum, so we fall back to using "old" challenges and responses. And
in general, that would cause the server side to never see a data
packet during the connection negotiation, which is unusual and I am
concerned there may be other niggles of odd behavior that may occur in
that scenario.
So instead, to fix this, make the server ignore responses in this
situation (that is, if we haven't sent out any challenges yet).
Clients will eventually resend the data packet, and we will go through
negotiating the connection security like normal. This should never
cause any new problems, since dropping a challenge packet must be
handled anyway (sometimes packets just get dropped). And a client will
never hang on sending the same response over and over again; clients
only ever send a Response in response to a Challenge packet.
Change-Id: Id3fae425addb2ac8ab60965213b3ebca2e64ba5d
Reviewed-on: http://gerrit.openafs.org/10315
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Rebuild the vldb free chain in addition to the hash chains when
vldb_check is run with the -fix option. Print a FIX: message for
entries added to the free chain.
Example vldb with a broken free chain.
$ vldb_check vldb.broken
address 199364 (offset 0x30b04): Free vlentry not on free chain
address 223192 (offset 0x36818): Free vlentry not on free chain
address 235180 (offset 0x396ec): Free vlentry not on free chain
Scanning 1707 entries for possible repairs
$ vldb_check -fix vldb.broken
Rebuilding 1707 entries
FIX: Putting free entry on the free chain: addr=199364 (offset 0x30b04)
FIX: Putting free entry on the free chain: addr=223192 (offset 0x36818)
FIX: Putting free entry on the free chain: addr=235180 (offset 0x396ec)
Thanks to Kostas Liakakis for reporting this bug.
Change-Id: I57d6b17263ffe5f8818f70f8260a0dce8d85ab1f
Reviewed-on: http://gerrit.openafs.org/11598
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 83f85c9ad6 updated the arguments
we give to configure, since --enable-disconnected and --with-krb5-conf
no longer exist. But, it only updated the configure options for the
userspace configure, and did not update the configure invocation for
building kmod kernel modules.
Update the other configure invocation, so they match and both of them
avoid using outdated configure options.
Change-Id: Ia7fe16a373b5feabd4060bd85fbf9220407082f5
Reviewed-on: http://gerrit.openafs.org/10623
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Attempt to make the parser in uss private so that it doesn't
conflict with other libraries that might leak their parser symbols.
Change-Id: I15b52f55b419b3bbc788ced9660bc41163e2be36
Reviewed-on: http://gerrit.openafs.org/11533
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Fall back to `uname -r` if we aren't probing for kernel sources,
as we still need to know for the rest of the build. While this
could be worked around by explicitly passing the sysname as an
argument, this seems friendlier.
Change-Id: I0db75ba5fc7d1f5ec08d27dfce6858b968b6ce28
Reviewed-on: http://gerrit.openafs.org/11552
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
It was reported in RT 131976 that on Linux some file
corruption was observed when doing mmap writes to
a file substantially larger than the cache size.
osi_VM_StoreAllSegments drops locks and asks the OS to flush
any dirty pages in the file 's mapping. This will trigger
calls into our writepage op, and if the number of dirty
cache chunks is too high (as will happen for a file larger
than the cache size), afs_DoPartialWrite will recursively
call afs_StoreAllSegments and some chunks will be written
back to the server. After potentially doing this several
times, control will return to the original afs_StoreAllSegments.
At that point the data version that was stored before
osi_VM_StoreAllSegments is no longer correct, leading to
possible data corruption.
Triggering this bug requires writing a file larger than the
cache so that partial stores are done, and writing enough
data to exceed the system's maximum dirty ratio and cause
it to initiate writeback.
To fix, just wait until after osi_VM_StoreAllSegments to
look at and store the data version.
FIXES 131976
Change-Id: I959f06b5a7a51171e7ed70189620e9d11d52efa2
Reviewed-on: http://gerrit.openafs.org/11644
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
