afs: Properly type afs_osi_suser cred arg Currently, afs_osi_suser is declared with a void* argument, even though its only argument is always effectively a afs_ucred_t*. This allows us to call afs_osi_suser with any pointer type without the compiler complaining. Currently, some callers call afs_osi_suser with an incorrectly-typed afs_ucred_t** instead, like so: func(afs_ucred_t **credpp) { afs_ucred_t **acred = *acredpp; /* incorrect assignment */ if (afs_osi_suser(acred)) { /* ... */ } } The actual code in the tree hides this to some degree behind various function calls and layers of indirection (e.g. afs_suser()), but this is effectively what we do. This causes compiler warnings because we are doing incorrect pointer assignments, but the end result works because afs_osi_suser actually uses an afs_ucred_t*. The type confusion makes it very easy to accidentally give the wrong type to afs_osi_suser. This only really matters on SOLARIS, since that is the only platform that actually uses its argument to afs_osi_suser(). To fix all of this, just declare afs_osi_suser as taking an afs_ucred_t*, and fix all of the relevant functions to handle the right type. Change-Id: I1366aedf0f3d7689735a9424c5272233931e3bf2 Reviewed-on: https://gerrit.openafs.org/14085 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Replace <rpc/types.h> with <rx/xdr.h> Our in-tree xdr.h appears to have started life as a concatenation of rpc/types.h and rpc/xdr.h, and should include all the needed functionality. Indeed, commit 7293ddf325b149cae60d3abe7199d08f196bd2b9 even indicates that we expect to be using our in-tree XDR everywhere anyway, so the system XDR is superfluous. Note that afs/sysincludes.h (not afsincludes.h!) already includes rx/xdr.h ifndef AFS_LINUX22_ENV. This change should help systems running glibc 2.26 or newer, which has stopped providing the Sun RPC headers by default. While here remove some duplicate includes of rpc/types.h in the AIX-specific sources. The Solaris NFS translator bits cannot really be changed, since the system headers are used and have tight interdependencies. Update rxgen to not emit rpc/types.h inclusion. [mmeffie: squash 12801 to not emit rpc/types.h from rxgen] Change-Id: I0b195216affa06ab9e259cb0bab0c8286a1636d9 Reviewed-on: https://gerrit.openafs.org/12800 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
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>
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>
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>
afs-suser-consistent-20040728 FIXES 6034 always call afs_suser() with one arg. always take one.
reindent-20030715 FIXES 1774 thanks to nneul@umr.edu for providing a script to do this. gnu indent 2.2.9 options: -npro -nbad -bap -nbc -bbo -br -ce -cdw -brs -ncdb -cp1 -ncs -di2 -ndj -nfc1 -nfca -i4 -lp -npcs -nprs -psl -sc -nsob -ts8 ==================== This delta was composed from multiple commits as part of the CVS->Git migration. The checkin message with each commit was inconsistent. The following are the additional commit messages. ==================== FIXES 1774 fix subst mistake
aix-51-support-20030701 FIXES 1661 make afs work for aix5.1 64 bit. some code cleanup
no-copy-libafs-builds-20021015 make things so file copies from src/libafs don't happen; change how libafs_tree is done
include-afsconfig-before-param-h-20010712 so stuff can be defined in afsconfig.h and included first
afsconfig-and-rcsid-all-around-20010705 convert rest of source to afsconfig; include rcsid macros ==================== This delta was composed from multiple commits as part of the CVS->Git migration. The checkin message with each commit was inconsistent. The following are the additional commit messages. ==================== remove bogus if/define/endif triple ==================== revert non-rcsid and afsconfig portion of patch
Standardize License information
Initial IBM OpenAFS 1.0 tree