With kernel 3.19 struct nameidata becomes opaque. As a result
we cannot rely on STRUCT_NAMEIDATA_HAS_PATH being true for
new kernels.
Rework the conditions here so that STRUCT_NAMEIDATA_HAS_PATH
is only tested when we're using a nameidata structure and
the result matters.
Also modify a configure test to use a nameidata pointer
instead of an actual structure.
Change-Id: I0d71fca44a67570ac3b86151c70f2969dc463f4f
Reviewed-on: http://gerrit.openafs.org/11648
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
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.
Change - Id:I8e8a7e4d3ddd861018de50af1eb7315e730ad529
Change-Id: I4b05aa3d37f01e0e675c420cbf941d682c49c69c
Reviewed-on: http://gerrit.openafs.org/11646
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
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.
Change-Id: I711a5a3a89af6e0055381dfd4474ddca2868bb9c
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>
namelist and idlist are used as IN parameters to ptserver RPCs that
can be issued by unauthenticated clients. Not having a length limit on
them means anyone can use up a ton of ptserver memory by just issuing
those RPCs with a very large length.
So, put a limit on them. PR_MAXLIST is a constant that already exists,
but is small enough to potentially limit real use, so define a new
OpenAFS-internal value for this purpose.
prlist and prentries are returned from the ptserver to clients, so
also limit them in the same way.
Change-Id: Iaf45639bbae401093354adbfb4daa172fe97ede1
Reviewed-on: http://gerrit.openafs.org/9588
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Revert change Ibab1dd189e7fbc41ca01e7ef7479421c056999f5 since uss
should always be safe to build now that its parser symbols are private.
Change-Id: I65fd2008b037dd36a2c7d3ef8817d4d7dda689d7
Reviewed-on: http://gerrit.openafs.org/11653
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Not all sed versions support inplace editing, so do things ourselves.
Also use the sed version found by configure for consistency.
Change-Id: I6194b8dd6b7abf88d0b0fa36ba871e0ba092ce1e
Reviewed-on: http://gerrit.openafs.org/11655
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
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.
Change-Id: Ia27fca3d8052ead45783cb2332c04fe6e99e5d9f
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>
This change fixes numerous places where the return values of various
system calls and standard library routines are not checked. In
particular, this fixes occurrances called out when building on Ubuntu
12.10, with gcc 4.7.2 and eglibc 2.15-0ubuntu20.1, when the possible
failure is one we actually do (or should) care about. This change
does not consider calls where the failure is one we deliberately
choose to ignore.
Change-Id: Id526f5dd7ee48be2604b77a3f00ea1e51b08c21d
Reviewed-on: http://gerrit.openafs.org/9979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Change the volUpdateCounter volume macro name to be
consistent with the volume header name.
Change-Id: I55f55f2c084135e9598c194ed9081fce800ddfe9
Reviewed-on: http://gerrit.openafs.org/11318
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
In e34e0d1 the Debian packaging was removed. Some traces are still left, so
remove those as well.
Change-Id: I1d5c22181f59b2bee42dd34c9f3a043297d294a2
Reviewed-on: http://gerrit.openafs.org/11630
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
DAFS introduced the VSALVAGING error code which is returned when a vnode
cannot be put and a volume has been scheduled to be salvaged.
Update the afsfileprocs to not assert on VSALVAGING, as well as the
VSALVAGE error code.
For example, VPutVnode() and VVnodeWriteToRead() may call
VRequestSalvage_r() which will set the error code to VSALVAGING when a
salvage is requested.
This was noticed during a code inspection.
Change-Id: I6cacfe92347bc5af57defef17b8a2f98c5302f93
Reviewed-on: http://gerrit.openafs.org/10611
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
We clearly do not need to modify the format string; declare it const.
This makes the signature of bozo_Log identical to FSLog, which can
make it easier to use these functions interchangeably.
Change-Id: I89ae9babec2c4e8714019f58fe29dacc7283ae15
Reviewed-on: http://gerrit.openafs.org/10830
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
A valid fssync-debug query <volid> command issued against
a DAFS fileserver will produce the following error messages in FileLog:
SYNC_getCom: error receiving command
FSYNC_com: read failed; dropping connection (cnt=1)
Routine dafs_prolog() issues a tentative FSYNC_VOL_LISTVOLUMES operation
to test for the presence of a DAFS fileserver. If DAFS is detected,
we then call dafssync-debug for the original requested operation.
However, the FSYNC connection for the tentative LISTVOLUMES operation
is never closed. This results in the errors when the command completes.
Close the test connection.
Change-Id: I3c987289408407ba38cd184b7518e72ee1ae9cfc
Reviewed-on: http://gerrit.openafs.org/10476
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The volserver only needs vl_errors.c to be locally generated, not
vlserver.h; in fact, the only consumers of vlserver.h in src/volser/
consume it via afs/vlserver.h.
Instead of reaching over to ../volser for the generated volerr.c,
generate our own local copy, as well as the volser.h generated from
the same error table -- volser.h is included with double-quotes from
the volser sources.
Add the appropriate dependencies on volser.h, and remove the unneeded
dependencies on vlserver.h
Change-Id: Ic6e728fa455419cc8e95dc25c41ed6d6b7d20934
Reviewed-on: http://gerrit.openafs.org/11380
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Consider the following situation:
- A client sends a data packet to a server, using a security class
that requires a challenge
- The server responds with a challenge
- The server is restarted
- The client responds to the challenge with a response
In that situation, the server will process the response, but since the
server was restarted, it has no knowledge of the challenge that was
sent. This generally means that we error the connection, since the
given response is not valid. For rxkad with modern endpoints, this
results in an RXKADPACKETSHORT error, since we interpret the response
as an 'old' response, but it's actually a 'v2' response, so we
interpret the fields in the response as garbage.
This means that the client gets a connection error when the client did
nothing wrong, and there's no way for the client to distinguish this
from a real connection error.
One way to solve this would be to send a Challenge packet to the
client immediately when we detect that this situation has occurred.
However, if we do that, then we never see a data packet with a
checksum, so we fall back to using "old" challenges and responses. And
in general, that would cause the server side to never see a data
packet during the connection negotiation, which is unusual and I am
concerned there may be other niggles of odd behavior that may occur in
that scenario.
So instead, to fix this, make the server ignore responses in this
situation (that is, if we haven't sent out any challenges yet).
Clients will eventually resend the data packet, and we will go through
negotiating the connection security like normal. This should never
cause any new problems, since dropping a challenge packet must be
handled anyway (sometimes packets just get dropped). And a client will
never hang on sending the same response over and over again; clients
only ever send a Response in response to a Challenge packet.
Change-Id: Id3fae425addb2ac8ab60965213b3ebca2e64ba5d
Reviewed-on: http://gerrit.openafs.org/10315
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Rebuild the vldb free chain in addition to the hash chains when
vldb_check is run with the -fix option. Print a FIX: message for
entries added to the free chain.
Example vldb with a broken free chain.
$ vldb_check vldb.broken
address 199364 (offset 0x30b04): Free vlentry not on free chain
address 223192 (offset 0x36818): Free vlentry not on free chain
address 235180 (offset 0x396ec): Free vlentry not on free chain
Scanning 1707 entries for possible repairs
$ vldb_check -fix vldb.broken
Rebuilding 1707 entries
FIX: Putting free entry on the free chain: addr=199364 (offset 0x30b04)
FIX: Putting free entry on the free chain: addr=223192 (offset 0x36818)
FIX: Putting free entry on the free chain: addr=235180 (offset 0x396ec)
Thanks to Kostas Liakakis for reporting this bug.
Change-Id: I57d6b17263ffe5f8818f70f8260a0dce8d85ab1f
Reviewed-on: http://gerrit.openafs.org/11598
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 83f85c9ad6 updated the arguments
we give to configure, since --enable-disconnected and --with-krb5-conf
no longer exist. But, it only updated the configure options for the
userspace configure, and did not update the configure invocation for
building kmod kernel modules.
Update the other configure invocation, so they match and both of them
avoid using outdated configure options.
Change-Id: Ia7fe16a373b5feabd4060bd85fbf9220407082f5
Reviewed-on: http://gerrit.openafs.org/10623
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Attempt to make the parser in uss private so that it doesn't
conflict with other libraries that might leak their parser symbols.
Change-Id: I15b52f55b419b3bbc788ced9660bc41163e2be36
Reviewed-on: http://gerrit.openafs.org/11533
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Fall back to `uname -r` if we aren't probing for kernel sources,
as we still need to know for the rest of the build. While this
could be worked around by explicitly passing the sysname as an
argument, this seems friendlier.
Change-Id: I0db75ba5fc7d1f5ec08d27dfce6858b968b6ce28
Reviewed-on: http://gerrit.openafs.org/11552
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
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.
FIXES 131976
Change-Id: I959f06b5a7a51171e7ed70189620e9d11d52efa2
Reviewed-on: http://gerrit.openafs.org/11644
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Document vldb free list in the vldb format (vldb.txt). The nextIdHash[0]
is on the free chain when the vl entry is free.
Also fix two typos in vldb.txt.
Change-Id: I5d79f55214295e029e7174ef46838afd7dc44bf1
Reviewed-on: http://gerrit.openafs.org/11597
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
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
Change-Id: I3a52f8ccef24f01d04c02db0a4b711405360e323
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>
This was introduced by c04c57c6c5
Change-Id: I2dbc558bf97673074c774b457b53b4a4436b43c1
Reviewed-on: http://gerrit.openafs.org/11624
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The duplicate LIWQ54 tag appears to break newer versions of fop. Since it
isn't referenced by anything, just remove in both instances.
Change-Id: Ie996f0110a9114399a1873ebda1eba4c7696f716
Reviewed-on: http://gerrit.openafs.org/11623
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Assuming the correct values are passed to the xdr functions, no casts
are required. Don't cast simple/struct/union/typedef values. Do cast
array/pointer/vectors, since the relevant xdr wrapper functions expect
char *.
Change-Id: I375c03899576735668c1a0df0af47377223ae97a
Reviewed-on: http://gerrit.openafs.org/10260
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Since prototypes were introduced, xdr functions for typedef foo
expect a foo *, never a foo, even if the underlying type is an array.
print_param (for stubs) got this right, but print_stat (for inter-xdr
calls) did not.
Change-Id: I2b12aaf919fd39e6195d85072fdfd915a1c509f0
Reviewed-on: http://gerrit.openafs.org/10259
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Remove sunrpc compatibility from rxgen. It's not tested, and
rpcgen is available from other sources. This will allow changes to be
made to rxgen without worrying about their impact on rpcgen compatibility.
Removals consist of the -l, -m, and -s switches, the source files
rpc_clntout.c and rpc_svcout.c, and the scan tokens 'program' and
'version'. The -R switch ('R compatibility') is also removed, as it's
a noop.
Change-Id: I960fac14faf072d221b8cb166e9388ab4accfa26
Reviewed-on: http://gerrit.openafs.org/10258
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Refactor auduting to be more like other uses in the code base.
Auditing is now done in a wrapper.
Change-Id: I491aeda31c223e594e3870573871ae10a541d010
Reviewed-on: http://gerrit.openafs.org/11315
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The bosserver creates a pair of symlinks in the client's configuration
directory (/usr/vice/etc) during startup, if the configuration files are
not present:
/usr/vice/etc/CellServDB -> /usr/afs/etc/CellServDB
/usr/vice/etc/ThisCell -> /usr/afs/etc/ThisCell
Due to a bug in the bosserver (which is not fixed on 1.6.x), the
symlinks are only created when the /usr/vice/etc directory already
exists when the bosserver is started.
If the bosserver is started before the client is installed (and the
/usr/vice/etc directory is present), then the packaging script will
write to the symlink CellServDB, overwriting the server's CellServDB with
the contents of the client's CellServDB.local and CellServDB.dist files.
Also, if the client is started after the bosserver creates the symlinks,
the client init script will overwrite the server's CellServDB with the
contents of the client's CellServDB.local and CellServDB.dist files.
Update the packaging and the client init script to delete this symlink
if present, since it is only intended to provide stub configuration
for the client utilities while setting up an initial server. Then,
the updating of the CellServDB will create a local file, instead of
following the symlink and overwriting the server CellServDB.
While here, adjust the indentation whitespace to match the tabs below.
Change-Id: I802fd8d85f73946ca8d8d57e115abb8ae6958196
Reviewed-on: http://gerrit.openafs.org/11601
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Add a couple of comments to help make it explicit when it is okay to
drop afs_xvcache here.
Change-Id: I451ffe80755ea471322e32017f71c0619e6a8e63
Reviewed-on: http://gerrit.openafs.org/7436
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
No implementation of osi_VM_FlushVCache drops and reacquires
afs_xvcache. Doing so would cause problems when afs_FlushVCache calls
osi_VM_FlushVCache, since someone could grab a reference to the vcache
while xvcache is dropped. So, prohibit dropping and reacquiring
afs_xvcache in osi_VM_FlushVCache, and remove the 'slept' argument to
it.
Change-Id: I50b4ee35f54a5277749f44e93b1094e4fb5c93e9
Reviewed-on: http://gerrit.openafs.org/7435
Reviewed-by: Alistair Ferguson <alistair.ferguson@mac.com>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
While studying some code I noticed one of the error messages in
afs_UFSGetVolSlot was prefixed with a different routine name.
More shocking was that git blame fingered me as the last person
to update that line! Indeed I had but I hadn't noticed, nor had
my reviewers, the mis-matched routine name.
Update afs/afs_volume.c to correct routine name.
Change-Id: Id7ee275c9f8991bb71082b9dfcd52c14ead83955
Reviewed-on: http://gerrit.openafs.org/11625
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The only user of AFS_BOZONLOCK_ENV is ppc_darwin_80. This was added
to the param file by commit:
commit 379e3be319
Author: Derrick Brashear <shadow@dementia.org>
Date: Sun Jun 19 00:20:01 2005 +0000
ppc-darwin80-20050618
this is actually a throwaway
It isn't clear to me what the intent was. Darwin clearly isn't
using the Bozon lock around every osi_FlushPages() despite comments
in DARWIN/osi_vnodeops.c about said lock. The possibility of the
Bozon lock being required only ppc_darwin_80 and not ppc_darwin_70 and
ppc_darwin_90 is unlikely.
The comments about the Bozon lock in FBSD/osi_vnodeops.c appears to be
a copy/paste from DARWIN's. Curiously, FBSD doesn't drop the GLOCK()
when osi_FlushPages() calls osi_VM_FlushPages() despite a comment to
the contrary in osi_VM_FlushPages().
Also, instead of editing the alpha_dux param files, just remove them.
Nothing is using them.
Change-Id: Ic1f6aabd82b9bd3686c95fd501a9d72163595421
Reviewed-on: http://gerrit.openafs.org/11108
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
With the "-stayup" release mechanism, clients may have callbacks
to the target of VolClone rather than the target of VolRestore,
so also break callbacks there.
This could cause clients to not be notified of a volume release
done with -stayup and have stale contents.
Change-Id: I94009f4b9382471a3615d2a729e4ee3955a14d44
Reviewed-on: http://gerrit.openafs.org/11619
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The packaging used by official FreeBSD package builds is taken from
the FreeBSD Ports Collection's version control, which is currently
available at https://svnweb.freebsd.org/ports/head/net/openafs/ .
The version of the FreeBSD packaging in the openafs repository
will almost always be out-of-date and is not needed by FreeBSD
(although a small portion of it is currently used by the upstream
FreeBSD packaging), and the actual packaging used by FreeBSD is
easily available, so there is no purpose in maintaining FreeBSD
packaging in the OpenAFS source code repository.
Change-Id: I969cd6933ecd56d6940b8d48da67f50260101571
Reviewed-on: http://gerrit.openafs.org/11622
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
The packaging used for uploads to Debian is maintained on Debian
infrastructure, presently at
http://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git .
The packaging repository for any given Debian openafs source
package will be listed in the Vcs-* fields in the package's
control file.
The version of the Debian packaging in the openafs repository
will almost always be out-of-date and is not used by Debian,
and the actual packaging used by Debian is easily available, so
there is no purpose in maintaining Debian packaging in the OpenAFS
source code repository.
Change-Id: I23011315ece011e32cdddd992c4f8a176e348c67
Reviewed-on: http://gerrit.openafs.org/11621
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Additional gain, when horizontal lists are converted to vertical, is that
each item will be individually version controlled.
Change-Id: I4f12efac9c3d828fafdc7ab8a15740cfb0276538
Reviewed-on: http://gerrit.openafs.org/10014
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
src/volser/volser.p.h defined the values used in VLDB entries. These values
appear (by exhaustive walk of source and by inspection of the volser's rxrpc
api) to be unused by any aspect of the volser and were solely used in
communication with the VLDB.
This patch deletes the misplaced definitions and moves the entire tree to
use the VLF_{RW,RO,BACK}EXISTS and VLSF_* macros from vlserver/vldbint.xg .
No include wrangling was needed; these definitions have always been in scope
but relatively unused.
It also serves to head off a potential problem, which actually motivated the
whole thing: ITSRWREPL was 0x10, which was claimed as VLSF_UUID;
VLSF_RWREPLICA is 0x40, which did not have an ITS equivalent. As ITSRWREPL
was not used, this had never shown itself in operation. There was no ITS
semantic equivalent of VLSF_UUID.
Change-Id: I60426c2635976b9ac34bf820a8aec7a0c8575e20
Reviewed-on: http://gerrit.openafs.org/11331
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Other bits may be asserted even if this is a RO vol.
Change-Id: Iff5256db25502b61b161ec068bd9d2a389f796c7
Reviewed-on: http://gerrit.openafs.org/11617
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
The convention appears to be that ITSRWVOL is the correct flag for
the backup volume.
This reverts commit dcafea769a.
Change-Id: I0f88107d56817515f41a68062053b263683afc94
Reviewed-on: http://gerrit.openafs.org/11341
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, the namei icreate routine creates a fake FdHandle_t for a
SetLinkCount call if we're creating a linktable. In the past this was
probably done because we did not want to open a "real" fdP ,since that
would mean opening another file descriptor, when we already had a file
descriptor (from the creating afs_open call).
This is a problem in the salvager, since it means that we can reach
ihandle code before the ihandle package has been initialized.
Specifically, we can reach icreate -> namei_SetLinkCount -> ih_fdsync.
If we reach ih_fdsync without the ihandle package being initialized,
we assert and dump core.
The ihandle package assumes that we've already initialized it if we
reach any ihandle code, since creating any IHandle_t causes the
package to initialize. But since namei_icreate fakes its own IHandle_t
and FdHandle_t structures, that doesn't happen.
So, to avoid this, stop faking our FdHandle_t and create a real one.
Since we have ih_attachfd, we can create a real FdHandle_t with our
existing file descriptor.
Change-Id: I7a8c1e0ed1ee8e5c8ce2e165b9493811d5d2435d
Reviewed-on: http://gerrit.openafs.org/10213
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
If a principal name is specified to the klog command, it is not
correctly passed in the pw structure. This in turn causes
uninitialized storage to be passed to ka_UserAuthenticateGeneral.
This may either lead to a segmentation fault in klog, or cause
garbage to be passed to the kaserver, leading to garbage in some
log and audit messages. In all cases it is impossible to authenticate
to kaserver with a specified principal name. However, klog
still works correctly when no principal name is specified.
This was introduced by commit 68ce3aa814
which removed lclpw to eliminate a clang warning. However, the clang
warning was misleading in this case, as lclpw was actually used
(confusingly) to indirectly update the pw structure.
Instead of reverting this commit, just update pw->pwname directly.
Change-Id: I565360c6e2f970637422e8b01998d3fc29874ec4
Reviewed-on: http://gerrit.openafs.org/11145
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Clean up and document parseNetRestrictFile_int and ParseNetInfoFile_int
in preparation for some future changes.
Change-Id: I3c8f1823ba1e042fb6ae68c6f0aba58128ef5b81
Reviewed-on: http://gerrit.openafs.org/11312
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
We have previously documented that volumes over 2TB can result in
inaccuracies, but this documentation does not say how the 'partition'
field in "fs listquota" can be inaccurate. It is confusing to see a
usage of 0% for a partition that you know is being used, so try to
briefly explain in what way this field is inaccurate.
The reason we _under_-report the partition usage is that the
fileserver actually gives back PartBlocksAvail and PartMaxBlocks (not
"blocks used" and "blocks total"). So 1TB used and 4TB total is
truncated to 2TB and given back as 2TB free and 2TB total. One we hit
3TB used we'll report it as 1TB free 2TB total (50%) when the actual
usage is 75%.
Change-Id: I0b3de04ef2bd6cd32fdcb1a82cbac58d5d621e5b
Reviewed-on: http://gerrit.openafs.org/11245
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
FindLinkHandle is only referenced inside vol-salvage.c. Also, the
concept of a link table only exists on namei, so the function is only
used for the namei server (and it's only called by other namei-only
code).
So, make the function static, and put it inside the AFS_NAMEI_ENV
ifdef, to be a little more clear about where it can be used. Moving it
inside the AFS_NAMEI_ENV ifdef also avoids a warning if FindLinkHandle
is made static, since otherwise the function would be defined but
unused on non-namei.
This change should incur no difference in behavior; it is just code
reorganization.
Change-Id: Ia8cdadafaf15c724462f600514aa59910619a090
Reviewed-on: http://gerrit.openafs.org/10848
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
