For CM xstat collecton 0 (function call statistics), there are many
more stats given to us on the wire than we currently print. Change
this so we print out everything in the afs_CMCallStats struct.
Change-Id: I959571731fe8bf2a714e4cb3b47c52c39c516621
Reviewed-on: http://gerrit.openafs.org/7047
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
rx_ReadProc and rx_ReadProc32 originally used temporary variables
(which were, at one time, declared as "register") to hand optimise
a couple of routines. With the removal of register throughout our
code, this is no longer helpful.
Change-Id: Id21a931408489b985b726af620a687b838303a86
Reviewed-on: http://gerrit.openafs.org/6997
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
An enumerated directory was not validated properly if
AFSValidateEntry() was called with PurgeData == FALSE even
when a data version change was detected. Now it does.
FIXES 130636
Change-Id: Ic5d2fd62b40fb16652fc09d459caf43905566d37
Reviewed-on: http://gerrit.openafs.org/7012
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
don't require things which don't exist on el5. do require them
in el6. require kernel-devel if building modules
don't do anything involving the kernel if not building modules
if we can figure out that we don't have 2.4 based on the version,
avoiding the need to depend on kernel-devel just to build an srpm.
Change-Id: I4bef6a00f50935b8efa057b42cd2147a22c0c1e6
Reviewed-on: http://gerrit.openafs.org/6985
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
previously, a "cached" repo which was assumed to be of the same
releasever and arch of the host was created in /var/tmp,
which would screw up repoquery across a multiple-OS-build.
well, you can tell repoquery what you really mean. so now we do.
Change-Id: I5f477e4eeddb755fcd410a37a2b58e1334da2863
Reviewed-on: http://gerrit.openafs.org/6991
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Commit 64778fd7be removed some '#ifdef
KERNEL' blocks, but for one block in SOLARIS/osi_machdep.h, the wrong
trailing #endif was removed. This effectively makes the last part of
the file Solaris 10+ only, and bypasses the header guard. On systems
before Solaris 10, this causes us to lose the osi_procname definition,
which eventually shows up as an undefined symbol.
So, reinstate the original #endif, and remove the correct #endif
instead.
Change-Id: I28a78dabc2c65abeadc003b95600026c3cb68e37
Reviewed-on: http://gerrit.openafs.org/7042
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
cm_GetNewSCache was leaking a valid cm_scache_t pointer in some
failure cases. On failure, explicitly set the return value to
NULL.
Change-Id: I074b278f969224aa535abe256ac33a90d0f4e62d
Reviewed-on: http://gerrit.openafs.org/7037
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The conn->callNumber array should be protected by the conn_call_lock
since the conn_call_lock is what protects the binding of calls to
connection channels.
Change-Id: I9f9b4e8f90d1e4ebbc4429af286358807784d84f
Reviewed-on: http://gerrit.openafs.org/6629
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The conn->conn_call_lock is held before call->lock in the lock
hierarchy which is violated within rxi_FreeCall(). While the
deadlock is rare, it is possible and has been experienced on
both Windows and Linux.
Change the signature of rxi_FreeCall to return 1 if it frees
the call and 0 if it does not.
Due to the lock hierarchy violation use MUTEX_TRYENTER()
to attempt to obtain the conn->conn_call_lock. If the lock
cannot be obtained set the call state to dally and
return. If the conn_call_lock can be obtained, behave as
we did before this patchset.
Only increment the callNumber if the original call->state
was dally or hold and the conn_call_lock could be obtained.
We must not increment the callNumber otherwise. Doing so can
result in call numbers being skipped when the conn->call slot
is reused.
Change-Id: Ic10bd2004e9b06df319c2f2efaa0b37bcb90c896
Reviewed-on: http://gerrit.openafs.org/6443
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
AFSRetrieveFileInformation does not parse the complete path.
That information is available in the Ccb->NameArray. If the
object on which AFSRetrieveFileInformation is called is a
relative symlink containing ".." references, the full contents
of the evaluated path is required for context. Pass the
Ccb->NameArray so that it is available.
Change-Id: Id02d3fb47df74c0a0de849eb10550be76150ce8b
Reviewed-on: http://gerrit.openafs.org/7020
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
AFSIsEqualFid() should use the hash value included in the FileId
as part of the comparison algorithm.
Change-Id: I2723e2e9795ce16869c6a0dc33611078b04a6a28
Reviewed-on: http://gerrit.openafs.org/7017
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
In the SMB modules, calls to cm_FindACLCache() were not
holding the cm_scache_t rwlock writed locked as required.
Change-Id: I213912eb8dd570ea918d92602c647e6aed8cfccb
Reviewed-on: http://gerrit.openafs.org/7015
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Change the test in cm_HaveAccessRights related to Freelance
mode. All objects in the freelance cell and root volume
by definition have access rights.
Change-Id: Ibb96b12c15728bc6b711b3d7f2ad892c55109cbf
Reviewed-on: http://gerrit.openafs.org/7008
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Do not drop and acquire locks if the cm_scache_t does not
have a callback.
Change-Id: I6f84729838e7e4c2d84c0a40f0811ed837b79287
Reviewed-on: http://gerrit.openafs.org/7007
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Save the time at which a callback was issued. This can be
used in a later patchset to determine if a callback was issued
after a negative access entry for a {fid,user} pair.
Change-Id: Iab54eb729fd5f2a2daf4855b7e7e75245dc28051
Reviewed-on: http://gerrit.openafs.org/6995
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
cm_aclent.h defined cm_TGTLifeTime() as a macro that always
returned 0x7fffffff. Implement cm_TGTLifeTime() as a function
that returns the actual token lifetime.
Change-Id: I8b19626395f536db248ae8324b13e49eda9a1a87
Reviewed-on: http://gerrit.openafs.org/6994
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
When a cm_scache_t object is created in 98% of the time, the
parent FID is known to the cache manager. Normally the cache
manager will obtain the parent info from the AFSFetchStatus
structure but if the user credentials do not permit status info
to be obtained from the file server the parent info will be unavailable.
Having the parent directory FID is useful for debugging but can
also be used to check the user's access rights on the parent directory.
Change-Id: I262345bc686392a4edef4c627182a8a67a392aa2
Reviewed-on: http://gerrit.openafs.org/6993
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The AFSDisk and AFSFetchVolumeStatus structures use signed
32-bit integers for representation partition size and
available blocks. RoundInt64ToInt31() should be used instead
of RoundInt64ToInt32() when assigning their values.
Change-Id: I3834141fce2d54ce8bdfac3dc566074583bb305e
Reviewed-on: http://gerrit.openafs.org/7022
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
If the clock is set backwards, call timeouts will not trigger
until the clock regains its original value plus the timeout period.
In rxi_CheckCall(), look for a backward clock shift and if one is
noticed, fail the call with RX_CALL_TIMEOUT.
Change-Id: I7ca5abee165fc21d72d3881670f9522d315b4982
Reviewed-on: http://gerrit.openafs.org/6943
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
When a host has requested universal errors, error code conversion
is performed in the CallPostamble. However, the InlineBulkStatus
errorcodes are passed as part of the data set, not as RX errors,
so this translation is not performed.
Fix this so that we also translate error codes that are part of
the InlineBulkStatus response.
Change-Id: Ia23232d948990bdf9b7c4e5e0bcd8be087289a03
Reviewed-on: http://gerrit.openafs.org/6992
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Trend Micro's anti-virus driver attempts to open the file in
response to CcPurgeCacheSection(). While processing
AFSSetDispositionInfo() the Fcb->NPFcb->Resource is held which is
also required if a status verification is required during the
CreateFile operation. That results in a deadlock.
Avoid the deadlock by setting the PENDING_DELETE flag prior to
calling CcPurgeCacheSection().
Change-Id: I40d93d70e120525343afb917d473ad79a1f36e29
Reviewed-on: http://gerrit.openafs.org/6988
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
ulFilter was assigned appropriate values but it was not passed
to AFSFsRtlNotifyFullReportChange as a parameter.
Change-Id: Ie362b2b762e599a7cb040640539a098fdf80a259
Reviewed-on: http://gerrit.openafs.org/6987
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
If there is an undercount of the ObjectReferenceCount, consider it
the same as if the object count is zero for comparison purposes.
Change-Id: Ia4ec2d1194f00cb530e7a50ed9db9c71cc4c5313
Reviewed-on: http://gerrit.openafs.org/6970
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
AFSInvalidateObject() must not be called with an AFSObjectInformationCB
pointer variable that it is not safe to overwrite as the function sets
the input value to NULL if the invalidation is going to be performed
asynchronously in a worker thread.
In AFSEnumerateDirectory(), the following call took place:
AFSInvalidateObject( &pDirNode->ObjectInformation,
AFS_INVALIDATE_DATA_VERSION);
which requires a worker thread to process. As a result, the
ObjectInformation pointer was being set to NULL which detached the
AFSObjectInformationCB from the AFSDirectoryCB. That in turn produced
an execption in AFSLocateName() which resulted in a resource not being
freed that in turn produced a deadlock.
Change-Id: Id30e84cf96b69156d648e3b452e7e03390559c43
Reviewed-on: http://gerrit.openafs.org/6962
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The ObjectInformationCB.ObjectReferenceCount is protected by
the VolumeCB->ObjectInfoTree.TreeLock. When the TreeLock is
dropped the reference count can change. Hold the TreeLock across
both ObjectReferenceCount == 0 tests and the associated tear down
or repeat the ObjectReferenceCount == 0 test after the TreeLock
is reacquired.
Change-Id: I069c22ae8f3a93fad3ef9a662df5b4903b317897
Reviewed-on: http://gerrit.openafs.org/6959
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
PsSetCreateProcessNotifyRoutineEx will fail with STATUS_ACCESS_DENIED
if the driver does not have the IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
bit set in the image header.
Do not include the ParentProcessId in the AFSProceSSDestroy
parameter list. It isn't available to use and isn't used for
anything in any case.
Assign AFSProcessCB blocks to processes that were created before
AFSRedirector registered the CreateProcessNotify callback and
access the file system.
Change-Id: I4b78cd94949cfdea6b36f601a851c0e2f53a7dbf
Reviewed-on: http://gerrit.openafs.org/6967
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
even if we get more than one match, and even if there's a space,
work anyway
Change-Id: I8e71af0cb02fda7ea0fcf1c2f7a0404eca4bc073
Reviewed-on: http://gerrit.openafs.org/6971
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
in xcode 4.3, packagemaker is unbundled. make no assumptions
about where it can be found; instead, let spotlight tell us
Change-Id: I5e3431ce40ad6e9114e98c9bf047a4312d42284d
Reviewed-on: http://gerrit.openafs.org/6966
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
maxGoodSize is only used in one block, so move the decl to that block.
Adjust some of the comments to more accurately reflect what's going
on.
Change-Id: Ifee3a6f98158a314cef6d241c53a0f881f4f2d2b
Reviewed-on: http://gerrit.openafs.org/6936
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently, when we go to the fileserver to fetch some data, we try to
make sure that we do not ask for data beyond the end of the file. For
example, if our chunk size is 1M, and we need to get the first chunk
for a file that is 4 bytes long, we will only ask the fileserver for 4
bytes.
This can cause issues when the file is being extended at the same time
as when we are trying to read the file. Consider the following
example. There is a file named X that has contents "abcd" at dv 1, and
we issue a FetchData64 request for X, only requesting 4 bytes. Right
before the fileserver gets the FetchData64 request, another client
writes the contents "12345" to file X.
The client will then fetch the contents "1234" for that file, at dv 2,
and store that as the contents of the first chunk for file X. On
subsequent reads for file X, applications will now get "1234<NUL>" as
the contents, since the size of the file will be updated to 5, but the
cache manager thinks that "1234" is the correct contents for the first
chunk of X at dv 2. The cache manager will continue to think so until
the cache entry is evicted or invalidated for whatever reason.
To avoid this scenario, always request a full chunk of data if we have
any data to fetch and the file has not been locally truncated. We can
still avoid the fetch at all if it looks like we're fetching beyond
end-of-file, since we know that at least at some point that was
correct information about the file. If this results in us trying to
fetch beyond end-of-file, the fileserver will respond with the correct
length anyway.
We still need to restrict the fetch request length based on
avc->f.truncPos, since the dcache data after avc->f.truncPos needs to
stay empty, since we don't track truncated data any other way. If we
also avoided this restriction, extending a file via truncation after
reducing a file's length via truncation could cause the old file data
to appear again, instead of filling the new file range with NULs.
Note that on at least Linux, with this fix an application can still
read the contents "1234" on the first read in the above example, and
"12345" on subsequent reads. This is just due to when we give the VFS
updates about file metadata, and could be remedied by updating file
metadata immediately from the FetchStatus information from the
FetchData64 call. However, just reading the contents "1234" in the
above example seems like a somewhat plausible outcome; at the very
least, it is an improvement.
Change-Id: I158593502ac96ba2c856a0b5997355a53d4173aa
Reviewed-on: http://gerrit.openafs.org/6882
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When we truncate a file, we truncate the contents of the relevant
dcache entry chunks, and prevent future FetchData operations from
fetching data beyond the truncation offset. If we never write anything
to that chunk, we never set DWriting, and so on disk it looks like
that dcache entry has valid data for the specified DV. However, since
the data is truncated, this is not true.
If a process holds a file open, truncates it without writing to it,
and then the client crashes (or we have trouble contacting the
fileserver when we close the file), the dcache entry will appear valid
on disk. So the next time we read the dcache entry, we will use the
incorrect cache contents as if they were accurate for the specified
DV.
To avoid this, set DWriting when we truncate a chunk. Normally we only
clear DWriting when we actually send data to the fileserver, so to
clear DWriting in this case, add an additional line to clear it in
afs_StoreAllSegments, after the StoreMini has completed.
Change-Id: Ifc3bfc21712ab37b1f2865ce59fa45bf03811dd8
Reviewed-on: http://gerrit.openafs.org/6937
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
If we get an invalid AFSFetchStatus structure from a server, log a
message to indicate as such. This serves as a warning to urge people
to fix their fileservers, and to explain what is doing.
Change-Id: I33845f6228f96f693dcbfddcee38dae583f1b092
Reviewed-on: http://gerrit.openafs.org/6881
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
We currently do not do any sanity checking on the AFSFetchStatus
structures returned from fileservers. Add some sanity checking for
BulkStatus and FetchStatus calls, so we do not screw up our cache if a
fileserver gives us bogus data.
If we do get an invalid AFSFetchStatus structure, act as if the server
gave us a VBUSY error code, so we will retry the request. For OpenAFS
fileservers prior to 1.6.1 that yield this situation, VBUSY is likely
the error code the fileserver should have responded anyway.
Change-Id: Ie16a5210149b21dd5945380f5d7b6a4d9ee01a72
Reviewed-on: http://gerrit.openafs.org/6880
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Also, fix afsxbsa.h to always include <time.h> since this should get
struct tm on any fairly modern operating system.
Change-Id: Idfb39f12d28a2a0aa470c8549e4149d0b2ccde9e
Change-Id: Ia1c563e5954c533f18bd56155f2ae1825813efe3
Reviewed-on: http://gerrit.openafs.org/6923
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
InlineBulkStatus currently returns 0 unconditionally, no matter what
errors are encountered. If we encounter an error early enough, from
CallPreamble for example, we do not fill in the OutStats nor CallBacks
structures at all. Since we return success anyway, this results in the
client getting AFSFetchStatus structures full of zeroes (or garbage,
before commit 726e1e13ff).
Since current OpenAFS clients do not perform any sanity checks on the
information received, this can result in cache corruption of files
being seen incorrectly as empty, and, before commit 726e1e, more
arbitrary corruption.
So instead, return an error if we encounter an error before we iterate
over the given FIDs. We still of course do not return an error for any
errors encountered during the actual metadata retrieval, as those are
reflected in the individual per-fid status structures.
Change-Id: Icfab4516e510be5f0063ddf9c69f11ab3d511b35
Reviewed-on: http://gerrit.openafs.org/6871
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
As the process is being created, assign the AuthGroup so that
the must up to date information is used to assign AuthGroup
inheritance from Impersonation states and to prevent the parent
process from being destroyed before the AuthGroup is determined.
Change-Id: I176360a589d7f2bcf4b1ededad069424e3ce5393
Reviewed-on: http://gerrit.openafs.org/6927
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Breakup AFSProcessNotify() into AFSProcessCreate() and
AFSProcessDestroy().
Correct inconsistencies with ETHREAD vs ThreadId HANDLE.
Add AFSProcessNotifyEx() and use PsSetCreateProcessNotifyRoutineEx()
to register it on Vista SP1 and above.
Change-Id: I2be85c3e8229883b4e239e1fdba9a65fc704daaa
Reviewed-on: http://gerrit.openafs.org/6926
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Do not install afs/softsig.h on Windows from src/util
Do not include it in src/viced/viced.c
Change-Id: I8b6dcb1508dcda7da297a0c9a6bfeaf037c40c88
Reviewed-on: http://gerrit.openafs.org/6950
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Add various connection accessor functions to the export map file for
libafsrpc so they can be used from within RX security layers.
Change-Id: I0b5c75d987aadd6942dcb87fb1b98586bcc9e553
Reviewed-on: http://gerrit.openafs.org/6948
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Since this library could be use anywhere (including a shared library)
it should be built as position independent code.
Change-Id: I9e9c8b5c08e73ce43c04341b1106126f7774c405
Reviewed-on: http://gerrit.openafs.org/6925
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
VNOSERVICE should not be grouped together with the volume status
error codes. It is used to indicate that the RPC was not serviced.
The file server issues it when its idle dead timeout period is reached
while receiving rx call data. The client's existing status information
is still valid and the client can retry the call.
Change-Id: I51e447824366381e740361576c96559f1c4f3fd3
Reviewed-on: http://gerrit.openafs.org/6938
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Add additional logging to handle the case where the afsd_service
returns STATUS_NOT_A_DIRECTORY for eval by id/name.
Change-Id: Ib510fcea6102a92e5e810af5923f06dffbba1ed9
Reviewed-on: http://gerrit.openafs.org/6930
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
If d_make_root is available, use it instead of d_alloc_root.
The helper was introduced in 3.3, and d_alloc_root gets removed
in 3.4.
Change-Id: I39aaa6fd14d04c05ad9cb5b610e7f12f70fe0c94
Reviewed-on: http://gerrit.openafs.org/6931
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
AFS's own ntpd and runntp are obsolete. Remove them from the
documentation, and recommend the OS vendor-supplied NTP instead.
Change-Id: If0cd837aa407eb49049881790e618ccd75ca6e5b
Reviewed-on: http://gerrit.openafs.org/6903
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
