Make the reloading of rxkad.keytab keys occur in the same way that
KeyFile keys are reloaded. That is, we only try to reload them if the
CellServDB mtime has changed. This is intended to have exactly the
same reloading behavior as KeyFile reloads.
I would have triggered this from afsconf_Check, but that approach
has annoyances. (Calling ticket5_keytab functions directly from
cellconfig pulls in libkrb5 dependencies for everything that uses
cellconfig, and we'd have to trigger an afsconf_Check call by calling
some other cellconfig function.)
These code paths involve processing untrusted user data. Just never
assert here, to be on the safe side.
Merge into "New optional rxkad functionality for decypting krb5
tokens"
We don't return anything, and pthread_once expects a function
returning void. So make it actually void, to avoid warnings.
Merge into "New optional rxkad functionality for decypting krb5
tokens"
No, we shouldn't assert, and those error codes should be okay (haven't
heard any better ideas). Get rid of these comments, so there's no
confusion.
Merge into "Clean up akimpersonate and use for server-to-server".
1.6 has common code for this, but not 1.4....
Keep the calls conditional on the presence of a krb5 library.
Change-Id: I5a1bcd515cb56a410f94de0a0f3614a8c8312b19
Since a6d7cacfd, aklog has been able to print a krb5 ticket to
itself for an arbitrary client principal, allowing a user with
access to the cell's krb5 key to get tokens as an arbitrary user.
Now that it is possible to use native krb5 tickets with non-DES
enctypes for authentication, and akimpersonate is available from libauth,
use printed native krb5 tickets for server-to-server communication (as well
as the -localauth versions of the client utilities).
Before doing so, refactor the akimpersonate code to be more usable
and readable, and eliminate some dead code. For example, we always printed
addressless tickets, so that code could be removed. Other code had excessive
stack usage for a library routine, which is eliminated. Use a start time
of 0 instead of 300 so that the printed ticket will always be
detected as infinite-lifetime.
In order to ensure usability on all platforms (in particular Solaris),
provide a couple more compat shims to implement routines which are not
always available from the krb5 library, in particular encode_krb5_ticket
and encode_krb5_enc_tkt_part. Thanks to Andrew Deason for implementing
these compatibility routines.
UKERNEL doesn't need this stuff.
akimpersonate: Handle missing encode_krb5_ticket
If we don't have encode_krb5_ticket and encode_krb5_enc_tkt_part,
implement our own. Basically, transform the appropriate structure into
the Heimdal equivalent, and use our builtin Heimdal ASN.1 encoding
functions to do the actual encoding for us.
Give it its own source file and header, install the header at
depinstall time, and have aklog get the akimpersonate functionality
from libauth.
Keep the linux box copyright from aklog_main.c (but strip the trailing
whitespace), as that block was added with the akimpersonate code.
Remove all calls to afs_com_err() as is fitting for library code,
to let it build. Do not bother removing curly braces which are
no longer needed; a future cleanup commit will catch that.
If a kerberos 5 ticket has a session key with a non-DES enctype,
use the NIST SP800-108 KDF in counter mode with HMAC_MD5 as the PRF to
construct a DES key to be used by rxkad.
To satisfy the requirements of the KDF, DES3 keys are first compressed into a
168 bit form by reversing the RFC3961 random-to-key algorithm
Change-Id: I4dc8e83a641f9892b31c109fb9025251de3dcb27
An additional, optional mechanism for decrypting krb5-format tokens
is provided that uses the krb5 api with a key from a keytab
instead of using libdes and the AFS KeyFile
The AIX compat stub for krb5_c_decrypt is contributed by Andrew Deason.
Change-Id: I97c08122c60482b84d602d6fa6482f1d5deef142
Allow tokens to be encrypted with algorithms other than DES.
The security object owner must provide an implementation
by calling rxkad_SetAltDecryptProc.
Make sure plainsiz is initialized before calling the alternate decrypt
proc.
Fix potential buffer overflows caused by misuse of the scanf function
in the fileserver and ptserver.
Also fix similar issues in the client side fs command and libadmin
library.
(cherry-picked from d1855f8e04)
Change-Id: Icc50158816c058a831267243d0e9fd443d01fa68
Implementing the d_automount or follow_link function pointers for our
directories means that we can hit symlink resolution limits during
lookup, since we look like a "symlink". We can hit these limits pretty
easily if there are just too many directories in the lookup path.
Our pseudo-symlink directories cannot contribute to an infinite
resolution loop, since our destination is always an actual directory,
not a symlink that will result in more redirection. So, decrement the
total_link_count counter when our d_automount or follow_link code is
reached, so we do not contribute to hitting the max resolution limit.
Note that this is not related to recursive symlink lookup (link_count)
but only to the iterative symlink limit (total_link_count). Our
lookups are not recursive here, and we are not causing more recursive
lookups like a normal text-based symlink would do.
Reviewed-on: http://gerrit.openafs.org/8009
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 238b88624a)
Change-Id: Ib14ee9d160189da658f36578e21bd458e6e7832a
Reviewed-on: http://gerrit.openafs.org/8195
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
On Linux, having a mountpoint in a volume root that points to the same
volume can cause serious problems. By 'immediately recursive', I mean
a situation like the following:
fs mkm mtpt vol
fs mkm mtpt/mtpt vol
If there are multiple dentry aliases for the directory (which is
possible if the directory is a mountpoint), an 'rmdir' on the
recursive mountpoint can cause the client to deadlock. Since the
'rmdir' code path in Linux locks the parent directory inode to perform
the rmdir, and locks the child directory inode after performing a
couple of sanity checks. For an immediately recursive mountpoint,
these two inodes are the same, and so we will deadlock.
Reviewed-on: http://gerrit.openafs.org/7742
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit d785abd5ec)
Change-Id: I7112a6b753a0a1b227c066a497a2e4729d40056f
Reviewed-on: http://gerrit.openafs.org/7954
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently, we try to invalidate other dentries that exist for a
particular dir inode when we look up a dentry. This is so we try to
avoid duplicate dentries for a directory, which Linux does not like
(you cannot have hardlinks to a dir).
If we cannot invalidate the other aliases (because they are being
used), right now we just return the alias. This can make it very easy
to panic the client, due to the sanity checks Linux performs when dong
things like 'rmdir'. If we do something like this:
mkdir dir1
fs mkm dir1/mtpt vol
mkdir dir1/mtpt/dir2
fs mkm dir1/mtpt/dir2/mtpt2 vol
cd dir1/mtpt
rmdir dir2/mtpt2
For the 'rmdir', we will lookup 'mtpt2'. Since 'mtpt' and 'mtpt2'
are mountpoints for the same volume, their dentries point to the same
directory inode. So when we lookup 'mtpt2', we will try to invalidate
the other dentry, but we cannot do that since it is the cwd. So we
return the alias dentry (for 'mtpt'). The Linux VFS layer then does a
sanity check for the rmdir operation, checking that the child dentry's
parent inode is the same as the inode we're performing the rmdir for.
Since the dentry we returned was for 'mtpt', whose parent is 'dir1',
and the actual dir we're performing the rmdir for is 'dir2', this
sanity check fails and we BUG.
To avoid this, make the dentry alias act like a symlink when we
encounter an uninvalidateable dentry alias. That is, we allow multiple
dentry aliases for a directory, however, when the dentry aliases are
actually used, we redirect to a common dentry (via d_automount where
possible, and follow_link elsewhere).
This means that such mountpoints will behave similarly to symlinks, in
that we 'point' to a specific mountpoint dentry. This means that if we
have multiple different ways to get to the same volume, and all are
accessed at the same time, all but one of those mountpoints will
behave like symlinks, pointing to the same mountpoint. So, the '..'
entries for each path will all point to the parent dir of one
mountpoint, meaning that the '..' entry will be "wrong", but for most
cases it will still be correct.
In order to try to make the 'target', pointed-to directory consistent,
we add a new field to struct vcache: target_link. This points to the
dentry we should redirect to, whenever that vcache is referenced. To
avoid (possibly not-feasibly-solvable) problems with refcounting, this
pointer is not actually a reference to the target dentry, but just
serves as a pointer to compare to.
FIXES 130273
Reviewed-on: http://gerrit.openafs.org/7741
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit de381aa0d3)
Change-Id: I42959ab0c09e5b752660cd87293c63ca7978d242
Reviewed-on: http://gerrit.openafs.org/7953
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
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.
(cherry picked from commit e8f6dfac59)
Reviewed-on: http://gerrit.openafs.org/7022
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
Change-Id: Ieb55d057b09648c88cf1f8596fd934139dde3910
Reviewed-on: http://gerrit.openafs.org/7024
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
The intention of this condition is to check if the current call
being considered is the last one on the queue, but the test is
incorrect. A null next pointer indicates a removed item, not
the end of the queue.
Use the queue_IsLast macro instead to correctly determine that
this is the last item in the queue and that a call has to be
selected, either the current one or a previously seen good choice.
This can cause calls to get permanently stuck in the call queue
and never get assigned to a thread, even when all threads are
idle.
Reviewed-on: http://gerrit.openafs.org/6564
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit 6ad3d646e6)
Reviewed-on: http://gerrit.openafs.org/6570
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit 339438c847)
Change-Id: I86e43066ab20dc64749be2c2ba0fffa511e7f9ff
Reviewed-on: http://gerrit.openafs.org/6623
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Russ Allbery <rra@stanford.edu>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Clear dirHeader->hashTable via memset instead of via a loop. This is
more efficient, and avoids the loop getting optimized into an unusable
_memset call on recent versions of Solaris Studio when building for
the kernel.
Thanks to Jeff Blaine for reporting the issue with Solaris Studio.
Reviewed-on: http://gerrit.openafs.org/4829
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit f091ace32e)
Change-Id: Ife4c55742b60f434574bafa32d1ae677dbcbfe66
Reviewed-on: http://gerrit.openafs.org/6415
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Normally when we AllocCBR, we are holding xvcache write-locked, since
it is called from FlushVCache. Before
a309e27463, when AllocCBR needs to flush
CBRs due to a lack of space, we hit the net, giving up callbacks on
fileservers.
This can cause a problem if one of those fileservers needs to contact
us in order to complete that request, since the callback service
thread may be waiting for xvcache, causing a deadlock (that is
eventually broken by network timeouts).
To avoid this, drop xvcache if AllocCBR looks like it does not have
sufficient space. Fix all callers of afs_FlushVCache to handle the
case where we sleep, since with this change, afs_FlushVCache can sleep
on all platforms.
This partially reverts a309e27463, as it
contains an alternative method of avoiding the xvcache lock in this
situation. This commit restores much of the code path to be much more
similar to how it used to be, except that it allows for dropping
xvcache for AllocCBR. This should make any change to our prior
behavior smaller/simpler, and thus safer and more consistent with
existing clients. This reintroduces the hard limit to how much space
we allocate for CBRs, although the part of
a309e27463 that raised this limit is
retained.
Reviewed-on: http://gerrit.openafs.org/3958
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 76158df491)
Change-Id: I0b41ff4f1d9f6d81010243720735e72c5686d572
Reviewed-on: http://gerrit.openafs.org/6593
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
The function afs1_readdir is not referenced anywhere. Remove it, as it
currently causes compilation errors (a typo with the
origOffset/orginOffset variable name).
This is a 1.6/1.4-only change. afs1_readdir was removed on master as a
part of commit 0284e65f97.
Reviewed-on: http://gerrit.openafs.org/5522
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit 1cf667e0df)
Change-Id: I951501775aa714c6ad866fc4a803c1863948c141
Reviewed-on: http://gerrit.openafs.org/5780
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
On Linux kernels that support keyrings, when we setpag we try to add
the PAG to the session keyring and to the supplemental group list.
Currently, if we fail to add the PAG to the keyring (which may happen
due to key quotas, or possibly other reasons), we return failure but
the group list is still modified with the new PAG in it.
Therefore, if the keyring-based approach fails, the new PAG may still
be in use, but there are no keyring keys associated with that PAG, so
the PAG may never get destroyed. This can cause a large number of PAGs
to accumulate over time, causing performance problems.
So, change this so that, in the event that keyring installation fails,
we revert the group list back to what it was before we touched it.
Also mark all unixusers with the new PAG as expired, in case one got
created during processing. Thus, the new PAG never gets used.
Reviewed-on: http://gerrit.openafs.org/5238
Tested-by: Derrick Brashear <shadow@dementix.org>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit ee2fbffb04)
Change-Id: I7a3dbf94f7f862e5e7d3ae4d54d3acacd48ed594
Reviewed-on: http://gerrit.openafs.org/5729
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Linux is a real stickler when it comes to error codes. Functions
which return positive error codes into the kernel tend to have
unfortunate effects. Because all AFS errors tend to be positive,
most of our kernel entry points negate errors before passing them
back to their caller.
This causes problems when internal functions themselves return
negative error codes. This was the case with the keyring functions,
which ended up returning a negative code to setpag(), this handed
that code ultimately up to the ioctl handler, which negated it (so
turning it positive) before throwing it up to the kernel.
The kernel sees this positive value as being a successful return,
and so passes it direct to userland, rather than assigning it to
errno. This led to the setpag() userspace function never being
aware of keyring errors that had occurred in the kernel.
Fix all this by making sure that all errors from the keyring code
are made positive before being passed upwards in the kernel module.
Reviewed-on: http://gerrit.openafs.org/4223
Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 3d92852ba9)
Change-Id: I197e963b9da6ba89a48998477ffda61b98903eb1
Reviewed-on: http://gerrit.openafs.org/5728
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
The dir package didn't protect against circular hash chains when
performing directory lookups. A corrupt directory could therefore
cause a client or a fileserver to go into an endless loop if that
directory contained a loop in its hash chain pointers.
Fix this by exiting the lookup if the hash chain has more elements
than the total number of entries in a directory. This maximum number
of entries is taken as being (number of entries per page) * (max
number of pages), which is considerably more than the real maximum
value.
Change-Id: I9e281571f3b01bd8de346ee5418df38b2f5edaa1
Reviewed-on: http://gerrit.openafs.org/5618
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Provide a new routine, GetVerifiedBlob() which will ensure that the
pathname contained within a directory blob is correctly terminated
before returning it to the caller. For the purposes of this function,
correct termination is defined as having a terminating \0 character
within the same directory page as the blob itself.
Change-Id: I4b3bbb95cb49645a8ac52e6061f9e24f89924831
Reviewed-on: http://gerrit.openafs.org/5617
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: Derrick Brashear <shadow@dementix.org>
When we call InlineBulkStatus or BulkStatus, we currently do not touch
tvcp->callback for any of the vcaches before making the call. This can
cause us to not notice an InitCallBackState issued by the fileserver
before the BulkStatus call returns, since the InitCallBackState
handler looks at tvcp->callback to determine what vcaches to clear
callbacks for. In turn, this can cause us to think we have a callback
agreement with the fileserver on one of the BulkStatus'd files, when
the fileserver does not actually have such a callback agreement.
So, set tvcp->callback to the server we are contacting, so if we get
an InitCallBackState call from that fileserver, the CBulkFetching
state will be cleared, and we will correctly discard the callback
information for that vcache.
Reviewed-on: http://gerrit.openafs.org/2548
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 37817796c4)
Change-Id: I3bb9bd6b8c9f7e5ef9f63a62d80cf70629990db6
Reviewed-on: http://gerrit.openafs.org/5647
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Revert the logic meant to prevent duplicate entries in the
host address hash table so hosts with multiple addresses can
be stored in the same hash bucket again.
Add a new log message to show when the host cannot be stored
in the hash table because of an address-port pair collision
with a host already in the hash table.
Reviewed-on: http://gerrit.openafs.org/1046
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 747a8c0642)
Change-Id: Ib8944657b14e80b091f0b209dcf7e809c5fc0574
Reviewed-on: http://gerrit.openafs.org/4882
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Do not use the local cell name when determining if a new entry name is
too long. This check assumes that foreign cells will use our local
cell name (assumed to be our local Kerberos realm) in a certain way,
and prevents creating users that will make those names too long.
This is undesirable for several reasons. One is that the local realm
name may not be the same as the local cell name (and we may have many
local realms). Another is that we cannot reliably predict how foreign
cells will construct foreign pt entry names, so preventing entry
creation based on that may prevent names that will never cause any
problems. This check also assumes that our names will be used as
foreign entries in other cells, which may not be the case.
So, remove the check based on the local cell name, and remove the
pr_realmNameLen variable while we are at it, since this is all it is
used for.
Thanks to Jeffrey Altman for discussion, and for bringing this up in
the first place.
Reviewed-on: http://gerrit.openafs.org/2488
Tested-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from 5e946d5b66)
Change-Id: I20cf2c2c2e31df0e765881e35fb04f22e934172a
Reviewed-on: http://gerrit.openafs.org/5325
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
In afs_DoBulkStat, we can call afs_Analyze multiple times for the same
set of connection objects. Since afs_Analyze puts its reference to the
given afs_conn and rx_connection structures, calling it more than once
can cause the reference counts on those objects to be lower than they
should be.
Instead of making another afs_Analyze call, just alter the error code
inside the normal do/while afs_Analyze loop, so the 'loop' afs_Analyze
call gets the appropriate error code from the first bulk stat'd entry.
Reviewed-on: http://gerrit.openafs.org/5086
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit ef28bc08c1)
Change-Id: Id367ea7e8d3735d1b88475ad771bd23e3d013df2
Reviewed-on: http://gerrit.openafs.org/5236
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Currently, a struct vcache has a multiPage counter, indicating how
many afs_getpage requests are in-flight for that vcache that involve
retrieving multiple pages. Any dcache associated with such vcaches are
then avoided when choosing dcache entries to evict from the cache,
since we may deadlock when trying to evict a dcache entry from one of
the earlier afs_GetOnePage calls in a particular afs_getpage request.
This behavior can cause the client to become unusable if the cache
becomes full, and the only items in the cache are dcache entries in a
file that has an in-flight multi-page afs_getpage request. Since, in
that case, we cannot kick out any entries from the cache, and so we
wait forever to wait for the cache utilization to go down.
To prevent this from occurring, record exactly which ranges in the
file have in-flight multi-page afs_getpage requests, and just avoid
dcache entries in those ranges. This way afs_GetDownD can evict dcache
entries in the same file, but still avoid entries that would cause a
deadlock.
Also add some comments explaining this situation a bit more.
Reviewed-on: http://gerrit.openafs.org/4896
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 31a001f60e)
Change-Id: I4fd91d07648616fa1c9dc9ee6e1f25e8c2f3b20b
Reviewed-on: http://gerrit.openafs.org/4928
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
The patch which moved our calls to fsync into the background, added
a sync prior to each batch of fsync calls. This is an incredibly bad
idea.
POSIX says that sync "shall cause all information in memory that
updates file systems to be scheduled for writing out to all file
systems". On Linux this means that we in effect perform an fsync()
on every open filehandle on the entire system, and in addition flush
all superblocks and journals out to disk. This makes the following
fsync() calls superfluous - sync() will have already written out
all of the data.
Add to this the fact that the fileserver is doing this every 10
seconds, and this becomes a major performance bottleneck,
particularly if the machine uses a journalled fs - as any disk
operations will end up blocking whilst the journal is written to
disk.
Reviewed-on: http://gerrit.openafs.org/1977
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Rainer Toebbicke <rtb@pclella.cern.ch>
Tested-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 5ea24a7c55)
Change-Id: Icdd0644d96d0c60ac02c7a6bb6c881bdaa15f939
Reviewed-on: http://gerrit.openafs.org/4394
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When a process requests an exclusive lock on a file on which it
already holds an exclusive lock, we basically form a no-op. However,
HandleFlock was allocating a new SimpleLocks and attaching it to
avc->slocks, without freeing the old SimpleLocks structure.
Since we don't need to do anything if we already hold an exclusive
lock, just break out of the loop right away when we detect that
scenario. Thus we avoid adding a new structure to avc->slocks, and we
avoid a memory leak.
Reviewed-on: http://gerrit.openafs.org/4395
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit ba9ae1ed7c)
Change-Id: I40af9d9aad3fa8651c0f16608bdb1bea2ec0f437
Reviewed-on: http://gerrit.openafs.org/4436
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
HandleFlock calls afs_StoreAllSegments when unlocking an exclusive
flock lock. This can drop the write lock on avc, so we must
effectively retry the entire lock operation again, since the world may
have changed while we were waiting to reacquire the lock on avc. So,
retry once all of the lock checks up to that point, to ensure that a
lock on the file actually still exists.
FIXES 125446
Reviewed-on: http://gerrit.openafs.org/4393
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 601fcf1d7f)
Change-Id: I8b12175bfd082f7fb75e7cfc1fb0e7662912e6e8
Reviewed-on: http://gerrit.openafs.org/4435
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Bozo needs to call rxInitHost() rather than rxInit() when -rxbind is
present. This patch causes it to read NetInfo/NetRestrict earlier in
the startup process so it can make that decision.
FIXES 57286
Reviewed-on: http://gerrit.openafs.org/4729
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 6260c4ae51)
Change-Id: Ie6880661d49670437429e61d31671778514827ce
Reviewed-on: http://gerrit.openafs.org/4813
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
When we get a reference to an afs_conn with afs_Conn and its variants,
we assume we can use the tc->id rx connection without holding any
locks. However, if tc->forceConnectFS gets set, the tc->id connection
can be destroyed and recreated out from under us. So, to avoid using a
possibly freed rx connection, grab a reference to the rx connection at
the same time as we grab a reference to the afs conn. And also put
back the same reference with afs_PutConn.
Reviewed-on: http://gerrit.openafs.org/4625
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 03f0c656c1)
Change-Id: I5bef36da0a4337d923a68f1d352b4aad1143395a
Reviewed-on: http://gerrit.openafs.org/4648
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
PSetTokens was afs_osi_Alloc'ing after afs_osi_Free'ing the previous
token data. This can sleep, causing tu->stp to be pointing to garbage
while we wait to alloc. Additionally, rxkad_NewClientSecurityObject
can sleep while waiting to alloc memory, and so the given tu->stp
pointer given to it by afs_ConnBySA may be invalid by the time it
actually uses the data.
To fix this, we could implement unixuser locking to ensure mutual
exclusion of these events. However, this implements a more
conservative change for the 1.4 branch. In PSetTokens we alloc the new
memory before we change anything, and in afs_ConnBySA we make copies
of the ticket data before giving it to rxkad. With these changes, the
glock gives us enough serialization to avoid issues with tu->stp
changing underneath us.
This change is 1.4-specific. On the master branch, this issue is fixed
by implementing unixuser locks in change
Idd66d72f716b7e7dc08faa31ae43e9a23639bae3.
Change-Id: I3eb59e611531eca8105cf4d4f67eb1bb1196fd9c
Reviewed-on: http://gerrit.openafs.org/4649
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
If our call to mod_install fails for any reason (for example, if the
afs entry is missing from /etc/name_to_sysnum), we may still have set
the sysent structures for setgroups and ioctl to point at libafs code.
So calls to those syscalls will cause a panic, since the code they
point to is no longer loaded.
To avoid this, just reset the sysent entries back to what they were if
we fail to load, just like we do when unloading the module.
Reviewed-on: http://gerrit.openafs.org/4685
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit ca425b7d49)
Change-Id: Iac5a2a4379a386393a42803821b8645764067521
Reviewed-on: http://gerrit.openafs.org/4688
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
return fail, rather than success, if no fid and thus
no list of servers to resort, in BlackListOnce.
will need a later change for vlservers
reported by jhutz@cmu.edu
Reviewed-on: http://gerrit.openafs.org/2473
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 43f3a074f0)
Change-Id: Ic4cfb511a409fa654ebe57f068986d6bd8cd67f5
Reviewed-on: http://gerrit.openafs.org/4667
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Every five minutes we afs_ShakeLooseVCaches to try and return the
number of vcaches in use down to the originally configured -stat level
(when we are using dynamic vcaches). We should calculate how many
vcaches to flush based on the number of currently active vcaches
(afs_vcount), not the peak number (afs_maxvcount). Otherwise, once we
exceed the configured -stat level, we will always keep trying to flush
numerous vcaches, even if we barely have any vcaches in use.
Reviewed-on: http://gerrit.openafs.org/4584
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 2a2206bfe1)
Change-Id: Ia8074673ac8c07770bb90016502a9ea860445660
Reviewed-on: http://gerrit.openafs.org/4621
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
update configure version strings for 1.4.14.1. note that macos kext
can be of form XXXX.YY[.ZZ[(d|a|b|fc)NNN]] where d dev, a alpha,
b beta, f final candidate so we have no way to represent 1.4.14.1.
switch to 1.4.15 dev 1 for macos.
Change-Id: I955a54fd44a411989b5eea2521f82909621f14cd
Add AFS_SUN5_ENV to the list of platforms where AFS_DAEMONOP_ENV is
defined. Implement the necessary functionality so we spawn kernel
threads when a daemon syscall is called. Remove the rxk_Listener
wrapper, since it will be called in a separate thread via the
afs_DaemonOp interface.
Reviewed-on: http://gerrit.openafs.org/4189
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit e261238470)
Change-Id: Ic6e116673caf8cfaf5c894a5ab9d9383bdaa3b0f
Reviewed-on: http://gerrit.openafs.org/4610
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
Create the AFS_DAEMONOP_ENV define to simplify the logic of when we
perform afs_DaemonOp-y code paths. Also create the daemonOp_common
function, to perform common pre-fork operations that are common
between platforms.
Reviewed-on: http://gerrit.openafs.org/4188
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 6143bb27d2)
Change-Id: Id44385334e8dd0485f6250c9e4c2a8d7337cf211
Reviewed-on: http://gerrit.openafs.org/4609
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
Conflicts in this cherry-pick (http://gerrit.openafs.org/4041) were
resolved incorrectly. The correct resolution of
"""
<<<<<<< HEAD
||||||| parent of 0d95e6b... linux: 2.6.38: New d_op handling
#if defined(AFS_LINUX26_ENV)
=======
#if defined(STRUCT_SUPER_BLOCK_HAS_S_D_OP)
sb->s_d_op = &afs_dentry_operations;
#endif
#if defined(AFS_LINUX26_ENV)
>>>>>>> 0d95e6b... linux: 2.6.38: New d_op handling
"""
is
"""
#if defined(STRUCT_SUPER_BLOCK_HAS_S_D_OP)
sb->s_d_op = &afs_dentry_operations;
#endif
"""
and not
"""
#if defined(STRUCT_SUPER_BLOCK_HAS_S_D_OP)
sb->s_d_op = &afs_dentry_operations;
#endif
#if defined(AFS_LINUX26_ENV)
"""
As usual, it’s impossible to tell the difference in the default
conflict style, so I urge everyone reading this to run
git config --global merge.conflictstyle diff3
Change-Id: I09fb77b2f1d80beda7b81fa1f40f663117dae920
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-on: http://gerrit.openafs.org/4596
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
The NetIfPoller code that is enabled on AFS_SUN510_ENV never gets
shutdown properly. The current code looks as if it was intended for
NetIfPoller to recognize the appropriate termState and just return,
but we never wait for it, and so we can complete the shutdown sequence
without NetIfPoller ever knowing that we are shutting down. This can
cause the machine to panic, as we keep attempting to run NetIfPoller
even after libafs has been unloaded.
Since NetIfPoller is fired by default every 30 seconds, we probably do
not want to wait for it to fire during shutdown. Instead, just destroy
the necessary timeout and task queue, which will wait for NetIfPoller
to complete if running, and will just prevent it from running in the
future otherwise.
Reviewed-on: http://gerrit.openafs.org/1957
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 9562721b89)
Change-Id: Ida24a406958cdafa54bdda954c34a05ef4e7e459
Reviewed-on: http://gerrit.openafs.org/3589
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Reviewed-on: http://gerrit.openafs.org/4045
Tested-by: Derrick Brashear <shadow@dementia.org>
