Instead of trying to bind to port 7101, and then retrying if
the port is in already in use, let the os find an available
port for scout and xstat_fs_test.
This fixes a bug where scout and xstat_fs_test do not call
rx_Finalize() before retrying rx_Init() with a different port
number, causing the program to crash later when more than
one copy of xstat_fs_test and/or scout are running at the same
time.
Change-Id: I64e4916b03b1cae20ef36bb1ae293885962677e7
Reviewed-on: http://gerrit.openafs.org/10707
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The use of the bdi_init function now gets a warning because the
return value is unused and the function is now defined with
the warn_unused_result attribute.
Assign and check the return value.
Change-Id: I78ae4ea356aef8c9dabe75179ad67db1fd64c28b
Reviewed-on: http://gerrit.openafs.org/10530
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Currently, if a new Rx connection comes in from a host we already have
a host struct for, we make a TellMeAboutYourself (TMAY) call to the
given host, to verify the UUID (and caps, interface info, etc) is what
we expect it to be. That is, if it's still the "same" host that we
know about. This is necessary because we otherwise have no way of
telling if the Rx connection is from the same host, or from a new host
that just happens to have the same IP address (e.g. in the case that
hosts are moving around and changing IPs). We do this while the host
is locked, so we only issue these TMAY calls one at a time.
If a large number of Rx connections come in from the same host at
around the same time, this can result in a lot of TMAY requests being
issued against the host, even for hosts that never change IPs and
never do anything strange. In these situations, issuing so many TMAYs
is useless. If we have several calls waiting to lock the host to issue
a TMAY, some of the extra TMAY calls are provably useless. So instead
of calling TMAY repeatedly, remember what the last successful TMAY
result was, and reuse it for the "provably useless" calls.
Note that this 'cache' stores the actual raw results of
TellMeAboutYourself. We could save some memory by storing just how we
interpret that data later on in h_GetHost_r, but this way results in
way simpler h_GetHost_r logic. Since, we can use the same code paths
as for a "real" TMAY call.
Change-Id: I6df74e625e90499bd64c9eb34f20db440f6605a6
Reviewed-on: http://gerrit.openafs.org/9711
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Commit 1d8937b860 turned crfree on
DARWIN into an inline function to work around an error flagged by
clang. A side effect of this is that the address passed to
kauth_cred_unref will not be the actual address of the value given to
crfree; we are instead giving kauth_cred_unref the address of our
function argument in order to adhere to the semantics of a function
call.
kauth_cred_unref seems to just take a pointer to the cred pointer in
order to set the value to effectively NULL afterwards, so this is not
a huge deal. However, this does mean that our current implementation
undoes any of the safeguards intended by making kauth_cred_unref work
this way in the first place.
So, revert 1d8937b860 and put the crfree
definition back to the way it was. Fix the caller in
afs_StoreOnLastReference to not cause an error by just assigning the
cred pointer to a temporary value. While it's not ideal that some
callers may need to do this, this is the only place where this is
necessary and it's more of an artifact of the weirdness of storing a
cred pointer in linkData, which probably should be changed anyway.
Change-Id: I50557901203d22a7b19028be551eb40f0c4cd751
Reviewed-on: http://gerrit.openafs.org/10614
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Specify the VSW_STATS flag to the vfsdef_t structure we give to
Solaris. This turns on statistics that can be retrieved via fsstat(1M)
and allows the fsinfo::: DTrace provider to work with AFS files.
We don't need to actually maintain these statistics; Solaris does that
for us. This flag just signifies that our vfs_t structure is capable
of storing the information. Since we get our vfs_t from Solaris (via
domount(), it gives us a vfs_t when it calls our afs_mount function)
and do not allocate a vfs_t ourselves, we are safe and this is fine to
do.
Change-Id: I356df91ea409245f0c5b1e4ef693ac28ad8f11b2
Reviewed-on: http://gerrit.openafs.org/10679
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The on disk uniquifier counter is set to 200 more than the current
nextVnodeUnique counter when the volume information is updated to disk. When
the nextVnodeUnique is near UINT32_MAX, then the uniquifier counter rolls
over. This can happen during a volume header update due to
VBumpVolumeUsage_r().
With this change, the nextVnodeUnique customer is reset to 2 and the
uniquifier is reset to 202 when a roll over occurs. (uniquifier of 1 is
reserved for the root vnode.)
With this change, the number of possible uniquifier numbers is limited to
200 less than UINT32_MAX.
The following shows a series of vnode creation/deletions to illustrate
the uniquifier rollover before this commit:
fid = 536870918.4.4294967114, nextVnodeUnique = 4294967115, uniquifier = 4294967295
fid = 536870918.4.4294967115, nextVnodeUnique = 4294967116, uniquifier = 4294967295
fid = 536870918.4.4294967116, nextVnodeUnique = 4294967117, uniquifier = 21
fid = 536870918.4.4294967117, nextVnodeUnique = 4294967118, uniquifier = 22
and after this commit:
fid = 536870918.4.4294967115, nextVnodeUnique = 4294967116, uniquifier = 4294967295
fid = 536870918.4.4294967116, nextVnodeUnique = 2, uniquifier = 202
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 202
fid = 536870918.4.3, nextVnodeUnique = 4, uniquifier = 202
Change-Id: I93c8a7cf47e39b8701265d6507cfc4f8c1352ddc
Reviewed-on: http://gerrit.openafs.org/10617
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Fixes for the per volume nextVnodeUnique counter roll over. Uniquifier number 1
is reserved for the root vnode, so reset the unique count to 2 when the
nextVnodeUnique counter rolls over.
Update the disk backed V_uniquifier count when the in-memory nextVnodeUnique
counter rolls over during the creation of a new vnode. If the nextVnodeUnique
rolls over when V_uniquifier is UINT32_MAX, then the V_uniquifier is not updated
and remains at UINT32_MAX until the next VUpdateVolume_r() call for the volume.
This bug is usually masked by the VBumpVolumeUsage(), which on every 128 volume
accesses, bumps the V_uniquifier to be 200 more than the current
nextVnodeUnique counter. This causes the V_uniquifier to roll over before
reaching UINT32_MAX. (The number of access before updating the headers is set
in the usage_threshold volume package option, which is currently set to 128 by
default.)
The following shows the unique counters for a series of vnode
creation/deletions before this commit. The nextVnodeUnique rolls over to 1,
and the uniquifier is not reset. The `usage_threshold' was set to a value
greater than 200 to avoid the VBumpVolumeUsage() calls during this test run.
fid = 536870918.4.4294967294, nextVnodeUnique = 4294967295, uniquifier = 4294967295
fid = 536870918.4.4294967295, nextVnodeUnique = 0, uniquifier = 4294967295
fid = 536870918.4.1, nextVnodeUnique = 2, uniquifier = 4294967295
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 4294967295
The following shows the unique counters after this commit:
fid = 536870918.4.4294967294, nextVnodeUnique = 4294967295, uniquifier = 4294967295
fid = 536870918.4.4294967295, nextVnodeUnique = 0, uniquifier = 4294967295
fid = 536870918.4.2, nextVnodeUnique = 3, uniquifier = 203
fid = 536870918.4.3, nextVnodeUnique = 4, uniquifier = 203
Change-Id: I438670200bf97baeac1486eda7df4cf243aabfc4
Reviewed-on: http://gerrit.openafs.org/10616
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
We have a vcache and need a vnode, so AFSTOV() is the right macro,
not VTOAFS().
It's kind of unfortunate that --enable-checking doesn't catch this.
Change-Id: I924649918dd0149b5fd7e4380b5f2e49d21fc8c4
Reviewed-on: http://gerrit.openafs.org/10702
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Currently, we can clear afs_CacheTooFull here, even if
afs_CacheIsTooFull() doesn't agree that the cache is no longer 'too
full'. This could theoretically result in afs_CacheTooFull being
cleared, even though the cache is indeed 'too full', according to
afs_CacheIsTooFull(). Just break here, and let afs_CacheIsTooFull()
decide.
This reverts a small part of 488c7c9785.
This part doesn't seem important to the functionality in that commit,
though; the rest of that commit is still here, and avoids the extra
work if we have calculated no needed space to free.
Change-Id: If0adce7fa2e88a970ddb202de02c8ff048d2ad15
Reviewed-on: http://gerrit.openafs.org/10460
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: Derrick Brashear <shadow@your-file-system.com>
- The comments preceding the afs_CacheIsTooFull macro, describing the
cache-related high and low water marks, are a little out of date.
We start freeing on 90% space, not 95%, and we also can take into
account how many free/used chunks we have.
- afs_WakeCacheWaitersIfDrained looks at the number of non-used (free
or discarded) blocks, not just free blocks.
Change-Id: I5bf923b3c24993294e752f4312737815d0102779
Reviewed-on: http://gerrit.openafs.org/10459
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit a84c6b0ece changed this so we
don't just discard an incoming request if the call already had an
error. But if the call already has an error, rxi_WaitforTQBusy is a
no-op, so checking if the error has "changed" is unnecessary and can
be confusing. Just bypass this whole block if the call already has an
error.
Discussed during the 5 Dec 2012 release-team meeting.
Change-Id: Id57d65736f3228d4e7595f56800f42c52e83ef39
Reviewed-on: http://gerrit.openafs.org/8748
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Calculate this during initialization, not every time we want to use
it.
Change-Id: I931d2f3f0b4b99add682c098dd51f03c9942f5b4
Reviewed-on: http://gerrit.openafs.org/9710
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Oct 29 2007 was a Monday, not a Tuesday. rpmbuild does actually yell
at us about this, so fix this so it will shut up.
Change-Id: I5e13f227ed62c4bbb7ac72f2c844136648c935c7
Reviewed-on: http://gerrit.openafs.org/10621
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ken Dreyer <ktdreyer@ktdreyer.com>
With Fedora 20, Fedora now separates the variant from the rest of the
kernel version with a plus (+) instead of a period (.) . This results
in directories called e.g. 3.12.5-302.fc20.i686+PAE, where right now
we look for 3.12.5-302.fc20.i686.PAE.
Use this new directory scheme for Fedora 20 builds, so we can build
against non-default kernel variants on Fedora 20 and beyond.
Change-Id: I309272f4f4f740058c48e92530e40a1c64d63668
Reviewed-on: http://gerrit.openafs.org/10620
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ken Dreyer <ktdreyer@ktdreyer.com>
We currently look for "fc1?" (that is, fc10 through fc19) when trying
to munge the kernel version in some ways. This broke on Fedora 20,
since 20 obviously does not match "fc1?". Similarly, we look
specifically for "el6" for RHEL6 versioning quirks, but these will
break on RHEL7 and beyond.
Change the version checks so that this will work all the way through
Fedora 99 and RHEL 9. That won't work forever, but it will keep us
working for a few versions if the versioning quirks do not change.
Change-Id: I64dfd483eb2cfa57d67c97ae6db09be5bb020195
Reviewed-on: http://gerrit.openafs.org/10618
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Reviewed-by: Ken Dreyer <ktdreyer@ktdreyer.com>
The old initializer was incomplete (initializing only one of the four
fields in the struct), which prompted warnings from clang
(-Wmissing-field-initializers):
../../../openafs/src/auth/ktc.c:149:2: warning: missing field 'server'
initializer [-Wmissing-field-initializers]
Since the variable is at file scope, it will be initialized to all
zeros anyway, and there is no need for an explicit initializer.
Change-Id: Ib7690759ec3403d1913852e30bb553ef8ac8f019
Reviewed-on: http://gerrit.openafs.org/10686
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
AFSCommonWrite() can return STATUS_PENDING if the write has been
deferred. In that case, the function exit must not:
* Update the Valid Data Length
* Purge the cache
* or do anything else related to the request
Change-Id: Ib34bef3a1d56d452babcaf1f3cfbf77fe8f93388
Reviewed-on: http://gerrit.openafs.org/10685
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
After CcDeferWrite() is called we no longer have access to the
current Irp. If we mark it deferred after calling CcDeferWrite()
we might mark the wrong thing.
Change-Id: Id4b1bbd241b5e2acafc8d015e85966cb80518dde
Reviewed-on: http://gerrit.openafs.org/10684
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Separate connection objects are maintained for use when accessing
replicated and single source volumes. If the matching connection
type cannot be found while holding the cm_connLock shared a second
search is performed after the lock is upgraded to an exclusive lock.
This second connection search was not enforcing the replication criteria.
Change-Id: I408a5d87c3a82da5235fa2255db7d1d7a6bcb6d9
Reviewed-on: http://gerrit.openafs.org/10681
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
In cm_ConnByServer() there is no need to hold the cm_connLock across
the cm_GetUCell() call. Obtain the cm_ucell_t object before the
cm_connLock is obtained.
Change-Id: I971b55e0aae7748b59895785c1c22b5461c4fd35
Reviewed-on: http://gerrit.openafs.org/10680
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Use LARGE_INTEGER to avoid the need for shifting and DWORD casts.
Take into account the size of time_t.
Change-Id: I056d920894b661ebb2060a5010efd9a0cd5a4a5d
Reviewed-on: http://gerrit.openafs.org/10673
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The bHoldFid parameter is after the bNoFollow parameter. The
two values were swapped resulting in unnecessary VLDB lookups.
Change-Id: Ia94bd761576d54e9dde847385a4900f2d915c34d
Reviewed-on: http://gerrit.openafs.org/10636
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The algorithm used to ensure "chunk size" operations attempts to
enforce aligned chunks. There are two problems:
1. an aligned chunk range may extend beyond the end of the file.
2. an aligned chunk might end before the requested length of the
active write.
Protect against scanning beyond the end of the file and do not truncate
writes.
Change-Id: Ibe6caebd78f73d2c93bfef0dcebef379ca843994
Reviewed-on: http://gerrit.openafs.org/10625
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
BUF_HASH takes to 4-byte integers not three and therefore cannot use
the basic opr_jhash which assumes a minimum of three 4-byte integers.
Change-Id: I7f30351025b3e9cd2156f772b0ed550b20964ad7
Reviewed-on: http://gerrit.openafs.org/10624
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
A few places in this file assume that our dbserver IP addresses are
"long"s. A long int can be 8 bytes on some platforms, but we know
these IP addresses are all 4-byte integers. In the rare instances
where we have the maximum number of dbservers, this can overwrite a
bit of extra memory. This can also result in a misaligned access on
platforms such as SPARC v9, since the elements of he->h_addr_list are
not guaranteed to be 8-byte aligned.
So instead, treat these as 4-byte integers. For copying out of
he->h_addr_list, also use a memcpy anyway to be safe, since we are not
guaranteed alignment.
Change-Id: I1afd6e49df32693f86392cb39ce8d7477422aa94
Reviewed-on: http://gerrit.openafs.org/10599
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The preuninstall scriptlet of the openafs RPM removes /afs. If, for
whatever reason, that directory does not exist, the scriptlet will
fail and hence break the deinstallation of the openafs package. The
proposed patch makes the scriptlet evaluate to true even if the /afs
has been removed by some other means and allows the package to be
uninstalled.
Change-Id: I3340c94521e15c56fe10840aff7b0b1080009c10
Reviewed-on: http://gerrit.openafs.org/10581
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Currently, we use sock_create to create our Rx socket. This means that
accesses to that socket (sendmsg, recvmsg) are subject to SELinux
restrictions. For all recvmsg accesses and some sendmsg accesses, this
doesn't matter, since the access will be performed by one of our
kernel threads (running as kernel_t or something similar, which is
unrestricted). Such as: the rx listener, a background daemon, the rx
event thread, etc.
However, sometimes we do run in the context of a normal user process.
For some RPCs like FetchStatus, we tend to run the RPC in the
accessing user thread, which can result in us sendmsg()ing the data
packets with the initial arguments in the user thread. We can also
send delayed ACKs via rx_EndCall, and possibly a variety of other
scenarios.
In any of these situations when we are sendmsg()ing from a user
thread, SELinux can prevent us from sending to the socket, if the
calling user thread context is not able to write to an afs_t
udp_socket. This will result in packets not being sent immediately,
but the packets will be resent later, so access will work, but appear
very slow. This can easily happen for processes that are specifically
constrained by SELinux; for example, webservers are often constrained,
even if most of the rest of the system is not. This can be noticed by
seeing the 'resends' and 'sendFailed' counters rising in 'rxdebug
-rxstat', as well as noticing SELinux access failures if 'dontaudit'
rules are ignored.
To avoid this, use sock_create_kern to create the Rx socket, to
indicate that this is a socket for use by kernel code, and not
accessible by a user. This should cause us to bypass any LSM
restrictions (SELinux, AppArmor, etc). Add a configure check for this,
since this function has not always existed, according to
<https://lists.openafs.org/pipermail/openafs-devel/2004-June/010651.html>
Change-Id: I77e7f87e93be4d750d398e01dc1634efd80657bc
Reviewed-on: http://gerrit.openafs.org/10594
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
This comment refers to the fact that we used to be just checking for
SELinux to see if we should pass that extra argument. Ever since
commit cb1b41b159, we do have a better
test for this.
Change-Id: Idf2ff879f05774f49a11d04f87579afccf385b57
Reviewed-on: http://gerrit.openafs.org/10593
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
It was originally committed in an unsorted state.
Change-Id: Ife43b60cd625eae5062865942fc5c8956d6b6aab
Reviewed-on: http://gerrit.openafs.org/10583
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The current code has afs_putname defined as
kmem_cache_free (names_cachep, (void *) name);
This is wrong and will cause a double -free when syscall auditing is
enabled. Fix it to call putname properly.
Instead of that, just create a new afs_getname function that doesn't
bother with struct filename at all, and use that unconditionally.
Signed-off-by:Jeff Layton <jlayton@redhat.com>
Change-Id: I1cd58a7e528abfeb7473cf47ae4cff5b8c8f419c
Reviewed-on: http://gerrit.openafs.org/10547
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeff Layton <jlayton@poochiereds.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
On MacOS X 10.9, the compiler has switched to LLVM and as a consequence
generates an error if there is a space between a macro invocation and
the starting left parenthesis.
Based on code originally done by Matt Haught <dmhaught@ncsu.edu>.
Change-Id: I28848f5294d0575d8abb1759c202cc3c2db85ac2
Reviewed-on: http://gerrit.openafs.org/10540
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Based on work originally done by Matt Haught <dmhaught@ncsu.edu>.
Change-Id: Ibc7d79953667dfdfcc2e6c5c1c4c77249f11f4ad
Reviewed-on: http://gerrit.openafs.org/10539
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Based on work originally done by Matt Haught <dmhaught@ncsu.edu>
Change-Id: I331cfc0040fab526c32e24f6af970f352f0a0a8e
Reviewed-on: http://gerrit.openafs.org/10538
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Since d2d591caf2 the file server no
longer performs a PRSFS_READ access check for the GetVolumeStatus RPC.
The cache manager should no longer test for PRSFS_READ as a means of
avoiding RPCs that are known to fail.
Change-Id: I67bd849d337d87657db8e1f0ed2839367b7972a8
Reviewed-on: http://gerrit.openafs.org/10532
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
rw (a test program for lwp) needs libopr to build
Change-Id: I489e675f5a1b845c7a8083466b44a73af305f8b8
Reviewed-on: http://gerrit.openafs.org/10517
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
introduced in Change I1e84969b. It does not
follow the overall style.
Change-Id: I5f68fdf425b365d69ee94680cef014de679cf6ff
Reviewed-on: http://gerrit.openafs.org/10529
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
All of the Cc and Mm functions are wrapped in try/except blocks.
The purpose is to ensure that Cc and Mm do not return an error as
an exception which could result in the afs redirector failing to
release a resource. Instead of calling the AFS exception handler
just handle the exception with EXCEPTION_EXECUTE_HANDLER. This permits
the __except block to capture the exception code.
The AFS exception handler will throw its own exception if the
AFSDebugFlags AFS_DBG_BUGCHECK_EXCEPTION bit is set. This is helpful when
debugging exceptions thrown by errors in the afs redirector code. It is
not helpful when a Cc function throws an exception. For example,
CcReadCopy() will throw STATUS_DELETE_FILE as an exception if an attempt
to read from a deleted file is initiated. This should simply fail the
read operation not BSOD the system.
Change-Id: I2fd1d4db530600441272e59353fbf28b831e2691
Reviewed-on: http://gerrit.openafs.org/10524
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If there is no redirector device present, return WN_NO_NETWORK
to indicate that this network provider is not ready for browsing.
Change-Id: I3e33769bb2d52a59b0ff993aa07e89d959d60800
Reviewed-on: http://gerrit.openafs.org/10523
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
It has not been connected to the build since at least the 1.2 days
and should be considered dead code.
FIXES 131777
Change-Id: Id1551e7f9f543934dc8755a29f46aa7b905bfadd
Reviewed-on: http://gerrit.openafs.org/10522
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Background:
cm_scache_t objects representing Freelance volume (cell=-1, volume=-1)
are special because they are populated from the Freelance mountpoint
and symlink tables. These tables are in turn generated from the
registry. The tables are regenerated on-demand after the execution of
cm_noteLocalMountPointChange() which increments cm_data.fakeDirVersion
which becomes the new data version value for the (-1.-1.1.1) directory
object.
The next time that cm_GetSCache() is called for a Freelance object
the fake root directory is rebuilt by cm_InitFakeRootDir(). Since the
vnode values are not persistent with regards to directory entry names the
FileId unique is used to distinguish the various versions.
cm_data.fakeUnique is incremented with each call to cm_InitFakeRootDir().
Each time cm_noteLocalMountPointChange() is executed the afs redirector is
notified of the data version change which will force the redirector to
rebuild its view of the directory the next time a path evaluation requires
evaluation of the root (\afs). In other words, on the next request.
If cm_noteLocalMountPointChange() is executed multiple times there is the
possibility of a race between the redirector and the service. When the
race is lost the redirector receives an invalidation event for -1.-1.1.1
as it is in the process of rebuilding the directory contents. The
redirector ends up believing it has the most recent data version when it
doesn't but the service no longer has Freelance mountpoint and symlink
tables representing the requested data version. Hence, the mountpoints
and symlinks end up as CM_SCACHETYPE_INVALID.
fs flushfile and fs flushvolume both had explicit checks to prevent
flushing Freelance objects because each call to cm_FlushFile() on a
Freelance object would execute cm_noteLocalMountPointChange() triggering
the race.
The Problem:
fs flushall is not executed on a specific object (volume or file).
Therefore there was no explicit check to prevent execution against
Freelance objects. For each cm_scache_t in the cache cm_FlushFile() is
processed. If there are N Freelance mountpoints and symlinks, there will
be N+1 calls to cm_noteLocalMountPointChange() in quick succession. Not
only does this risk losing the race described above but it is extremely
wasteful as the Freelance tables may be repeatedly regenerated.
This Patchset:
This patchset re-organizes the Freelance processing in the flush code
paths. cm_FlushFile() and cm_FlushVolume() can simply no longer be
successfully executed against a Freelance object. Both will return
CM_ERROR_NOACCESS.
"fs flush <file>" is not permitted against Freelance objects.
"fs flushvolume <path>" will execute cm_noteLocalMountPointChange() once if
the path is a Freelance object.
"fs flushall" continues to execute cm_FlushFile() on all cm_scache_t
objects. The calls on Freelance object will fail. After all cm_scache_t
objects are flushed then cm_noteLocalMountPointChange() will be executed
once to force the Freelance directory to be rebuilt.
This patchset does not address the race but significantly reduces the
likelihood the race will be lost.
Change-Id: I298dad453432001b7b2e6f4533ddee17e041b02e
Reviewed-on: http://gerrit.openafs.org/10521
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
When processing a "fs flush*" command, reset the the cm_scache_t
mountPointStringp which contains the known mountpoint or symlink
target information.
Change-Id: I72bba6101699e82649eed226cdfc73077b13de92
Reviewed-on: http://gerrit.openafs.org/10520
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Commit b7f4f2023b broke builds against
older kernels which don't have bool defined in linux/types.h . Fix
this by using unsigned char instead of bool for the static inline
functions.
Change-Id: Icbb82446ef66edd2650f33135ed6ccd2b8a920b2
Reviewed-on: http://gerrit.openafs.org/10483
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Add support for an extra argument to afs_symlink() to return the
newly-created symlink vnode if requested (this is needed on OS X
Mavericks). On OS X Mavericks return the newly-created symlink vnode in
the symlink vnops functions, on all other platforms ignore it.
It turns out that technically OS X has required the symlink to be
created for a while, but code inside of symlink() would call namei() on
the symlink name if the returned vnode point was NULL. The difference
is that on Mavericks the Manditory Access Control Framework has been
enabled, and that turns on some extra code which unconditionally calls
vnode_mount() on the returned vnode pointer, which ends up causing a
panic
Change-Id: I33b2f51cd10f76689eb9868eb05800ab493087c4
Reviewed-on: http://gerrit.openafs.org/10474
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
CM_REQ_NORETRY is set by threads that want all errors returned
immediately. However, there are some errors that should never
be returned:
RX_MSGSIZE
RX_CALL_BUSY
VNOSERVICE
RX_CALL_IDLE
RXKADEXPIRED
VICECONNBAD
VICETOKENDEAD
For these errors even if the thread has requested no retries a RPC
retry must be performed.
Change-Id: I692f65a9fdbbf27fc880ac8912fc72c1d1357c6d
Reviewed-on: http://gerrit.openafs.org/10470
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
These are coming from the stack and as such they might not be NULL.
Change-Id: Ia5c6efd08574b4de05a11dceae47021b0160395b
Reviewed-on: http://gerrit.openafs.org/10475
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
when it is required. In some linux-kernels (like in SLES11 SP3)
it is not done automatically and the compilation fails.
Change-Id: I1e84969b26e87e36893b071103325a7a532ebbf9
Reviewed-on: http://gerrit.openafs.org/10471
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Clean up references to a header file which was removed some time ago.
Change-Id: I2ddc26afc01edf84bb1bdb21a3488c88dd6c9775
Reviewed-on: http://gerrit.openafs.org/10318
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
