In RDR_PopulateCurrentEntry it is possible for TargetNameLength and
TargetNameOffset to be uninitialized resulting in stack garbage being
returned to the redirector. This can result in a blue screen.
Change-Id: Ifa306ba54bea3f26f1938cbd6bdc28521065299d
Reviewed-on: http://gerrit.openafs.org/10373
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If cm_RecycleSCache returns an in-hash entry it means that either
it wasn't recycled properly or somehow we raced this entry with
another thread. Just skip it and keep searching.
Change-Id: Ia443a04b063a019003662639d31f96db486d673c
Reviewed-on: http://gerrit.openafs.org/10353
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
If the cm_scache_t has CM_SCACHEFLAG_INHASH flag set but cannot be
found in the CH_SCACHE_HASH(&scp->fid) hash chain then search the
entire hash table for the object. At the end of the function we
will know that the CM_SCACHEFLAG_INHASH flag is safe to clear.
Change-Id: I92bfad98b7d3cdc42b5aa6b8fae24d47557465e7
Reviewed-on: http://gerrit.openafs.org/10352
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The Windows IO Manager is not supposed to issue multiple
outstanding cached writes to a file system for a synchronous
file object. To do so would risk out of order application
of writes that extend the end of file and in turn risk data
corruption. It turns out that on Server 2003 SP2 and more
than likely XP and 2000 as well, if a file system returns
STATUS_PENDING because a write was deferred due to the
Windows Cache Manager failing CcCanIWrite(), the IO Manager
will happily continue issue subsequent write requests.
On OSes older than Vista disable the use of deferred writes
and sit in a spin loop waiting for the Windows cache manager
to make room. This is much less efficient and increases the
write latency but it is safe.
Change-Id: Ic47d62749bdb4d0475661967fcbfd25834f21a72
Reviewed-on: http://gerrit.openafs.org/10351
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
In DriverEntry() RtlGetVersion() is used to obtain the OS version
information. Store the result in a global structure that can be
used elsewhere to make run time decisions based upon the OS.
Change-Id: I194e7da6858d1dea755d8de82a9bee70e63ade4d
Reviewed-on: http://gerrit.openafs.org/10350
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
It was not compiled into anything.
Correct references in bucoord_internal to command.c.
Remove the forward declaration of struct cmd_parmdesc and make cmd.h
a prerequisite for this header, since all but two consumers had cmd.h
already.
Change-Id: Id60a550871643610ccd96c226ecf0a3c4acb3955
Reviewed-on: http://gerrit.openafs.org/10363
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
_afsconf_OpenInternal() may exit early for a number of reasons
before properly initalizing afsconf_dir->listKeys.
This leads to a crash when _afsconf_CloseInternal() attempts
to clean up listKeys.
Prevent this situation by calling afsconf_InitKeys() before any
possible exit from _afsconf_OpenInternal().
Change-Id: I6911427817a2518a576c00a7ea56351f9fb4fd19
Reviewed-on: http://gerrit.openafs.org/10323
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Include the generated header in the current directory.
Change-Id: Iaa22fcfd0e22e5f33e7c9bf8a26a838b25668160
Reviewed-on: http://gerrit.openafs.org/10361
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Commit 65e701fee4 introduced a couple of
select() calls when the pthreaded vos writes to or reads from a usd
pipe, corresponding to the IOMGR_Select() calls in LWP. However, these
select() calls are unnecessary, since the read() or write() calls
themselves will block anyway. The reason they are there for LWP is so
the IOMGR can run another process while we're waiting for the file
descriptor to be ready.
The select() in ReceiveFile currently incorrectly waits for the output
to be ready for reading, even though we're trying to write to it. As a
result, if we try to 'vos dump' to a pipe with the pthreaded vos (such
as stdout), we will hang forever, since it will never be ready for
reading.
To fix this, just get rid of the select() calls, since they don't
really do anything.
FIXES 131749
Change-Id: Ibe8841e0c01f1e55ac4ca1a8a99ab71083654662
Reviewed-on: http://gerrit.openafs.org/10360
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Fixing a couple typos and rewording a comment for clarity in afs_segments.c
Change-Id: Ic631b6f8d59e4e9a56f61e583a8ef0f8f8794d8b
Reviewed-on: http://gerrit.openafs.org/10364
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
9.2 is newly released and HEAD is now 11-current.
Change-Id: Ic79ff26aa39e08940b6035770fe4c6f15b02c418
Reviewed-on: http://gerrit.openafs.org/10341
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
On the BSDs, struct timeval is not two 32-bit integers like our
struct clock, so the ABI is quite incompatible. Use the native type
for the function call and translate to our local type accordingly.
This lets us get rid of a workaround for the FreeBSD kernel build,
wherein particular compiler flags masked the stack corruption that
can occur due to this ABI mismatch.
Change-Id: I68f9947b0875dca7343ecd41a4c529d5c5bc3be5
Reviewed-on: http://gerrit.openafs.org/10340
Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Antoine Verheijen <apv@ualberta.ca>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Move a rmlock.h inclusion up a bit so that the vm headers can get the
rmlock assertion (and other) macros they need.
The filedesc structure has been expanded on FreeBSD to support a
stronger capabilities system; getting to the actual file descriptor
requires another structure access.
limits.h and stdarg.h need sys/ and machine/ prefixes for inclusion in the
kernel on FreeBSD. Fixing this lets us get rid of some unnecessary -I
arguemnts in the kernel module build, which seem to have not been functioning
as expected, anyway.
Catch up to VM layer changes.
This builds, but crashes at runtime due to some ABI incompatibilities
that appear in the rx event layer; those will be fixed in a separate patch.
Change-Id: Icc253b1e938a58a7ab8d1b789c82b9b940d263fd
Reviewed-on: http://gerrit.openafs.org/10339
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Commit 6c41b1f740 improved a few log
messages to include the client ip and port of the request triggering
that log message. Include the viceid and fid (if applicable), too, so
an administrator may more easily identify the cause.
This creates the function LogClientError, so we can use a common
function for logging very similar information. This also modifies
h_FindClient_r to give the viceid to the caller, even in the case of
error. In addition, this modifies CallPreamble to accept a fid and
modifies all callers to accomodate.
Change-Id: I326e17538265ea3251db27a05ede25c33e9a230d
Reviewed-on: http://gerrit.openafs.org/10347
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
from tabular_output.h to afsutil_prototypes.h
Like this, tabular_output.h does not have to be included
in any devel-package.
Change-Id: I9e3089fe4a65b2a801c45ba513a8f5dc49ce609b
Reviewed-on: http://gerrit.openafs.org/10327
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The primary motivation is to get automatic log rotation, but we
also get built-in locking for the logging calls.
This does have a side effect of changing the format used to print
timestamps in the log file.
Export WriteLogBuffer from liboafs_util so as to be mostly compatible
with the ... idiosyncrasy of LogError()'s previous behavior.
Garbage-collect the unused (and un-exported) printHashTable() and LogNetDump().
Change-Id: I860370e60082ea355806b3f1945eee76db7c32e3
Reviewed-on: http://gerrit.openafs.org/10333
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Karl Ramm <kcr@1ts.org>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
In general, the salvager will try to salvage any volume if we find an
inode for that volume. However, for namei, we'll always have at least
one inode for the RW volume, even if we only have e.g. an RO volume at
a particular site, since the linktable special inode is always marked
as for the RW volume id. So, if we salvage a volume group that only
has an RO, normally we would also try to salvage the corresponding RW,
even if it doesn't exist. We would then recreate the "missing"
metadata files, so after salvaging, the RW appears to exist as a
normal volume.
The salvager currently tries to avoid this by skipping salvaging the
RW if we find more than one volume in the volume group, and if the RW
only has one special inode, and that one special inode is the
linktable. This solves the problem most of the time, but misses a few
corner cases:
- If we found more than one linktable, we'll try to salvage the RW
anyway. This shouldn't happen, but certain cases of corruption can
cause incorrectly-named linktables, resulting in multiple
linktables.
- If we only find one volume (the RW), we'll still salvage the RW,
even if the only inode for it is a single linktable. This can
happen due to botched salvages in the past, or interrupted deletes
and such. It's just cruft.
In any situation like those, we cause an RW volume to be created where
there previously was none. This can be a problem, since the RW volume
is unknown to the administrator, and does not appear in the VLDB. Such
"phantom" volumes can be very confusing and can cause problems in the
future. For example, if that same RW volume is moved to the server
with the "phantom" RW volume, we now have two of the same RW volume on
the same server on different partitions, which is a big problem.
So, to avoid these corner cases, check all of the special inodes to
see if all of them are linktables. Also perform this check if we don't
have any non-special inodes (even if we only see 1 volume), to catch
the "cruft" case above.
Change-Id: I00df021ebedce44f69302a48ed2716bd9bda124e
Reviewed-on: http://gerrit.openafs.org/10321
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Currently, if we detect an inconsistent linktable filename (where the
filename indicates it's for a different volume than the directory path
indicates), we don't set the linkCount for the inode info. This means
that our caller will get random garbage for the linkCount.
In many cases this value is ignored, but for the salvager, if this is
the only linktable file we find, we treat it as the linktable we
should be using. Thus, if linkCount contains undefined data, we might
try to INC or DEC the linktable a bunch of times, depending on what
random stack garbage the linkCount is filled with.
The salvager shouldn't be INC/DEC'ing these linktables according to
the their linkCount anyway, but in the meantime, at least ensure that
this doesn't contain stack garbage, so we ensure that we won't try to
INC or DEC this thousands or millions of times.
Change-Id: Ib5e7f45d5739878434cbe57b6f2ab532f002e5b8
Reviewed-on: http://gerrit.openafs.org/10320
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
The rx calls will take locks when built in pthreaded mode, and must go
after rx_Init(). Some other setup would benefit from using time-domain
locking and should run before we go multithreaded.
In particular, initialize bozo_confdir while single-threaded, as it is
otherwise protected by the afsconf internal locking. While here, pass
NULL to afsconf_SetCellInfo -- bozo_confdir would always be NULL there,
anyway.
Change a couple globals into local variables in main; they are just
used to defer setup after argument parsing.
ReadBozoFile will create worker threads to monitor child processes,
so it cannot move up too far.
Change when we daemonize, too.
Change-Id: If7b6883748919270c9a5a41cd8e6fb724e95aa36
Reviewed-on: http://gerrit.openafs.org/10285
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>
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 843d705ca6.
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 7694f536d3
(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>
