This stuff has been #if 0'd for ages; put it out of its misery.
While here, remove the global bnode_waiting which is not used for anything.
bnode_SoftInt claims to return a pointer, so return NULL instead of 0.
Change-Id: Ie7b32bbc606a105190d246355f47bd7ea885c6f8
Reviewed-on: http://gerrit.openafs.org/10284
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Without this commit, when we break callbacks for a fid, we loop over
all callbacks for the fid, break a few of them, and then start over.
We do this repeatedly until we run out of callbacks. If a client sees
a callback break, and then establishes a new callback promise while
the fileserver is still breaking callbacks, the fileserver can break
the same callback for the same host again and again. This can continue
forever, if the client establishes its new callback promises quickly
enough.
So to avoid this, when we start breaking callbacks, flag all of the
callback structures that we want to look at. Then when we repeatedly
loop through all of the callbacks for the fid, only look at the
flagged callback structures.
This adds a 'flags' field to struct CallBack, and defines a single
flag, CBFLAG_BREAKING.
This is an alternative fix to the issue also fixed in 843d705c. This
implementation avoids allocating extra memory under locks, and has the
slight benefit of not breaking callbacks that were elsewhere deleted
during the BCB. This comes at the cost of a single extra traversal
through our callback list, and the cost of claiming one of the bits in
the CallBack structure.
Change-Id: I6418bd404de61ec7a531261ecf581eeea719a2d4
Reviewed-on: http://gerrit.openafs.org/10172
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
This mostly reverts commit 843d705ca6f0250c3760ec2aa1f3403d19de3df1.
That commit causes each callback-breaking thread to potentially use up
a large amount of memory, as well as possibly causing large memory
allocations under H_LOCK, which isn't great.
There are other ways to allow for atomic callback breaks. Revert that
commit to allow for alternative methods to be implemented in separate
subsequent commits. Do this in separate commits so pullups to stable
branches are easier.
This does not revert the change in the definition of MAX_CB_HOSTS.
That value can still be large due to the improved multi_Rx
implementation.
Change-Id: I14024b4d80696b0361658b1c5ae7af308629fab4
Reviewed-on: http://gerrit.openafs.org/10171
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
"these used to be asserts" is not a useful comment. This area of code
does maybe look a little confusing at first glance, though, so replace
these with comments that are more informative.
Change-Id: I4e0b9dff3d010931e02559e82165ffbd61c5b189
Reviewed-on: http://gerrit.openafs.org/10313
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
When we have a nonexistant or invalid linktable, we manually set all
of the linkcounts to 1, since we're recreating the link table from
scratch. However, we also have a linkCount count in our in-memory
allInodes array, which could be populated by garbage if we had a
garbage linktable. So make sure to set our in-memory linkCount to 1
for each inode, so we don't use garbage linkcount data.
Change-Id: I8f4873e12f70f81ee6f2c764957e77136b0a385e
Reviewed-on: http://gerrit.openafs.org/10312
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The whitespace here is pretty weird. Clean it up a little.
Change-Id: Ia558d453301ee1231cfb21ee87dc7f190dc905d7
Reviewed-on: http://gerrit.openafs.org/10311
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
When gop_lookupname_user returns a non-NULL vnode, the vnode came
from afs_GetVCache (by way of afs_lookup) which takes a reference
on the vnode entry. There's no need to take another spurious
reference here. The existing code already knows that there's a
reference in place, as there is an AFS_RELE down where FBSD80_ENV
unlocks the vnode if it's locked (that code is also suspicious).
Prior to this patch, things like 'fs flush /path/to/file' would
leak a reference on that cache entry, preventing clean shutdown.
Change-Id: Iefb7be16bb76b709ffd7cfc082ef9078adf9e354
Reviewed-on: http://gerrit.openafs.org/9957
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Introduce spawnprocve_sig, a variant of spawnprocve that allows
a caller to spawn a process with a specific signal mask.
This is useful when we want to set a mask that is different
from the current one. It needs to be done after the fork()
so that the current thread is not affected.
Change-Id: I900c85cb70d22756b78562618b0e853dcedf8235
Reviewed-on: http://gerrit.openafs.org/8749
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Right now, if you give ih_attachfd_r an invalid fd, and fdLruHead is
NULL, we'll return an FdHandle_t* for an invalid fd. Nowhere in the
code is this possible right now, but the implementation of
ih_attachfd_r and ih_attachfd doesn't make this very clear.
Ideally the "close some fds and retry" behavior in ih_attachfd_r will
be split out, so this code could be easier to follow, and we could
implement open() EMFILE retrying for icreate operations. But for now,
just make the current behavior clearer, so future modifications do not
introduce such mistakes.
Change-Id: Ibc80b32bc6f50480d12e3241fe198bc0587a962c
Reviewed-on: http://gerrit.openafs.org/10249
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The syntax is a little confusing, so an example is needed to clarify it.
Change-Id: I413a5f2af6ccf48e780007c658c35a34384d09e0
Reviewed-on: http://gerrit.openafs.org/10281
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
When running vos release with the -verbose flag, print the reasons for a
complete release, and the reasons for doing a full dump of the volume. When
doing a full dump, have the verbose output print 'entire volume' instead of
'full release', to avoid confusion with a complete release.
Change-Id: I041da692bfea5d7eb0c96d51a5a794e3eeeb6d72
Reviewed-on: http://gerrit.openafs.org/9018
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Fix a build error for older versions of linux, introduced by
commit 7694f536d3997768b69a635616b0cf24d71a595a
(scsi_command_size became scsi_command_size_tbl)
Fixes a build error on RHEL/CentOS 5.9; 2.6.18-348.3.1.el5.
Change-Id: I7e6f08e7f7cbba47034701e6137eb91fa567dbda
Reviewed-on: http://gerrit.openafs.org/10282
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
to vos "setfields". It might be a misleading if it exists
sucessfully when clearly invoked wrongly.
Change-Id: Ic92f4e17fde0a0dfc182f9713350800c72fa165e
Reviewed-on: http://gerrit.openafs.org/10271
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
State upfront that klog and klog.krb (v4) are obsolete.
Update the klog.krb description and remove some redundant
text.
Change-Id: I6ede8084aebbd49c5a27aa427ef9782d99a347aa
Reviewed-on: http://gerrit.openafs.org/10270
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Upstream r248084 changed the vm_object mutex to be a rwlock,
allowing for future optimizations. This is a KPI change, so
introduce conditionals to be compatible with both versions of the KPI.
Change-Id: I6e3101bc80262480035dee4c5b2d1b9cbc44b57b
Reviewed-on: http://gerrit.openafs.org/10295
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Change all makefile rules which run compile_et in order support parallel
make. The compile_et generates two outputs, so special care must be
taken in rules which run compile_et.
All the rules for compile_et have been changed to the form:
foo.c foo.h: foo.et
compile_et foo.et -h foo
foo.h: foo.c
The above rules are equivalent to:
foo.c: foo.et
compile_et foo.et -h foo
foo.h: foo.et foo.c
compile_et foo.et -h foo
therefore a parallel make will serialize the builds of foo.c and foo.h,
and should detect that the second is no longer needed once the first is
over. This form works since foo.et is not a phony target, and does not
depend on a phony target.
Previously, the rules for compile_et were of the one of the two forms:
a) foo.c foo.h: foo.et
compile_et foo.et -h foo
or
b) foo.h: foo.c
foo.c: foo.et
compile_et foo.et -h foo
Form a) is problematic for parallel makes, since it is equivalent to:
foo.c:
compile_et foo.et -h foo
foo.h:
compile_et foo.et -h foo
In a parallel make, compile_et will be run concurrently, clobbering
each other's output files.
Form b) is better, but is problematic when foo.h is removed, since foo.h
will not be updated.
Thanks to Russ Allbery for pointing out the automake documentation which
describes issues with commands that produce multiple outputs, and
portable solutions.
http://www.gnu.org/software/automake/manual/automake.html#Multiple-Outputs
Change-Id: I14c056606084f80270e05592d3d09a600f804e24
Reviewed-on: http://gerrit.openafs.org/10237
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
When adding mount points or symlinks do not chase mount points
when attempting to determine the FID of the added object.
Change-Id: Ic4e070d687cc56407a19c41f185f3e28db7671bd
Reviewed-on: http://gerrit.openafs.org/10298
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
It is possible for cm_MergeStatus() to be called while the
cm_buf_t.mx is already held. If it is a panic occurs. Test for
refcount == 0 before acquiring the lock in addition to afterwards.
If the refcount is not zero, then we do not need to acquire the
lock in any case.
Change-Id: I1b73a03f4745e524d7fdf8f9b231b420895ff0fa
Reviewed-on: http://gerrit.openafs.org/10297
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If a test for NULL is performed ahead of an assignment and then
use of the assigned value, there is a race which can result in
the assigned value being NULL if the value being assigned is
altered by another thread.
Perform the assignment first then test based upon that.
Change-Id: I6d50619dab168c2aa12542b14217779f1be08ee9
Reviewed-on: http://gerrit.openafs.org/10296
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
com_err.h can be in com_err.h, et/com_err.h, or krb5/com_err.h (for
netbsd 6.1 and possibly other netbsd). aklog currently only includes
either com_err.h or et/com_err.h, depending on autoconf probes
performed by the krb5.m4 macros.
So, also look for krb5/com_err.h. The krb5.m4 macros currently only
look for com_err.h at all if certain other libkrb5 tests return
certain results, so just look for all of them directly in some of our
openafs-specific krb5 probing logic in configure.ac.
Also remove the duplicate check for et/com_err.h in acinclude.m4 while
we're here. We only use et/com_err.h if krb5 support is enabled, so
only check for it in the second of krb5 probes.
FIXES 131716
Change-Id: Ic454b9bf7043f91654dcd1c262ab3790bf2ad272
Reviewed-on: http://gerrit.openafs.org/10244
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
If we are using single-DES keys in our KeyFile, yell at the
administrator, so they have a chance at realizing that they should
migrate to stronger crypto.
Change-Id: Ic37d9e1cea7ee7e12594be0dec02000f11efc896
Reviewed-on: http://gerrit.openafs.org/10273
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
When we "nuke" a volume, we delete all inodes we can find that are for
the given volume id. This currently means that if we nuke an RW volume
id, we delete all of the inodes for file data for the entire volume
group (since they're all stored in the VG id), but we do not delete
the special inodes for any non-RW volumes in that volume group. Those
special inodes left behind are not very useful, since we just deleted
all of the actual file data.
Currently this means that on namei, it's impossible to nuke the
special inodes for non-RW volumes, since the namei nuke will only look
in the subdir for the given volume id. If you give it the RW volume
id, it won't delete the special inodes as menioned above; if you give
it the RO volume id, it will only look in the RO subdir, and won't
find the RO special inodes in the RW subdir.
If a volume group is damaged in such a way that the salvager cannot
fix it (due to a bug), this means that it is impossible to get rid of
that volume group completely from the partition on namei without
manually running "rm -rf" on the relevant AFSIDat directory. Normally
we have a failsafe of running 'vos zap -force', but that doesn't work
for non-RW special inodes, as mentioned above.
So, in order to allow this 'vos zap -force' failsafe to work in
hopefully all situations, also delete the special inodes for the
parent volume. Use similar logic as exists in the salvager's
OnlyOneVolume function.
Change-Id: Id29da48a548c70b2b9ada1dd09f41cb59452bd11
Reviewed-on: http://gerrit.openafs.org/10256
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The C type for xdr's bool is bool_t. When casting, use the correct type
Change-Id: I562ee1e48eeffa8fece66176cf13013630d157aa
Reviewed-on: http://gerrit.openafs.org/10261
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Cap the retry delay to a reasonable amount of time instead
of just doubling the delay until it reaches 16 hours.
Change-Id: Ibc7dd75670a9b02f34050842b6e54df4f5a7c315
Reviewed-on: http://gerrit.openafs.org/10148
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit c10f5296 made rx_Init only call rxi_StartListener in the kernel
if we have RXK_LISTENER_ENV. But this doesn't make any sense, since
rxi_StartListener only does anything if RXK_LISTENER_ENV is _not_
defined. As a result, for any non-rxk-listener non-rx-upcall platform,
we never receives rx packets in the kernel, since we never set up our
rx packet callback. The only such platform appears to be AIX, since
while other platforms (HPUX, FBSD, IRIX) have a non-rxk-listener mode,
they also implement an rxk-listener mode that we always turn on.
So, just always call rxi_StartListener, and let the ifdef guards for
the various implementations of rxi_StartListener do the right thing.
FIXES 131725
Change-Id: I209a89bda06f2c790aca2682468066c7b0bb7edd
Reviewed-on: http://gerrit.openafs.org/10263
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
turns out not just writev is unhappy with aio_write (only); core dumping
wants a write file op. always provide it.
FIXES 131729
Change-Id: If099f83973825981b4c568db7572bf30d399c089
Reviewed-on: http://gerrit.openafs.org/10251
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
if the mountdir in the cacheinfo file is not absolute,
it can confuse commands like "df". Thus, force it to
be absolute.
Change-Id: Idb098b7c83fef6931fe71dd53a85569a953e5e3f
Reviewed-on: http://gerrit.openafs.org/10250
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
if we are symlinked to ourself directly, return ELOOP.
Change-Id: I408012c4a9afb6bab0e917677c940f65ad59c697
Reviewed-on: http://gerrit.openafs.org/10240
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
in order that we can make a future version static, move the code.
Change-Id: I67e50ef5f14db3567ecd437b694b62b2c8fdb760
Reviewed-on: http://gerrit.openafs.org/10239
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
when we do a no cache read, we should decrease the resid as we use
up buffer... otherwise we have no idea in the caller how much data
actually got transferred
Change-Id: I50072fddcde1681b3760002d5065b1c2d9b97605
Reviewed-on: http://gerrit.openafs.org/10231
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
when processing "fs sysname" on a client, a rmtsys-related
checks are executed by default. These prevent a user with gid
2750 and 274i8 (0xabc and 0xabe) from executing this command.
Add a new flag inside the cachemanager for the rmtsys-
functionality. This flag is set through a new ioctl by the afsd
on startup.
Change-Id: Idf95aa81cc1dbb46c70a11b9ae2ccfa04bfb4c4f
Reviewed-on: http://gerrit.openafs.org/10245
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Fix a bug introduced by the check to avoid excessive stats of the
cellservdb. Fixes a bug where cached cell config data is served for up
to one second after a write.
Check the timeRead field which is reset after a write to indicate the
data should be read.
Fixes commit 0e3bfa033ed230fcb46ad8e3c26c8b7aae6e00af
Change-Id: I209e93a1bc4107a878eefaae92ec0e5e4ada2518
Reviewed-on: http://gerrit.openafs.org/10230
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
read/write will fall back to aio ops but e.g. writev will
fail if there is not either a write or writev op explicitly.
force the fallback via do_sync_read/do_sync_write
required with 2.6.18-348.x rhel kernels but probably not newer ones
Change-Id: I773a8e38df435015e4bc9fc353d930d14b3e6791
Reviewed-on: http://gerrit.openafs.org/10246
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: Derrick Brashear <shadow@your-file-system.com>
honour the returncode of key_instantiate_and_link() to avoid
having non-working pagsh without an error.
Change-Id: Ia62c1c24b22e833cd5dc2689181397965901d34e
Reviewed-on: http://gerrit.openafs.org/10179
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
In preparation for upcoming changes in the 3.12 cycle, d_lockref
was introduced late in the 3.11 cycle. The dentry's d_lock and
d_count are moved to this new structure. A new d_lock macro makes
the change transparent for locking, but direct users of d_count
must adapt. A new d_count() helper function is provided and
should now be used.
Use the new d_count() helper function if available, and move
some of the ifdef logic into a helper compatibility function.
Change-Id: I32a21a174d763fb7df8f1e04da3bb7260684571d
Reviewed-on: http://gerrit.openafs.org/10219
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If a callback race has been lost cm_MergeStatus is not executed.
In that case either the activeRPC count should not be incremented
or must be decremented to indicate that the current call has been
completed.
Change-Id: I417f72bbc482f6d207ed0c09770b1d8a53d078ff
Reviewed-on: http://gerrit.openafs.org/10218
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If the CcPurge operation fails or cannot be performed, in addition
to setting the purge on close flag, set the verify data flag. This
ensures that the next attempt to access the file will retry the
purge.
Change-Id: I9ebbdab8b5dd31ace5d316454b6e54cf537686d5
Reviewed-on: http://gerrit.openafs.org/10217
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Add trace statements at each location the VERIFY flag is set or
cleared.
Change-Id: I108d3d44947bc92f147afb66f746af3262435104
Reviewed-on: http://gerrit.openafs.org/10216
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If the redirector is using Direct IO servicing there are no extents
in use. Skip the AFSFlushExtents, AFSTearDownExtents, and related
calls unless extent processing is in use. This will reduce lock
contention and reduce cpu processing.
Change-Id: I2948295bdd6056e6fbdab7d32c46575a8a7aebbc
Reviewed-on: http://gerrit.openafs.org/10215
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
Now that the Fcb Resource and SectionObjectResource are held in
the FastIo pathway and the Trend Micro deadlock has been addressed
by holding a reference on the FileObject it is time to fix the
lock acquisition ordering. For each CcPurgeSection call the
Fcb Resource will be held exclusive before the SectionObjectResource.
Change-Id: Ica9e3674b39e2789c35bcf13d9fa1f2326420119
Reviewed-on: http://gerrit.openafs.org/10192
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
