Currently, SalvageVolumeHeaderFile will set isp->volSummary->fileName
to a new string whenever the volume header needs to be created or
re-written. When control reaches back to SalvageFileSys1, this can
cause DeleteExtraVolumeHeaderFile to delete the header, since
vsp->fileName is used as a sort of indicator to see whether or not a
volume has been referenced by the inode summary.
When we create a new header, we avoid this because we allocate a new
VolumeSummary struct, which is not caught by the last
DeleteExtraVolumeHeaderFile for loop in SalvageFileSys1. However, we
do delete the header when we simply re-write a header, since we use
the existing VolumeSummary struct. Set fileName in neither, for
consistency.
Change-Id: Ibb7b5fbadb701028a6bafe01ae9f8d3265e2f443
Reviewed-on: http://gerrit.openafs.org/6783
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs_notify_change currently just returns "-code". This can cause a
panic if the error code is negative, since we will return a positive
error code, which may get interpreted as a valid pointer value in
higher levels.
Specifically, if we hit afs_notify_change via something like this code
path:
do_sys_open -> do_filp_open -> open_namei -> may_open -> do_truncate
-> notify_change -> afs_notify_change (via inode->i_op->setattr)
the positive error value will be interpreted by do_sys_open as a valid
'struct file' pointer, and will be dereferenced.
So pass the return value through afs_convert_code, like all of the
other vnode ops, so we ensure we return an error properly.
Change-Id: I941cc2d77d5a96cf86dfe133d30af4ccf6e9f2cb
Reviewed-on: http://gerrit.openafs.org/6776
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs_notify_change is almost always used solely in inode_operations
structs, and is more similar to the other per-vnode functions. Put it
with the other per-vnode functions for better organization, and so
they can use the same static functions.
Move the helper functions iattr2vattr and vattr2inode along with it.
Change-Id: I47a69fe673cfc3318ce583596ba25cbeb9cb0b96
Reviewed-on: http://gerrit.openafs.org/6775
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
if we get e.g. an idle dead error we should retry
retriable actions, namely data stores. in order
for writing files to work correctly given how
the writeback code is structured it's important that
this not interfere with analyze's shouldRetry decision
on those RPCs
Change-Id: Ie091a72b924c8414ec66c377fa13da14575a69cf
Reviewed-on: http://gerrit.openafs.org/6749
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
notify the redirector that the directory data version has
changed when a pioctl is used to create a symlink or mount point.
FIXES 130589
Change-Id: I07e1ae130b9db8d3dd68fef892c47de008be7cd4
Reviewed-on: http://gerrit.openafs.org/6747
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The AFSPerformObjectInvalidate() was obtaining exclusive
access to the Fcb ExtentsResource even though it was not
tearing down the extents list. The ExtentsResource could
be held shared instead. Doing so will avoid the following
deadlock:
Thread 1:
nt!MmPurgeSection+0x403
nt!CcPurgeCacheSection+0x100
AFSRedirLib!AFSPerformObjectInvalidate+0xd4
AFSRedirLib!AFSWorkerThread+0xa4
nt!PspSystemThreadStartup+0x2e
Thread 2:
AFSRedirLib!AFSAcquireShared+0x18
AFSRedirLib!AFSMarkDirty+0x68
AFSRedirLib!AFSNonCachedWrite+0x603
AFSRedirLib!AFSCommonWrite+0x5fa
AFSRedirLib!AFSWrite+0x20
nt!IofCallDriver+0x45
AFSRedir!AFSWrite+0x57
nt!IofCallDriver+0x45
fltMgr!FltpDispatch+0x6f
nt!IofCallDriver+0x45
AMFilter+0x2c6e
nt!IofCallDriver+0x45
PMDriver+0x112a
nt!IofCallDriver+0x45
OpLoader+0x1cd2
nt!IofCallDriver+0x45
savonaccesscontrol+0x6f15
savonaccessfilter+0x2fa0
nt!IofCallDriver+0x45
nt!IoAsynchronousPageWrite+0xd0
nt!MiMappedPageWriter+0x127
nt!PspSystemThreadStartup+0x2e
Thread 1 is attempting to perform a cache purge which cannot complete
until Thread 2 is finished but Thread 2 requires the ExtentsResource
which is held by Thread 1.
Change-Id: I4582093cf973f61cf6aff0df5e23b6711ec708b3
Reviewed-on: http://gerrit.openafs.org/6744
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Prior to 1.6.2 the file server does not report an accurate value
for the lock state. In addition, callbacks are not broken when
locks are freed due to lease expiration.
Change-Id: I5b79d1d59c2ace9834cf23dfbef33e343ce6dda0
Reviewed-on: http://gerrit.openafs.org/6741
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
locks are issued on a lease. If the lock is expired, the lock
count is zero.
Change-Id: I628dd5b8b0d38694d653d9e8e82ff60ec2e1505c
Reviewed-on: http://gerrit.openafs.org/6740
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
tid is now unused - remove it to avoid a warning.
Change-Id: If2d4fdf16415bbf19de3cd8a3e621d04d4d9b018
Reviewed-on: http://gerrit.openafs.org/6743
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently, h_TossStuff_r bails out and logs a message if we detect
that somebody grabbed a reference or locked the host while we tried to
h_NBLock_r. The reasoning for this is that it is not legal for anyone
to h_Hold_r a host that has HOSTDELETED set (but the error is
detectable and recoverable); callers are supposed to check for
HOSTDELETED and not hold a host in that case.
However, HOSTDELETED may not be set when h_TossStuff_r is called,
since we call it if either HOSTDELETED _or_ CLIENTDELETED are set. If
CLIENTDELETED is set and HOSTDELETED is not, it's perfectly fine (and
necessary) for callers to grab a reference to the host. So, if that's
what is going on, don't log a message, since that's normal behavior.
Check for HOSTDELETED before we h_NBLock_r, since it is technically
possible (and legal) for someone to grab a reference to the host and
somehow set HOSTDELETED while we wait for h_NBLock_r to return. Also
log the flags when we see this message.
Change-Id: Ie50a0617de094bb1c721da28f100ed4b31aa849f
Reviewed-on: http://gerrit.openafs.org/6733
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
We added this address to the host with an addInterfaceAddr_r call just
a few lines before, which adds the host to the address hash table.
Another call to h_AddHostToAddrHashTable_r is pure overhead and
confusing.
Change-Id: Ib08817274e632f67776956ede8b56eaf0dce879e
Reviewed-on: http://gerrit.openafs.org/6729
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, in h_GetHost_r, if we get a connection whose address does
not match an extant host, but the reported uuid does, we ProbeUuid the
old host. If it fails, we call MultiProbeAlternateAddress_r and set
'probefail'. Later on, if 'probefail' is set, we always add the
connection address to the host, and remove the host->host,host->port
address from the host.
However, this is not always correct. Consider the following situation.
We have an existing host that has primary address 1.1.1.1, and also
has addresses 1.1.1.2 and 1.1.1.3 on the interface list but not on the
hash table. Say that host A stops responding on 1.1.1.1, and a
connection comes in from 1.1.1.2. We ProbeUuid 1.1.1.1 and get a
failure, so we call MultiProbeAlternateAddress_r.
MultiProbeAlternateAddress_r probes via rx_Multi the addresses 1.1.1.2
and 1.1.1.3. Say that 1.1.1.3 responds first, and responds
successfully, so MultiProbeAlternateAddress_r sets 1.1.1.3 to be the
primary address for the host.
After MultiProbeAlternateAddress_r returns, 'probefail' is set. A few
lines down, we see that oldHost->host does not match haddr, and
'probefail' is set, so we add 1.1.1.2 to the interface list, and
remove 1.1.1.3, and set 1.1.1.2 to be the primary address, even though
1.1.1.3 is the address we most recently 'know' is correct.
To fix this, only set 'probefail' if MultiProbeAlternateAddress_r also
fails after the failed ProbeUuid call. Conceptually this makes sense,
since if MultiProbeAlternateAddress_r succeeds, it found an address
that responds successfully to ProbeUuid, and it sets that address to
be the primary address. Therefore, after MultiProbeAlternateAddress_r
returns success, the situation is the same as if the 'good' address
was already the primary address, and the ProbeUuid call succeeded, so
'probefail' should be cleared.
Change-Id: Id32817916a8a42db567ad099aae00745b79598c5
Reviewed-on: http://gerrit.openafs.org/6728
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The functions MultiBreakCallBackAlternateAddress_r and
MultiProbeAlternateAddress_r try to find a valid address in a host's
interface list of addrs. If they find one, they update host->host and
host->port. However, they do so just by changing those fields directly
and by calling h_DeleteHostFromAddrHashTable_r and
h_AddHostToAddrHashTable_r. This leaves the old host->host, host->port
on the interface list, and leaves it marked as 'valid'. Similarly, the
new host and port may still be marked as not 'valid'.
This can result in the host being on the addr hash table via an
address that is not on the host's interface list. After the above
situation occurs, we may call
removeInterfaceAddr_r(host, host->host, host->port);
and then update host->host and host->port, which happens in a variety
of places. Since host->host, host->port is not marked as valid in the
interface list, it is not removed from the addr hash table, but it is
removed from the interface list. Eventually, this can cause the host
to be referenced from the addr hash table even after it has been
freed.
Since this can result in hash table entries pointing to the 'wrong'
host, this can result in FileLog messages such as:
Sun Feb 5 03:16:35 2012 Removing address that does not belong to host 0xdeadbeefdead (1.2.3.4:7001).
And bogus instances of the message:
Sun Feb 5 03:16:36 2012 CB: new identity for host 0xdeadbeefdead (1.2.3.4:7001), deleting(1 baadcafe 12345678-9abc-def0-12-34-456789abcdef fedcba98-76543210f-ed-cb-a9876543210f)
To fix this, make MultiBreakCallBackAlternateAddress_r and
MultiProbeAlternateAddress_r update the address list the same way as
all of the code in host.c does; by adding the new address with
addInterfaceAddr_r, removing it with removeInterfaceAddr_r, and
updating host->host and host->port.
Change-Id: I0a95e0186c03c1831c4df86daae901bf2462da0e
Reviewed-on: http://gerrit.openafs.org/6727
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, when the fileserver gets a new connection from an address
not on the addr hash table, we allocate a new host structure and add
that host to the addr hash table. If we then find that that host's
uuid matches the uuid of an extant host, we do the following:
- probe the old host with the uuid, and MultiProbeAlternateAddress_r
if the probe fails
- mark the duplicate host as HOSTDELETED
- manipulate the interface lists
Consider, for example, that we have an extant host ('oldHost') with
address 1.2.3.4:7001, but with 5.6.7.8:7001 on its alternate interface
list. At some point, the 1.2.3.4:7001 interface goes away or becomes
unreachable. A new connection comes in from that same host on
5.6.7.8:7001.
What will happen is we create a new host for address 5.6.7.8:7001, and
then detect the uuid collision. When we try to probe the old address
of 1.2.3.4:7001, it will fail, and we will try to
MultiProbeAlternateAddress_r. MultiProbeAlternateAddress_r will
determine that the alternate address 5.6.7.8:7001 responds
successfully to the probe, and it tries to set 5.6.7.8:7001 to be the
primary address of 'oldHost', and add 'oldHost' to the addr hash table
under 5.6.7.8:7001.
But the "new" host from the incoming connection is already hashed on
the address hash table under 5.6.7.8:7001, so the
h_AddHostToAddrHashTable_r call in MultiProbeAlternateAddress_r fails.
Since we later delete the new duplicate host, this results in
5.6.7.8:7001 being the primary address for the host, but that address
is not anywhere in the address hash table.
This behavior can be seen by the following pair of FileLog messages:
Wed Feb 1 11:02:38 2012 CB: ProbeUuid for 0xdeadbeefdead (1.2.3.4:7001) failed -01
Wed Feb 1 11:02:38 2012 h_AddHostToAddrHashTable_r: refusing to hash host beefdead, baadcafe (5.6.7.8:7001) already hashed
While those message do not necessarily indicate this problem, this
problem will result in those messages.
To fix this, mark the duplicate host as HOSTDELETED before we do any
probing on 'oldHost'. This way, if MultiProbeAlternateAddress_r tries
to add 'oldHost' to the addr hash table under 5.6.7.8:7001, it will be
able to do so successfully, since the old duplicate host is deleted.
Change-Id: Id3aaab0718425492dca1deba892725160677b85f
Reviewed-on: http://gerrit.openafs.org/6726
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
If an rx call has the RX_CALL_PEER_BUSY flag set, but the call's
conn->lastBusy is not set, we can easily cause an rx caller to loop
infinitely. rx_NewCall will see that lastBusy for a call channel is
not set, and will use that call channel, but rxi_CheckBusy will note
that the call appears busy and that there are non-busy call channels
on the same conn, and so will return RX_CALL_BUSY.
This can currently happen in rxi_ResetCall, since we set
RX_CALL_PEER_BUSY on the call again if the call had that flag set when
rxi_ResetCall was called. If we are calling rxi_ResetCall with
'newcall' set, the passed in call is unrelated to the new call, since
it was obtained from the free list. Thus, the busy-ness of the call
should be ignored. Fix this by only paying attention to the incoming
RX_CALL_PEER_BUSY flag if 'newcall' is not set.
Also prevent this from happening by clearing RX_CALL_PEER_BUSY in
rx_NewCall when we select a call and clear lastBusy for that call.
Change-Id: Ic5a4709854b62d962ed91ee0103c6cbdd735d175
Reviewed-on: http://gerrit.openafs.org/6707
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
allow writing of data where it's not user data we're changing
(e.g. allow a vnode to be marked cloned in the vnode index)
Change-Id: If3338ab0474ddbfe895b705217d61c054c4cb696
Reviewed-on: http://gerrit.openafs.org/6251
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
effectively the same functionality that reclone already uses, but
for some reason we artificially limit it out of clone despite
the interface being there for it. it used to be there. put it back.
Change-Id: I22868c41f8d3b920ba61d01e5334ff2320b38376
Reviewed-on: http://gerrit.openafs.org/6250
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
remove EROFS error which is the only thing preventing a working clone
on a non-RW.
Change-Id: Ic3d4d07519188712e9a38267fc74ebd1eaef7d8a
Reviewed-on: http://gerrit.openafs.org/6249
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
If the machine has been upgraded from an AFS SMB Server to the
AFS Redirector, the registry will have leftover configuration
for the "AFS" netbios name in the Lsa BackConnectionHostNames
value and the LanmanWorkstation ReconnectableServers and
ServersWithExtendedSessTimeout values. These values are not
useful with the AFS Redirector since \\AFS is owned by afsredir.sys
and not the SMB redirector. Remove the "AFS" netbios name from
these values when afsd_service.exe has started in redirector mode.
Change-Id: If8c100d3569595645c041ac58fedb1c835f9129f
Reviewed-on: http://gerrit.openafs.org/6737
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
There were several different real and made-up hostnames and company names used
throughout our documentation examples.
The IETF has reserved "example.com" and other "example" TLDs for use in
examples (RFC 2606). Replace almost all references to ABC Corporation, DEF
Corporation, and State University, as well as "abc.com", "bigcell.com",
"def.com", "def.gov", "ghi.com", "ghi.gov", "jkl.com", "mit.edu",
"stanford.edu", "state.edu", "stateu.edu", "uncc.edu", and "xyz.com".
Standardize on "Example Corporation", "Example Network", "Example
Organization" (example.com, example.net, and example.org).
The Scout documentation in the Admin Guide contains PNG images that contain
the old cell names, so I left those references until the images can be
replaced.
Change-Id: I4e44815b2d2ffe204810b7fd850842248f67c367
Reviewed-on: http://gerrit.openafs.org/6697
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The Unix Mode bits were not being saved. This patch permits
them to be saved.
FIXES 130572
Change-Id: I6bf96c04115ee0f01e84b44b9efaacb578d95cbc
(cherry picked from commit 534d95ef90ac5e5ebf5deb227008e0b023e7ef8b)
Reviewed-on: http://gerrit.openafs.org/6734
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The DirectoryEnumEvent is not required to implement:
AFSSetEnumerationEvent
AFSClearEnumerationEvent
AFSIsEnumerationInProgress
The DirectoryEnumCount is modified by interlocked operations
and can be used as a marker for when an enumeration is in progress.
Change-Id: I414ce2bc753b0fd60a3fac51c2cf3d264a32ab05
Reviewed-on: http://gerrit.openafs.org/6725
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
AFSPrimaryVolumeWorkerThread held the VolumeCB->ObjectInfoTree.TreeLock
exclusively across calls to AFSCleanupFcb() which in turn triggers
a file extent release to the service which can in turn result in
an object invalidation. Processing the invalidation requires shared
access to VolumeCB->ObjectInfoTree.TreeLock which results in a deadlock.
This patch alters the processing of AFSPrimaryVolumeWorkerThread
so that the VolumeCB->ObjectInfoTree.TreeLock is not held across
the AFSCleanupFcb() calls.
FIXES 130431
Change-Id: I3726df02ab47d2dcc83a32c75957a5dafcfbf20e
Reviewed-on: http://gerrit.openafs.org/6724
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>
The daemon thread's loading and unloading of afsdhook.dll every
second prevents the disk drive from sleeping and forces a search
of the PATH. Make the periodic reloading configurable and
disable it by default.
Change-Id: I7e1a5b2bc7e1c4d4ea39fc30cf34c1195a326ed2
Reviewed-on: http://gerrit.openafs.org/6715
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
If acquisition of the Global\AFS_KTC_Mutex fails, return a
different error code from a pioctl failure since the pioctl
was never issued.
Change-Id: I001227f87e97a06bf419c68d6579843e4f93f032
Reviewed-on: http://gerrit.openafs.org/6710
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Cache the value of GetComputerNameW() to avoid repeated calls
for each and every redirector ioctl request.
Change-Id: I4476db982897a631510eba7d859385268b16ce34
Reviewed-on: http://gerrit.openafs.org/6708
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Currently, the openafs-client RPM init script ignores any error
reported by rmmod. If 'umount /afs' succeeds but rmmod does not, the
client may panic the machine if the client is started again (from e.g.
running the 'restart' init script method), since afsd will try to
initialize AFS with a libafs that has been shut down.
So, do not ignore errors from 'rmmod', and instead fail the 'stop'
method from the init script if we get an error.
Change-Id: Id4a07703fb4df69ad3a6a3569c91e48f73a0d309
Reviewed-on: http://gerrit.openafs.org/6709
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Change the default cell from openafs.org to grand.central.org
since there is no openafs.org cell. All openafs software is
distributed from the grand.central.org cell.
Change-Id: I21ea2c5a9b55fbe3bb4ea19ae34ecf0e5a38084f
Reviewed-on: http://gerrit.openafs.org/6699
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Master does not track a particular version number.
For Windows builds on master, reset the version to
0.0.0 so that the builds are not confused with the actual
1.5.7600.
Change-Id: I3c84bb117418284de0d65e2a4069b88908b91659
Reviewed-on: http://gerrit.openafs.org/6698
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Modify AFSRemoveFcb to use InterlockedComparePointerExchange
to ensure that only one thread can remove and deallocate an
AFSFcb structure.
Change-Id: I27d27b6a99806bee2fc2cfc04c2ac04d975a553d
Reviewed-on: http://gerrit.openafs.org/6696
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Provide examples of the direct volume access syntax, using the
fictitious example.com cell.
Change-Id: Ia2ea592531e29f6b744d0bd6993d598d78a799c4
Reviewed-on: http://gerrit.openafs.org/6691
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
In AFSSetRenameInfo(), the rename to itself check was performed
after the name collision check. Move the check earlier in the
routine to ensure that we catch the no-op before any real work
is done.
Change-Id: I580dd9958a259d4a1819c6bd882dae8067d2853d
Reviewed-on: http://gerrit.openafs.org/6692
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Currently in h_Alloc_r, we h_Lock_r the host, so we have it locked on
return. However, h_Lock_r drops the host glock, which is bad in this
situation since we have already added the host to the global hash
table, so other threads may see it. This can mean that by the time
h_Alloc_r returns, the returned host may have HOSTDELETED set, and/or
the addresses associated with the host may be completely different.
h_Alloc_r's caller, h_GetHost_r, seems to assume that the host is
still associated with the address of the passed-in connection. When
this is not true, this can result in the host structure getting into a
strange state, such as the primary addr/port may not be hashed. The
host may also have HOSTDELETED set, in which case we're not supposed
to be dealing with it at all.
To avoid these problems, lock host->lock directly in h_Alloc_r,
without going through h_Lock_r and dropping H_LOCK. Also do it as one
of the first things we do to initialize the host, just to make sure
that if anybody else happens to see the host, it is locked by us when
they do.
Change-Id: Ia99cb84ad94f3e143ed0bae33485a88d60ff5b27
Reviewed-on: http://gerrit.openafs.org/6389
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
For replication writes at the remote site, we will want to call
this without a host structure.
Change-Id: I9cdef18f35229c9ab162cc07f6d60fe443204654
Reviewed-on: http://gerrit.openafs.org/6674
Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Add missing BlockSize registry value
Correct AFSRedirector\NetworkProvider registry key description
Add note that LanAdapter value is ignored if SMB mode is not in use.
Change-Id: I449988f1f6841c1b254d73b08a6ee53ca2dbaeda
Reviewed-on: http://gerrit.openafs.org/6685
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
OpenAFS reparse points represent mount points, symlinks, and dfs
referrals. All of which are file system objects that represent
another named entity in the system. As a result the reparse tag
field must include the Reparse Tag Surrogate bit (0x20000000) set.
This permits the IsReparseTagNameSurrogate() macro provided in
winnt.h to be used to determine if the reparse point is a surrogate
or not.
See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365197%28v=vs.85%29.aspx
Change-Id: I2561823e23371c2fdf01941da99fe848ca1fa11d
Reviewed-on: http://gerrit.openafs.org/6668
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Add some basic definitions that will be needed to handle RW
replicas.
A new volume type RWREPL is added. Replicas will share the same
volume ID as the RW volume, so the array of volume IDs by volume
type is unchanged, as is the VLDB entry format.
A new flag bit ITSRWREPL/VLSF_RWREPLICA for serverFlags identifies
RW replica sites in VLDB entries.
Change-Id: I882b238f34e682ebea782e11dc418ae1340d4546
Reviewed-on: http://gerrit.openafs.org/6676
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
OPENAFS_VOL_STATS has been unconditionally defined since the IBM days.
Adjust the code to assume it is set.
Change-Id: I3b5ff99a469e6865ff1e10405a7f77d8c3890f59
Reviewed-on: http://gerrit.openafs.org/5551
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
With newer Solaris Studio (sometime in the 12.* series), cc started
adding SSE instructions to optimized x86 code, which is invalid for
kernel code and can generate panics. There appears to be no way to
turn this off currently (-xvector=%none is non-functional), so default
to not optimizing kernel code.
Change-Id: I5fdedb11219df68e0146b8e0cee9010c2eb4067e
Reviewed-on: http://gerrit.openafs.org/6671
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
We no longer include rx_packet.h from rx.h, so rx_kcommon.h was not
picking up some packet-related definitions. Some files
(SOLARIS/rx_knet.c, IRIX/rx_knet.c) were using packet-related defines
(e.g. RX_HEADER_SIZE) while just including rx_kcommon.h. Include
rx_packet.h in those files to get the relevant definitions.
Change-Id: Ib012f295d8e324dd8b38eb0b89933eac392a9583
Reviewed-on: http://gerrit.openafs.org/6670
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
