Forgot to delete an obsolete line
Remove a line from merge conflict
correct last commit

It was the other line which was obsolete...
FBSD: 9.3 has been released, so add config bits and sysname

Change-Id: I453a457d5311dfea04fd7e8173f1296a0db74902
Reviewed-on: http://gerrit.openafs.org/11327
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
FBSD: 10.1 is coming out soon

The 10.1 release cycle is starting in a month, so let's get ahead of
the curve by adding the config bits now.

Change-Id: Ia17e1267dafee5c80d87a6bfc5e423982f83306d
Reviewed-on: http://gerrit.openafs.org/11328
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Move VLOP_RESTORE and VLOP_ADDSITE home

Change-Id: I19c04ea1762eec349b0e9645fa9777e6a6c5263a
Reviewed-on: http://gerrit.openafs.org/11325
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
ptserver: Fix RemoveFromSGEntry hentry memcpy

In this function, hentry is the "previous" continuation entry that we
looked at, and centry is the "current" continuation entry. We keep
track of the previous continuation entry in case we need to update its
'next' pointer, which we do if we free one of the continuation entries
because it is empty after the removal.

So, this memcpy is supposed to copy the current entry to the previous
one, but the arguments are flipped, so we just copy zeroes to centry
(since hentry is initialized to zeroes early on in the function), and
hentry never gets set to anything besides zeroes.

The effect of this is that whenever a ptdb entry has more than one
continuation entry, and we free up any of them after the first one via
RemoveFromSGEntry, the previous continuation entry becomes blanked
(though the 'next' pointer should still be correct). This means the
membership information for that group is not recorded correctly, as it
loses a chunk of the IDs that it is a member of. The reverse mapping
should still be intact (the parent groups have a pointer to the
sub-group), but the group probably doesn't function correctly.

The reason this happened is because of the confusing conversion from
bcopy to memcpy. Most of the instances of bcopy/bcmp/bzero/etc were
converted (correctly) back in commit c5c521af, but the supergroups
implementation was added afterwards, in 8ab7a909, and contained a
bcopy reference. This bcopy was converted to memcpy in 58d5f38b, but
the argument order was not corrected, causing this bug.

To fix this, just flip the first two arguments of the memcpy. Just get
rid of the casts here, too, to match the code in the non-supergroups
RemoveFromEntry and elsewhere.

Change-Id: Ibcbbdcb13ef5c033ea3452555832a0fd3f916efd
Reviewed-on: http://gerrit.openafs.org/11340
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: D Brashear <shadow@your-file-system.com>
LINUX: Drop dentry if lookup returns new file

Background: when an entry is looked up after its parent changes,
afs_linux_dentry_revalidate re-looks-up the entry name in its parent.
If we get an ENOENT back, we d_drop the dentry, and in any other
situation we just d_invalidate it. As discussed in prior commits
997f7fce437787a45ae0584beaae43affbd37cce and
389473032cf0b200c2c39fd5ace108bdc05c9d97, we cannot simply d_drop the
dentry in all cases, because that would cause legitimate directories
to be reported as "deleted" if we just failed to lookup the entry due
to e.g. transient network errors (this causes, among other things,
'getcwd' to fail with ENOENT).

However, this logic has problems if the dentry name still exists, but
points to a different file; the case where 'tvc != vcp' in
afs_linux_dentry_revalidate. If that case happens, and the dentry is
still held open by some process, we will continue to try to reference
the vcache pointed to by the 'old' dcache entry, which is incorrect.

To maybe more clearly illustrate the issue, consider the following
cases:

  $ sleep 9999 < /afs/localcell/testvol.ro/dir1/file1 &
  $ rm -rf /afs/localcell/testvol.rw/dir1
  $ mkdir /afs/localcell/testvol.rw/dir1
  $ vos release testvol
  $ ls -l /afs/localcell/testvol.ro
  ls: cannot access /afs/localcell/testvol.ro/dir1: No such file or directory
  total 0
  d????????? ? ? ? ?            ? dir1

Here, on the last 'ls', afs_linux_dentry_revalidate will afs_lookup
'dir1', and notice that it points to a different file (tvc != vcp),
and will d_invalidate the dentry. But since the file is still held
open, the dentry doesn't go away, and so we are still pointing to the
vcache for the old, deleted 'dir1'. That file doesn't exist anymore on
the fileserver, so we get an ENOENT when actually trying to stat() it
(we get a VNOVNODE from the fileserver, whcih gets translated to an
ENOENT).

A possibly more serious case is when the file is just renamed:

  $ sleep 9999 < /afs/localcell/testvol.ro/dir1/file1 &
  $ mv /afs/localcell/testvol.rw/dir1 /afs/localcell/testvol.rw/dir1.moved
  $ mkdir /afs/localcell/testvol.rw/dir1
  $ touch /afs/localcell/testvol.rw/dir1/file2
  $ vos release testvol
  $ ls -l /afs/localcell/testvol.ro/dir1
  total 0
  -rw-rw-r--. 1 1235 adeason 0 Jul 23 11:09 file1
  $ kill %1
  $ ls -l /afs/localcell/testvol.ro/dir1
  total 0
  -rw-rw-r--. 1 1235 adeason 0 Jul 23 11:10 file2

In this situation, the same code path applies, but the old file still
exists, so we will continue to use it without error. But since we are
still pointing at the old file, of course the results are incorrect.
Once we kill the process holding the file open, the bad dentry finally
goes away and the results are valid again.

To fix this behavior, d_drop the dentry in all cases, except when we
encounter an error preventing the lookup from being done. This ensures
that the dentry is unhashed from the parent directory in the scenarios
above, and so cannot be used for a subsequent lookup.

With this change, the only afs_lookup response that causes a simple
d_invalidate is when we encounter actual errors during the lookup
(such as transient network failures). This is correct, since in those
cases we don't _know_ that the dentry is wrong. For all other cases,
we do know that the dentry is wrong and so we must force it to be
unhashed.

Change-Id: I11a2db1e05d68a755a77815ec5e8d01ac7b36129
Reviewed-on: http://gerrit.openafs.org/11320
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: D Brashear <shadow@your-file-system.com>
libafs: fix error location code in LINUX/osi_export

Fix the missing error location code introduced in commit
40fb2650b783fbafe51aefd3d0af7a6b0536c265
libafs: allocate vattrs in LINUX to reduce stack used

Use location number 104, which is the next in the sequence.

The code in this module is compiled when building the
nfs translator, which is only built under linux when
configure detects it is possible.

Thanks to Andrew Deason for spotting this error.

Change-Id: I00c834bc915fa3be7d5f27467895930e4f62aa76
Reviewed-on: http://gerrit.openafs.org/11351
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
config: Remove deprecated macro from FreeBSD configuration files

The macro STDLIB_HAS_MALLOC_PROTOS was deprecated in commit
daff4006627fc88be85dade3d72aa45e57a6804a.

Change-Id: I9c2129f6f3d5be6a00ef6ddd358967e0fd4f7ec9
Reviewed-on: http://gerrit.openafs.org/11333
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Garrett Wollman <wollman@csail.mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
config: Updates to AFS_HAVE_STATVFS for FreeBSD

Always define AFS_HAVE_STATVFS.  According to the man page, statvfs()
appeared in FreeBSD 5.0.  Additionally, this macro is only used for
userspace which eliminates all disables except for FreeBSD 5.0 which
appears to have just been an oversight when the param file was created
from the 4.x param files.

Also fixes the comment so it reflects the actual choice.

Change-Id: Ibdcd694e9c4a0d0cecccd91a51962af6fb11ff36
Reviewed-on: http://gerrit.openafs.org/11344
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Garrett Wollman <wollman@csail.mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
config: AFS_SHORTGID no longer in use

Remove the AFS_SHORTGID macro from the param header files.  There
are no usages in the rest of the source tree.

Change-Id: I417b6e90fa9a094bfef727134b640964596eceb3
Reviewed-on: http://gerrit.openafs.org/11345
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Garrett Wollman <wollman@csail.mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
config: Refactor the FreeBSD configuration files

Use a common file for most of the platform specific settings.

Change-Id: If95ad44de99fc3320570d53d706fed4d760fe67d
Reviewed-on: http://gerrit.openafs.org/11346
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Garrett Wollman <wollman@csail.mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
libafs: do not allow NULL creds for afs_CreateReq

Do not allow callers to pass a NULL cred to afs_CreateReq.  This
avoids setting the uid of zero in the vrequest when no cred is
passed.  Update callers to pass afs_osi_credp for an anonymous cred
when no cred is available.

Thanks to Andrew Deason for pointing out afs_osi_credp should be
used.

Change-Id: I05f694026ec72ab701160d9920e47c16cda46cd7
Reviewed-on: http://gerrit.openafs.org/11336
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: D Brashear <shadow@your-file-system.com>
libafs: fix vrequest leak in afs_lookup

Fix vrequest leak introduced in commit
9930567bcf9655d3f562b210b2dc4b4a99226691.

Thanks to Andrew Deason for finding this error.

Change-Id: I8fc1391ab43f33c5a8208ff58d1d0641292cf63e
Reviewed-on: http://gerrit.openafs.org/11337
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
libafs: remove stray "-v 2" argument to afs_compile_et

Commit 4e6b7ab904d38d38da1b80a7342bd815668a8c09 separated the
compile_et rules for creating the source and header files using
the new -emit functionality. During review for inclusion in 1.6,
Chas Williams spotted a stray "-v 2" carried over to the rule
for creating the header file, where it doesn't apply. Remove it.

Change-Id: I554354eae0fa018e56fe7b78df69a43e5b5a0b07
Reviewed-on: http://gerrit.openafs.org/11347
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
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.

Change-Id: I12ac77cd271be72af2fa4045c2ebf576847b625e
Reviewed-on: http://gerrit.openafs.org/11317
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: D Brashear <shadow@your-file-system.com>
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.

Change-Id: I61cc7304e9885ddaaebe96db3b12457cb6224420
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>
volinfo: fix documenting comments

As pointed by Andrew deason during review of the 1.6 pullup of
commit ae27283550dab33704f30e18975722e0ed2c5424, psize is not
a parameter of HandleHeaderFiles, and in function HandleSpecialFile
it is of type inout since the value is first read by the += operation.
Fix this, and try to improve the description of psize too.

Change-Id: Ia728b20475f0c44b6104dc954aaa04d5f0f098b5
Reviewed-on: http://gerrit.openafs.org/11319
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>
afs: remove cruft from Solaris afs_freevfs

Remove some unused variables left behind in a previous
refactor of flushing vcaches during afs_shutdown
(commit 80fe111f0044aa7a67215ad92210dc72cb7eb2c0).

Change-Id: Ie0a23cb08fc2946f1c400b8ce8e15ef3dc22ec20
Reviewed-on: http://gerrit.openafs.org/11310
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>