Benjamin Kaduk [Wed, 18 Feb 2015 20:52:30 +0000 (15:52 -0500)]
Merge branch 'master' into experimental
Pick up the spanish translation, the changelog from master, and
CellServDB updates. Some of the new patches will not apply against
this new upstream version, which will be addressed in a follow-up
commit.
Andrew Deason [Wed, 4 Feb 2015 16:25:38 +0000 (10:25 -0600)]
rx: Zero unitialized uio structs
We use some uio structures that were allocated on the stack, but we
only initialize them by initializing individual fields. On some
platforms (Solaris is one known example, but probably not the only
one), there are additional fields we do not initialize. Since we
cannot be certain of what any additional fields there may be, just
zero the whole thing.
This is basically the same change as
I0eae0b49a70aee19f3a9ec118b03cfb3a6bd03a3, but in the rx subtree.
Reviewed-on: http://gerrit.openafs.org/11711 Tested-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Daria Brashear <shadow@your-file-system.com>
(cherry picked from commit a762e6871ad6837ee126cec9e63d99388b4bf119)
Change-Id: Ie6a2cce500d6a0a7a09c305296f4b34d122d3108
Reviewed-on: http://gerrit.openafs.org/11714 Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marc Dionne [Thu, 18 Dec 2014 13:43:22 +0000 (08:43 -0500)]
Linux: d_splice_alias may drop inode reference on error
d_splice_alias now drops the inode reference on error, so we
need to grab an extra one to make sure that the inode doesn't
go away, and release it when done if there was no error.
For kernels that may not drop the reference, provide an
additional iput() within an ifdef. This could be hooked up
to a configure option to allow building a module for a kernel
that is known not to drop the reference on error. That hook
is not provided here. Affected kernels should be the early
3.17 ones (3.17 - 3.17.2); 3.16 and older kernels should not
return errors here.
[kaduk@mit.edu add configure option to control behavior, which
is mandatory on non-buildbot linux systems]
Reviewed-on: http://gerrit.openafs.org/11643 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 15260c7fdc5ac8fe9fb1797c8e383c665e9e0ccd)
Andrew Deason [Fri, 30 Jan 2015 19:29:57 +0000 (13:29 -0600)]
afs: Zero uninitialized uio structs
In several places in the code, we allocate a 'struct uio' on the
stack, or allocate one from non-zeroed memory. In most of these
places, we initialize the structure by assigning individual fields to
certain values. However, this leaves any remaining fields assigned to
random garbage, if there are any additional fields in the struct uio
that we don't know about.
One such platform is Solaris, which has a field called uio_extflg,
which exists in Solaris 11, Solaris 10, and possibly further back.
One of the flags defined for this field in Solaris 11 is UIO_XUIO,
which indicates that the structure is actually an xuio_t, which is
larger than a normal uio_t and contains additional fields. So when we
allocate a uio on the stack without initializing it, it can randomly
appear to be an xuio_t, depending on what garbage was on the stack at
the time. An xuio_t is a kind of extensible structure, which is used
for things like async I/O or DMA, that kind of thing.
One of the places we make use of such a uio_t is in afs_ustrategy,
which we go through for cache reads and writes on most Unix platforms
(but not Linux). When handling a read (reading from the disk cache
into a mapped page), a copy of our stack-allocated uio eventually gets
passed to VOP_READ. So VOP_READ for the cache filesystem will randomly
interpret our uio_t as an xuio_t.
In many scenarios, this (amazingly) does not cause any problems, since
generally, Solaris code will not notice if something is flagged as an
xuio_t, unless it is specifically written to handle specific xuio_t
types. ZFS is one of the apparent few filesystem implementations that
can handle xuio_t's, and will detect and specially handle a
UIOTYPE_ZEROCOPY xuio_t differently than a regular uio_t.
If ZFS gets a UIOTYPE_ZEROCOPY xuio_t, it appears to ignore the uio
buffers passed in, and supplies its own buffers from its cache. This
means that our VOP_READ request will return success, and act like it
serviced the read just fine. However, the actual buffer that we passed
in will remain untouched, and so we will return the page to the VFS
filled with garbage data.
The way this typically manifests is that seemingly random pages will
contain random data. This seems to happen very rarely, though it may
not always be obvious what is going on when this occurs.
It is also worth noting that the above description on Solaris only
happens with Solaris 11 and newer, and only with a ZFS disk cache.
Anything older than Solaris 11 does not have the xuio_t framework
(though other uio_extflg values can cause performance degradations),
and all known non-ZFS local disk filesystems do not interpret special
xuio_t structures (networked filesystems might have xuio_t handling,
but they shouldn't be used for a cache).
Bugs similar to this may also exist on other Unix clients, but at
least this specific scenario should not occur on Linux (since we don't
use afs_ustrategy), and newer Darwin (since we get a uio allocated for
us).
To fix this, zero out the entire uio structure before we use it, for
all instances where we allocate a uio from the stack or from
non-zeroed memory. Also zero out the accompanying iovec in many
places, just to be safe. Some of these may not actually need to be
zeroed (since we do actually initialize the whole thing, or a platform
doesn't have any additional unknown uio fields), but it seems
worthwhile to err on the side of caution.
Thanks to Oracle for their assistance on this issue, and thanks to the
organization experiencing this issue for their patience and
persistence.
1.6 note: This differs noticeably from the master commit in two
places:
- src/afs/NBSD/osi_vnodeops.c: On master there is no stack-allocated
uio struct here.
- src/afs/VNOPS/afs_vnop_write.c and afs_vnop_read.c: On master,
these code paths are structured quite differently, and are handled
in afs_osi_uio.c instead.
Reviewed-on: http://gerrit.openafs.org/11705 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Daria Brashear <shadow@your-file-system.com>
(cherry picked from commit 5ef1de5eddccce0e7b135bb9ed4decaa62fc19ce)
Change-Id: I8dbf60637774dff81ff839ccd78f58b3b1e85c5b
Reviewed-on: http://gerrit.openafs.org/11713 Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 30 Jan 2015 19:08:19 +0000 (13:08 -0600)]
SOLARIS: Avoid uninitialized caller_context_t
Currently we pass a caller_context_t* to some of Solaris' VFS
functions (VOP_SETATTR, VOP_READ, VOP_WRITE, VOP_RWLOCK,
VOP_RWUNLOCK), but the pointer we pass is to uninitialized memory.
This code was added in commit 51d76681, and this particular argument
is mentioned in
<https://lists.openafs.org/pipermail/openafs-info/2004-March/012657.html>,
where the author doesn't really know what the argument is for.
Over 10 years later, it's still not obvious what this argument does,
since I cannot find any documentation for it. However, browsing
publicly-available Illumos/OpenSolaris source suggests this is used
for things like non-blocking operations for network filesystems, and
is only interpreted by certain filesystems in certain codepaths.
In any case, it's clear that we're not supposed to be passing in an
uninitialized structure, since the struct has actual members that are
sometimes interpreted by lower levels. Other callers in
Illumos/OpenSolaris source seem to just pass NULL here if they don't
need any special behavior. So, just pass NULL.
I am not aware of any issues caused by passing in this uninitialized
struct, and browsing Illumos source and discussing the issue with
Oracle engineers suggest there would currently not be any issues with
the cache filesystems we would be using.
However, it's always possible that issues could arise from this in the
future, or there are issues we don't know about. Any such issues would
almost certainly appear to be non-deterministic and be a nightmare to
track down. So just pass NULL, to avoid the potential issues.
Reviewed-on: http://gerrit.openafs.org/11704 Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Daria Brashear <shadow@your-file-system.com>
(cherry picked from commit b9647ac1062509d6a3997ca575ab1542d04677a2)
Change-Id: I5d247cfa6ada3773d20e3938957dcc31c8664bb2
Reviewed-on: http://gerrit.openafs.org/11712 Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
When a corrupt directory is discovered, scanning stops immediately and
readdir returns ENOENT. Currently, the vcache lock is unlocked and the
dcache containing the directory is released, but that's not enough.
It's also necessary to unlock the dcache, on which we hold a read lock,
and to clear the vcache state which records an in-progress readdir.
Andrew Deason [Mon, 1 Dec 2014 16:23:23 +0000 (10:23 -0600)]
LINUX: Avoid mvid NULL deref in check_bad_parent
check_bad_parent dereferences vcp->mvid, assuming it is not NULL (vcp
is a root vcache here, so mvid refers to the parent fid). However, in
some situations, vcp->mvid can be NULL.
When we first afs_GetVCache the fid, we try to set mvid by setting
mvid to the 'dotdot' structure in the volume struct. But we get that
volume struct from afs_GetVolume, which can fail (at the very least,
this can fail on network failure when looking up vldb information). If
it fails, then we do not set the mvid parent. On future lookups for
the fid, afs_GetVCache will return early for a fastpath, if the vcache
is already in memory. So, mvid will never get set in such a situation.
We also set the mvid parent fid in afs_lookup if we resolved a
mountpoint to the root vcache. However, this is skipped if CMValid is
not set on the vcache, so if CMValid is cleared right after resolving
the mountpoint (say, perhaps done by some other thread e.g. a callback
break or other reasons), then the mvid parent fid will not be set.
To avoid crashing in these situations, if vcp->mvid is NULL in
check_bad_parent, don't check the mvid, and assume it does not match
(since we don't know what it is).
Benjamin Kaduk [Wed, 4 Feb 2015 01:54:28 +0000 (20:54 -0500)]
Import a big pile of upstream patches
Bring in support for new linux versions, through 3.19 hopefully.
Also avoid spurious failures of getcwd() in some situations,
improve the configure test for key_type.match (which caused
a nasty bug on certain CentOS versions), bring in a patch that
avoids file corruption in certain cases when writing large files
fast enough to surpass the max dirty ratio, and fix a refcount leak
that manifested as odd OOPSes.
Marc Dionne [Mon, 5 Jan 2015 12:03:16 +0000 (07:03 -0500)]
Linux 3.19: No more f_dentry
Back in kernel 2.6 .20 struct file lost its f_dentry field
which was replaced by f_path.To ease transition f_dentry
was defined as f_dpath.dentry in the same header.This
define finally gets removed with kernel 3.19.
Keep using f_dentry in the code, but add a configure test
for the presence of f_path and the absence of the f_dentry
macro so we can add it if its missing.
Marc Dionne [Thu, 18 Dec 2014 12:13:46 +0000 (07:13 -0500)]
Linux: d_alias becomes d_u.d_alias
The fields in struct dentry are re-arranged so that d_alias
shares space wth d_rcu inside the d_u union. Some references
need to change from d_alias to d_u.d_alias.
The kernel change was introduced for 3.19 but was also backported
to the 3.18 stable series in 3.18.1, so this commit is required
for 3.19 and current 3.18 kernels.
Reviewed-on: http://gerrit.openafs.org/11642 Reviewed-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de> Reviewed-by: Daria Brashear <shadow@your-file-system.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d6f29679098aff171e69511823b340ccf28e5c31)
Marc Dionne [Thu, 18 Dec 2014 11:57:22 +0000 (06:57 -0500)]
Linux: Move code to reset the root to afs/LINUX
Move the Linux specific bit of code to reset the root to
afs/LINUX platform specific files. Things that play with
the Linux vfs internals should not be exposed here.
No functional change, but this helps cleanup some ifdef
mess.
Reviewed-on: http://gerrit.openafs.org/11641 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de> Reviewed-by: Daria Brashear <shadow@your-file-system.com>
(cherry picked from commit 6ca324e565c34d9d04f3c553b7d0febe675ae538)
Andrew Deason [Sun, 14 Sep 2014 19:10:11 +0000 (14:10 -0500)]
afs: Fix some afs_conn overcounts
The usual pattern of using afs_Conn looks like this:
do {
tc = afs_Conn(...);
if (tc) {
code = /* ... */
} else {
code = -1;
}
} while (afs_Analyze(...));
The afs_Analyze call, amongst other things, puts back the reference to
the connection obtained from afs_Conn. If anything inside the do/while
block exits that block without calling afs_Analyze or afs_PutConn, we
will leak a reference to the conn.
A few places currently do this, by jumping out of the loop with
'goto's. Specifically, in afs_dcache.c and afs_bypasscache.c. These
locations currently leak references to our connection object (and to
the underlying Rx connection object), which can cause problems over
time. Specifically, this can cause a panic when the refcount overflows
and becomes negative, causing a panic message that looks like:
afs_PutConn: refcount imbalance 0xd34db33f -32768
To avoid this, make sure we afs_PutConn in these cases where we 'goto'
out of the afs_Conn/afs_Analyze loop. Perhaps ideally we should cause
afs_Analyze itself to be called in these situations, but for now just
fix the problem with the least amount of impact possible.
FIXES 131885
Reviewed-on: http://gerrit.openafs.org/11464 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Daria Brashear <shadow@your-file-system.com> Tested-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 54c0ee608f4afd2b178c9b60eabfc3564293d996)
Marc Dionne [Fri, 19 Dec 2014 15:11:53 +0000 (10:11 -0500)]
Unix CM: Avoid using stale DV in afs_StoreAllSegments
It was reported in RT 131976 that on Linux some file
corruption was observed when doing mmap writes to
a file substantially larger than the cache size.
osi_VM_StoreAllSegments drops locks and asks the OS to flush
any dirty pages in the file 's mapping. This will trigger
calls into our writepage op, and if the number of dirty
cache chunks is too high (as will happen for a file larger
than the cache size), afs_DoPartialWrite will recursively
call afs_StoreAllSegments and some chunks will be written
back to the server. After potentially doing this several
times, control will return to the original afs_StoreAllSegments.
At that point the data version that was stored before
osi_VM_StoreAllSegments is no longer correct, leading to
possible data corruption.
Triggering this bug requires writing a file larger than the
cache so that partial stores are done, and writing enough
data to exceed the system's maximum dirty ratio and cause
it to initiate writeback.
To fix, just wait until after osi_VM_StoreAllSegments to
look at and store the data version
Andrew Deason [Tue, 26 Apr 2011 19:32:25 +0000 (14:32 -0500)]
Fix --without-krb5
Currently, specifying --without-krb5 causes the AM_CONDITIONAL
KRB5_USES_COM_ERR to not be defined, which makes configure refuse to
run successfully. Fix this by forcing KRB5_USES_COM_ERR to always be
false if we are running explicitly without krb5.
Benjamin Kaduk [Wed, 26 Nov 2014 17:58:10 +0000 (12:58 -0500)]
openafs-client should RemainAfterExit
Otherwise, if the options are such that there are no userland threads
that stick around (as would happen for -afsdb), systemd thinks that
we have finished, and runs the stop commands right away.
Thanks to Andrew Deason for noticing the issue at upstream.
Benjamin Kaduk [Wed, 27 Aug 2014 16:23:20 +0000 (12:23 -0400)]
Appease compile_et for objdir builds
The argument we pass to -p needs to be in the source tree, not
the object tree -- compile_et will not find the input files it
wants in the objdir tree.
For tbudb we can do this as is done on master, by just including
it in the local variable BUDB, but for tptserver and tvlserver
that is a rather invasive change.
Benjamin Kaduk [Thu, 30 Oct 2014 23:51:29 +0000 (19:51 -0400)]
Build fix for recent FreeBSD -current
r273707 added a flags argument to syscall_register(), so
add the appropriate version check in param.generic_fbsd.h
and ues that in the main code.
Reviewed-on: http://gerrit.openafs.org/11565 Tested-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit f39dd54e11dff5e2b4da3eec419ae7c0825c210f)
Note that the 1.6 branch does not have param.generic_fbsd.h, so
the patch was modified for backport to just use AFS_FBSD110_ENV
as the conditional.
Change-Id: Id2934d83940caff4f64c2a7f2187b0eca5881c8f
Reviewed-on: http://gerrit.openafs.org/11610 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Wed, 5 Nov 2014 16:22:00 +0000 (10:22 -0600)]
LINUX: Avoid check for key_type.match existence
Commit b5de4a9f removed our key_type 'match' function for kernels that
do not have such a 'match' function pointer. However, this added a
configure test where we are supposed to fail for the "new" behavior,
which is discouraged.
This causes an actual problem, because this test will fail on at least
RHEL5, due to arguably unrelated reasons (the header file for the
relevant struct is in key.h instead of key-type.h). And so, in that
situation we avoid defining a 'match' function callback, meaning our
'match' function callback is NULL, which causes a panic when we try to
actually look up keys for a PAG.
To fix this, transform the 'match' config test into one where we
succeed for the "new" behavior. We do this by testing for the
existence of the new functionality that replaced the old 'match'
function, which is the match_preparse function (specifically, the
'cmp' field in the structure accepted by match_preparse). This should
cause unrelated compilation errors to cause us to revert to the "old"
behavior instead of the "new" behavior. At worst, this should cause
build issues if we get the config test wrong (since we will try to use
the 'match' function definition that does not exist), instead of
panicing at runtime.
Note that while we test for key_type.match_preparse, we don't actually
use that function, since our 'match' functionality is the same as the
default behavior (according to b5de4a9f). So, we can avoid defining
any such function for newer kernels.
Thanks to Stephan Wiesand for bisecting this issue.
Reviewed-on: http://gerrit.openafs.org/11589 Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit a9a3cb2efff7e6c020be4687b004d157bc070ac6)
Change-Id: I59f40258c5ea35a59681f436095922d111e344f6
Reviewed-on: http://gerrit.openafs.org/11595 Tested-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Anders Kaseorg <andersk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marc Dionne [Thu, 23 Oct 2014 15:27:55 +0000 (11:27 -0400)]
Linux 3.18: key_type no longer has a match op
Structure key_type no longer has a match op, and
overriding the default matching has to be done
differently.
Our current match op doesn't do anything special so there's
no need to try to override the defaults; just remove the
assignment of .match and the associated function.
Reviewed-on: http://gerrit.openafs.org/11563 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit b5de4a9f42bb83ae03f2f647b11a1200a502d013)
Change-Id: I7baca4a7f02eac45671e1e9ebf48534cdd5830be
Reviewed-on: http://gerrit.openafs.org/11570 Reviewed-by: Anders Kaseorg <andersk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 28 Oct 2014 05:10:56 +0000 (00:10 -0500)]
LINUX: Avoid d_revalidate failure on mtpt mismatch
Currently, if afs_linux_dentry_revalidate is given an inode that
corresponds to a mtpt vcache ('vcp'), it resolves the mtpt to its root
dir if it's easy to do so (mvid and CMValid are set). Later on, we run
afs_lookup to see if looking up our dentry's name returns the same
vcache that we got; afs_lookup presumably will also resolve the mtpt
if it's easy to do so.
However, it is possible that afs_linux_dentry_revalidate and
afs_lookup will make different decisions as to whether or not they
resolve a mtpt to a dir. Specifically, if CMValid is cleared after
afs_linux_dentry_revalidate checks for it, but before afs_lookup does,
then afs_lookup will return a different vcache than
afs_linux_dentry_revalidate is expecting, even though the relevant
directory entry has not changed. That is, tvc is not equal to vcp, but
tvc could be a mtpt that resolves to vcp, or vice versa. CMValid can
be cleared by another thread at virtually any time, since this is
cleared in some situations when we're not sure if the mtpt resolution
is still valid (callbacks are broken, vldb cache entries expire, etc).
afs_linux_dentry_revalidate interprets this situation to mean that the
directory entry has changed, and so it eventually d_drop's the
associated dentry. The way that this manifests to users is that a
"fakestatted" mtpt can appear to be deleted effectively randomly, even
when nothing has changed. This can be a problem because this causes
the getcwd() syscall to return ENOENT when the working directory
involves such an affected directory.
To fix this situation, we just detect if afs_lookup returned either
'vcp' (our possibly-resolved vcache), or the original inode associated
with the dentry we are revalidating. If the returned vcache matches
either of these, then the entry is okay and we don't need to
invalidate or drop anything.
FIXES 131780
Reviewed-on: http://gerrit.openafs.org/11559 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit ba1cc838ab4a80b7a7787c441a79aca31d84808c)
Change-Id: I3273cc15ebe7fd94f3127840fdc5316bd7458e7c
Reviewed-on: http://gerrit.openafs.org/11568 Reviewed-by: Anders Kaseorg <andersk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 24 Jul 2014 16:07:45 +0000 (11:07 -0500)]
LINUX: Check afs_lookup return code explicitly
Checking if the returned vcache is NULL or not is a bit of an indirect
way to check if an error occurred. Just check the return code itself,
to make sure we notice if any kind of error is reported.
Suggested by Chas Williams.
Reviewed-on: http://gerrit.openafs.org/11321 Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit 2edf5c0382385f898a017fd8e0e2429f8b2b3520)
Change-Id: I7e123ab1cf88570a6b18e438e01409ed7804e014
Reviewed-on: http://gerrit.openafs.org/11558 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marc Dionne [Thu, 25 Sep 2014 10:52:12 +0000 (07:52 -0300)]
Linux 3.17: Deal with d_splice_alias errors
In 3.17 the logic in d_splice_alias has changed. Of interest to
us is the fact that it will now return an EIO error if it finds
an existing connected directory for the dentry, where it would
previously have added a new alias for it. As a result the end
user can get EIO errors when accessing any file in a volume
if the volume was first accessed through a different path (ex:
RO path vs RW path).
This commit just restores the old behaviour, adding the directory
alias manually in the error case, which is what older versions
of d_splice_alias used to do.
Reviewed-on: http://gerrit.openafs.org/11492 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit 5815ee92a41cdcf105741d834042a5617dc4c219)
Change-Id: Ie86009ede93255c85fcf640af14c598fe1e42ca9
Reviewed-on: http://gerrit.openafs.org/11550 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marc Dionne [Tue, 9 Sep 2014 13:39:55 +0000 (10:39 -0300)]
Linux 3.17: No more typedef for ctl_table
The typedef has been removed so we need to use the structure
directly.
Note that the API for register_sysctl_table has also changed
with 3.17, but it reverted back to a form that existed
before and the configure tests handle it correctly.
Reviewed-on: http://gerrit.openafs.org/11455 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit 6a23ca5b6e8bcaf881be7a4c50bfba72d001e6cd)
Change-Id: Ifb8fc0b9b01d2578c65407608f0e1b3f3b254459
Reviewed-on: http://gerrit.openafs.org/11549 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Jeffrey Altman [Mon, 13 Oct 2014 21:48:05 +0000 (17:48 -0400)]
aklog 1.6: make krb5_524 non-fatal for native K5 tokens
The krb5_524_conv_principal() function should fail whenever the Kerberos
v5 principal cannot safely be mapped onto a Kerberos v4 principal, and
does fail on some Kerberos v5 principals used in real-world AFS
deployments.
Prior to this patchset a failure was treated as a fatal error that
in turn prevents an AFS token from being generated or set into the
cache manager.
The krb5_524_conv_principal() function as applied to AFS tokens is
just a local guess. How the username in the token is interpreted by
the AFS server is up to the server.
krb5_524_conv_principal() is only used for Krb5 native tokens. For Krb4
tokens the krb5_524_convert_creds() function is used to obtain both the
Kerberos v4 ticket and the converted names from the KDC. Many
organizations used the krb524d service to perform name translation. When
the krb524d service is used, the name translation is performed by the KDC,
so there is no local call to krb5_524_conv_principal() which might fail.
As a result, disallowing the use of a native Krb5 token due to a failed
local name translation is a needless loss of functionality; the local name
translation is not an essential part of obtaining a token.
This patchset modifies the behavior such that krb5_524_conv_principal()
errors are non-fatal.
1. If -noprdb is not specified the error message is generated
and a NULL username is used.
2. If the username is NULL the prdb lookup is disabled.
3. If the username is NULL the informational messages do not
include a username.
4. If the username is NULL the username info provided to the
cache manager in the token description is the nul string.
This patchset is an openafs-stable-1_6_x specific version of
the patch. The master version was submitted to
http://gerrit.openafs.org/#change,11542
Credit to Ben Kaduk for assistance with the wording of this commit
message.
Change-Id: If12ae69394321fa7b7a182c9db95716bc66e489c
Reviewed-on: http://gerrit.openafs.org/11538 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Thu, 30 Oct 2014 20:07:41 +0000 (16:07 -0400)]
Separate helper for shutdown module check
If a client was running during the upgrade from a sysvinit version
of the package, stopping it with the systemd unit file will not
necessarily have run the precheck script sufficiently recently to
fill in the KMOD variable with openafs, so that the shut-down client
would leave the kernel module loaded. This causes great badness
when attempting to start the client again.
We do not want to reuse the precheck script during shutdown, as it
has conditionals on things like "not already running" which are not
appropriate there, so use a separate helper script for shutdown.
Always unload a module if it's present (unless loading is disabled),
to reduce the risk that subsequent starts will have trouble.
Benjamin Kaduk [Thu, 23 Oct 2014 03:57:18 +0000 (23:57 -0400)]
Pull patches from gerrit for realpath() issues
realpath() insists on having a sufficiently large buffer passed
in; it will stomp on all the memory and cause an application crash
if the provided allocation is too small.
Stephan Wiesand [Wed, 8 Oct 2014 14:47:13 +0000 (16:47 +0200)]
Update NEWS for 1.6.10
Add the change number of the late aklog fix. Also state that we
support Linux clients up to 3.16 only, since we already know that
3.17 needs a few tweaks, probably to ship with 1.6.10.1 .
Anders Kaseorg [Tue, 30 Sep 2014 17:52:31 +0000 (13:52 -0400)]
aklog: Fix segfault on aklog -path
Commit 2fac53522e7ef5b3a376e191bffdc1f6784e6995 “aklog: Fix improper
use of readlink” inadvertently changed the meaning of int link from a
boolean flag (length > 0) to just a length. This caused ‘aklog -path
(anything)’ to segfault.
Update the type of link and the condition of the while loop to account
for this change.
FIXES 131930
Reviewed-on: http://gerrit.openafs.org/11517 Reviewed-by: Anders Kaseorg <andersk@mit.edu> Tested-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit fbea3265b3bc042b97be17229839ccf7d11a0bf9)
Change-Id: I6eb0126c574665507be923102c3fa812c3716352
Reviewed-on: http://gerrit.openafs.org/11530 Tested-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Ben Kaduk [Fri, 18 Jul 2014 19:19:24 +0000 (15:19 -0400)]
FBSD: adhere to gop_lookupname() semantics
The current semantics are that gop_lookupname() returns an unlocked
vnode; the previous code was written to a different semantic that
a locked vnode should be returned.
This makes a disk cache more likely to work on FreeBSD, but such
configurations remain not very tested.
Reviewed-on: http://gerrit.openafs.org/11317 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit 774d77e056515ae3e87c8f0be8e133c3cdb36bbb)
Garrett Wollman [Wed, 13 Aug 2014 06:32:06 +0000 (02:32 -0400)]
viced: time_t might not be long
Fix a couple of printf format errors that bite on FreeBSD 10 for i386.
Since time_t might be an int, it can't be printed with a long format.
Since time_t might be a long in general, cast to it to long when
printing.
Reviewed-on: http://gerrit.openafs.org/11385 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 9dd67783bb2bd9ef8a972a1aac47b1925069a655)
Change-Id: Icda432863a36169857a20300ab936a1a72de7891
Reviewed-on: http://gerrit.openafs.org/11404 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Garrett Wollman [Wed, 13 Aug 2014 06:20:02 +0000 (02:20 -0400)]
afsd: correct printf format mismatch in debugging printf
On platforms where size_t is unsigned int, the type of
cacheFiles * sizeof(AFSD_INO_T) is not an unsigned long as the format
string requires. Casting cacheFiles to unsigned long ensures that the
result is at least unsigned long, although it will still be wrong if
any architecture makes size_t be long long. Fixes build for FreeBSD
10 on i386.
Reviewed-on: http://gerrit.openafs.org/11384 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit f02beb8d644ec2a52bf21737a040321905a39e20)
Change-Id: I1e874f7f049e2fdfdfbe9e6413d421a5e1a5b249
Reviewed-on: http://gerrit.openafs.org/11403 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Thu, 6 Feb 2014 21:22:49 +0000 (16:22 -0500)]
pointers are not castable to unsigned int
When printing a pointer's value for debugging purposes, use the
dedicated printf format specifier for pointers instead of assuming
that unsigned int ('x') is good enough.
Found by clang on FreeBSD 10.0.
Reviewed-on: http://gerrit.openafs.org/10820 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 758ec15f9391c296f1caa042385148f1a5e0bc84)
Change-Id: Ibe88c38d0563ac125486d0ae7f16882a7989ee98
Reviewed-on: http://gerrit.openafs.org/11402 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
However, several of these files are also compiled from different
directories, such as src/libafsauthent. These need to also have the
relevant include path added, or else we cannot include the relevant
file. So, add the needed include paths.
This commit is 1.6-specific. The build system on the master branch
differs greatly, and these files are not build separately in these
directories.
Change-Id: I502b99b9411aff9660b50f0f4d9a4fb4f6a1106a
Reviewed-on: http://gerrit.openafs.org/11392 Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
projects / packages / o / openafs.git / log