IRIX: Remove pre-65 code Commit d1923139 (irix kill efs and start pruning pre-65) removed all files that defined AFS_SGI64_ENV and earlier, but didn't remove that code that depended on those defines. In addition, there has been code in the tree that checks for AFS_SGI53_ENV since OpenAFS 1.0, but nothing has ever defined Irix 5.3 support in OpenAFS. Remove all of this obsolete code. Change all references to AFS_SGIXX_ENV to AFS_SGI_ENV, and assume AFS_SGI_ENV is defined in all IRIX dirs. Consolidate some of the resulting ifdef logic appropriately. Change-Id: I9dd426296e04801980b805a5e195063762b23189 Reviewed-on: https://gerrit.openafs.org/14230 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
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>
Remove references to SunOS 4 We already removed support for Solaris versions before Solaris 8, in commit e4c2810f ("Remove support for Solaris pre-8"), but there are still some references to SunOS (meaning SunOS 4) in the tree. This is even older than Solaris (aka SunOS 5), so get rid of these. This commit removes most references to SunOS 4 regarding platform support, and a few comments. This also removes a few comments that were just wrong or nonsensical (e.g. CMAPPED in afs.h is used by other platforms; some comments in platform-specific osi_file.c files referenced SunOS for some reason). Change-Id: I0dd3176c582409176fd898f9c9539fbd833ea789 Reviewed-on: https://gerrit.openafs.org/13506 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
libafs: reduce stack space in VNOPS Allocate temporary vrequests to reduce the amount of stack space used. Change-Id: Ic14cc4f657f7c7e97ef396601bd6c8c7f91abe55 Reviewed-on: http://gerrit.openafs.org/11004 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: Throttle byte-range locks warnings per-file Currently, the warning messages about byte-range locks are throttled only according to what the last PID of the locking process was. So, if that same process performs a bunch of byte-range locks a bunch of times, we log this warning message at most once every 2 minutes. However, if we have even just one other process also performing byte-range locks, the throttling can become pretty useless as lastWarnPid ping-pongs back and forth between the two different PIDs. This can happen if multiple unrelated byte-range-lock-using pieces of software just happen to be running on the same machine, or if a piece of software uses byte-range locks after forking into separate processes. To avoid flooding the log in situations like this, keep track of the last warn time in the relevant vcache, so we don't get frequent warnings for byte-range lock requests on the same file. Change-Id: I446cf6a438a75aa741c5543b93f74f4184ee6508 Reviewed-on: http://gerrit.openafs.org/10796 Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs: Include FID in DoLockWarning Provide the FID that is being locked when we warn about byte-range locks, so the user can find what file the process is trying to lock. Change-Id: I56a185c200ac73045ee29b79410e27222c2637f2 Reviewed-on: http://gerrit.openafs.org/10795 Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
afs: Refactor DoLockWarning Change DoLockWarning around a little bit, so subsequent changes are easier to follow. Move lastWarnTime/lastWarnPid so they are only usable within this function. This commit should incur no functional change. Change-Id: I5d25f64e9c088aecee0f0c46b6c401b2caa71ccb Reviewed-on: http://gerrit.openafs.org/10794 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
Apply cast from cfc9b348 to the else clause Clang on FreeBSD complains about format string mismatch as well. Change-Id: I8bf17571807acdcac460efb94d0388b5cac4fa6c Reviewed-on: http://gerrit.openafs.org/9855 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
afs: Avoid tracking file locks for RO volumes Advisory file locks for RO volumes don't make a lot of sense, since there are no possible writes to worry about. The fileserver already does not track these, so don't even bother processing them in the client. Change-Id: Ie2a20d2f7af67799cfb8d30e72aa3e52a1ecc2d5 Reviewed-on: http://gerrit.openafs.org/8197 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
afs: Use common cleanup code for lockctl EINVAL afs_lockctl has common cleanup code in the 'done' label. Use it here, instead of trying to duplicate it. Currently this code path appears to not be dropping the discon lock, which this rectifies. Change-Id: I136a78bc3235454db7e3d69bb79b0061cfcab265 Reviewed-on: http://gerrit.openafs.org/8196 Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Remove support for Solaris pre-8 Remove support for all Solaris and SunOS platforms prior to Solaris 8, since Solaris 7 reached end-of-life in August of 2008. Remove all non-documentation references to sunx86_57 and earlier, sun4x_57 and earlier, and AFS_SUN57_ENV and earlier. References to AFS_SUN58_ENV have been changed to AFS_SUN5_ENV where appropriate, and AFS_SUN5_ENV now implies Solaris 8. AFS_SUN57_64BIT_ENV has been renamed to AFS_SUN5_64BIT_ENV. Change-Id: Ia64ce7da7bfc685fa28a5119c51ec740625456e3 Reviewed-on: http://gerrit.openafs.org/4888 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: BuildBot <buildbot@rampaginggeek.com>
libafs: Get rx conn ref with afs conn ref When we get a reference to an afs_conn with afs_Conn and its variants, we assume we can use the tc->id rx connection without holding any locks. However, if tc->forceConnectFS gets set, the tc->id connection can be destroyed and recreated out from under us. So, to avoid using a possibly freed rx connection, grab a reference to the rx connection at the same time as we grab a reference to the afs conn. And also put back the same reference with afs_PutConn. Change-Id: I442886ee89c6f3fa609e47261317e647e124eecc Reviewed-on: http://gerrit.openafs.org/4625 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementia.org>
afs: Retry unlock after afs_StoreAllSegments HandleFlock calls afs_StoreAllSegments when unlocking an exclusive flock lock. This can drop the write lock on avc, so we must effectively retry the entire lock operation again, since the world may have changed while we were waiting to reacquire the lock on avc. So, retry once all of the lock checks up to that point, to ensure that a lock on the file actually still exists. FIXES 125446 Change-Id: If249b0e761b595062068d7a506be85a3307870e8 Reviewed-on: http://gerrit.openafs.org/4393 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: BuildBot <buildbot@rampaginggeek.com>
afs: Avoid memory leak on recursive write flock When a process requests an exclusive lock on a file on which it already holds an exclusive lock, we basically form a no-op. However, HandleFlock was allocating a new SimpleLocks and attaching it to avc->slocks, without freeing the old SimpleLocks structure. Since we don't need to do anything if we already hold an exclusive lock, just break out of the loop right away when we detect that scenario. Thus we avoid adding a new structure to avc->slocks, and we avoid a memory leak. Change-Id: I27c3df1d7807a0b74cba11d6e4a563df8232932a Reviewed-on: http://gerrit.openafs.org/4395 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-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>
Fix typo: LockType -> lockType Fix simple typo that causes a build error. Change-Id: I85f2899850383746094b7e9bab81dea13c2caeab Reviewed-on: http://gerrit.openafs.org/1908 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
fcntl write lock on readonly file error fix apparently we return EROFS where we should return EBADF. Fix the error the client gets; the RPC is unchanged (and indeed shouldn't be changed) Change-Id: I738f1ee36f39d03bf018c0f91c7de9c8ed8cc9a9 Reviewed-on: http://gerrit.openafs.org/1895 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
flush changes on LOCK_EX unlock right now, flock with LOCK_EX, on unlock, triggers an async store. make it sync, but also, make sure to ask to have any in-memory data sent to us (e.g. VM_StoreAllSegments); unlike Solaris VMSYNC_INVAL, we don't want to invalidate the pages, just get copies written back. LOCK_SH did not, does not and AFAICT should not trigger writes. Change-Id: Id4a72f73b685b5566bb31f6f610f22d806899280 Reviewed-on: http://gerrit.openafs.org/1846 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
Warning fix: cast to expected type Cast argument to match the expected type from the format string. Change-Id: Iddec912ff8a27f46d872fc3101677913adfb537a Reviewed-on: http://gerrit.openafs.org/1812 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
byte-range lock warning should include pid is is the same pid cmdebug would print. just include it in the logged byte-range lock warning. FIXES 126438 Change-Id: Idd83a4c4a56edf43ab257b3a7f08e1bbb774f04a Reviewed-on: http://gerrit.openafs.org/1333 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>