Change AFS*_LINUXnn_ENV to AFS*_LINUX_ENV The minimum Linux kernel that is now supported is linux-2.6.18. The Linux versioned preprocessor macros AFS_*LINUXnn_ENV are no longer needed to distinguish the different levels of Linux and can be merged into just a single set of macros. Perform a global change of _LINUX\d+_ENV to _LINUX_ENV. e.g. AFS_LINUX24_ENV -> AFS_LINUX_ENV AFS_USR_LINUX24_ENV -> AFS_USR_LINUX_ENV AFS_AMD64_LINUX20_ENV -> AFS_AMD64_LINUX_ENV Replace the multiple definitions for the versioned 'AFS*_LINUXnn_ENV' with just single non-version definitions 'AFS*_LINUX_ENV'. Apart from replacing the now-redundant #define directives and tidying up a few comments at the close of a preprocessor block to match their current form, this commit was done using a mechanical change of the variable names and did not reduce preprocessor statements that could now be combined or eliminated. Nor does this commit remove dead code. A follow-up commit (Cleanup AFS_*LINUX_ENV usage) will handle these changes. The updates should have no functional changes. Change-Id: I71e32ca9818d28f82b4f23679868d1b9a62c44bd Reviewed-on: https://gerrit.openafs.org/14387 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
FBSD: Remove pre-8 code Commit 123f0fb1 (config: remove support for old FreeBSD releases) removed our support for FreeBSD releases before FreeBSD 8. However, various areas of code still reference the symbols from those old versions (e.g. AFS_FBSD53_ENV). Remove our ifdef logic for these old symbols, according to the following rules: - In FBSD-specific dirs, assume AFS_FBSD80_ENV is always true (as well as the symbols for earlier versions) - In non-FBSD dirs, convert AFS_FBSD80_ENV to AFS_FBSD_ENV (and do the same for all earlier versions) This allows us to remove code that was specific to older FreeBSD versions, and simplify some ifdef conditionals. Also remove the definitions for AFS_FBSD80_ENV and earlier versions in our existing param.h files. With this commit, the functions afs_start, afs_vop_lock, afs_vop_unlock, and afs_vop_islocked are now always unreferenced, so remove them. Change-Id: Ia5a5ba5ee5b71a86cb4514305e20f1bb34487100 Reviewed-on: https://gerrit.openafs.org/13812 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Tim Creech <tcreech@tcreech.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
FBSD: build fix for FreeBSD 11 r285819 eliminated b_saveaddr from struct buf, while r292373 changed the arguments to VOP_GETPAGES. The approach used by this patch to address these changes was inspired by FreeBSD's nfs and samba clients. Change-Id: Ibcf6b6fde6c86f96aa814af2bca08f1a8b286740 Reviewed-on: https://gerrit.openafs.org/12575 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
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. Change-Id: I0eae0b49a70aee19f3a9ec118b03cfb3a6bd03a3 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>
Port cache manager to NetBSD-5 and NetBSD-current Change-Id: I3d1aa0b22bb8533718f48bd4424743299d5de019 Reviewed-on: http://gerrit.openafs.org/4661 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Updates to the Cache Manager to include NetBSD5 support LKM currently builds and will mount when forced with the entry point manually defined. Contents of /afs can be discovered, but when listing the directory, the system call will not return. Change-Id: I68ba1897b56613bd4ebbe331eea3140c6a963a7d Reviewed-on: http://gerrit.openafs.org/2767 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
death to register in soviet compilers, compiler optimizes you. stop providing dated (and annoying for debugging) register keywords. Change-Id: Ibcac0aa3f353fe531b9be0beedca919fb947bfab Reviewed-on: http://gerrit.openafs.org/2436 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Kill FBSD4X with fire We haven't even pretended to work on the 4.X series for quite some time, and keeping this code around just makes things (slightly) harder to read. AFS_FBSD_ENV is now equivalent to AFS_FBSD50_ENV (though the latter should not be used). Leave the fbsd_4 sysnames in afs_sysnames.h for archival purposes. Change-Id: Ibebda92967ca26c3dd4bf0b2cc6a66ae3a94d0ff Reviewed-on: http://gerrit.openafs.org/1968 Tested-by: Derrick Brashear <shadow@dementia.org> Reviewed-by: Derrick Brashear <shadow@dementia.org>
netbsd: rebase cm at NetBSD 4.0 Rebases the NetBSD client port at OpenBSD, which was originally based on an original NetBSD client port by John Kohl. The platforms remain closely connected. At latest milestone, the port builds as a NetBSD LKM, which was loadable and can mount /afs (but much work remains past this point). Change-Id: I1381a60078794da03a82e7bf6e78127da82d61ee Change-Id: I8e07e82796f6981c99d22ff50dd5b284aad88a9f Reviewed-on: http://gerrit.openafs.org/1874 Tested-by: Derrick Brashear <shadow@dementia.org> Reviewed-by: Derrick Brashear <shadow@dementia.org>
UKERNEL: End the #define u insanity UKERNEL redefines the character 'u' to do a function call. This hurts other kernel developers in all sorts of interesting ways. Remove the definition, and instead explicitly reference the get_user_struct() function in those places that we need to. Change-Id: I64be2eb527c779df0a3d4508444ed68f3634667d Reviewed-on: http://gerrit.openafs.org/1243 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Complete removal of DUX client code With commit cfce015ead18c72ee921f480c73e9247a98838fc (in 2006) all of the files specific to the DUX cache manager were removed. However, the DUX code within general files remained untouched. This patch completes the removal of the (entirely non-functional) DUX client, by removing all cache manager code which is for AFS_DUX*_ENV and AFS_OSF_ENV platforms. It also takes the advantage of this removal to simplify some #ifdef ladders, and indents others (purely because I needed the indentation to work out what on earth was going on!) Change-Id: Icbea5ed3ef94c5e902cdb0d722be85f376c3d296 Reviewed-on: http://gerrit.openafs.org/785 Tested-by: Derrick Brashear <shadow@dementia.org> Reviewed-by: Derrick Brashear <shadow@dementia.org>
Make typedefs of AFS_UCRED and AFS_PROC with renaming Make typedefs of AFS_UCRED and AFS_PROC, with a corresponding name change. The names afs_ucred_t and afs_proc_t are chosen since these appear to be the best available choices. The names cannot actually collide with anything which POSIX might later introduce. For UKERNEL, the preprocessor is used to redirect references. This seems not easily avoidable at present. LICENSE BSD Reviewed-on: http://gerrit.openafs.org/645 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Remove struct from AFS_UCRED instantiations (opaque credential type support) The identifier AFS_UCRED is intended as a preprocessor alias to a possibly-opaque credential type. A platform header will normally rename AFS_UCRED to a platform credential type with #define. This is not intended to change the meaning of AFS_UCRED, but removes the assumption that it is a struct type, which may not be true, depending on the platform and other decisions made by the AFS client port. Reviewed-on: http://gerrit.openafs.org/397 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Ukernel prototypes Prototypes and warning fixes for the cache manager when built as part of libuafs Reviewed-on: http://gerrit.openafs.org/73 Verified-by: Derrick Brashear <shadow@dementia.org> Reviewed-by: Derrick Brashear <shadow@dementia.org>
Remove the RCSID macro The move to git means that we can no longer populate the RCSID macro in the way that it was used with CVS. This patch simply removes the macro from every file, except where it contains information from upstream (and it's in a comment). Reviewed-on: http://gerrit.openafs.org/14 Verified-by: Derrick Brashear <shadow@dementia.org> Reviewed-by: Derrick Brashear <shadow@dementia.org>
discon-allow-saving-vcaches-on-shutdown-20090126 LICENSE IPL10 FIXES 124211 restructure so we can save info necessary to keep dirty changes across offline shutdown
libafs-prototypes-20081129 LICENSE IPL10 add prototypes missing from libafs
macos-rollup-20051013 incorporating STABLE14-macos104-20051005 STABLE14-macos-cleanup-20051006 macos-cleanup-20051006 macos-cleanup-20051007 from the 1.4.x branch, which needed to be forward-ported to work here, sadly.
solars-sparc32-largefile-20051011 readd largefile support for solaris sparc32
freebsd60-20050422 Preliminary FreeBSD 6.0 support. Builds, but unlikely to work.