commit 8c307b42f0b0b80bcf69de09031991d2ab776ed9 Author: Stephan Wiesand Date: Thu Jun 17 17:03:16 2021 +0200 Make OpenAFS 1.8.8 Update version strings for the 1.8.8 release Change-Id: I8dc5b309ab17890410825caa329e536f14430d6b Reviewed-on: https://gerrit.openafs.org/14642 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 40a209edeeb984ab20b35cde666dac087bfc5eb0 Author: Stephan Wiesand Date: Thu Jun 17 16:59:56 2021 +0200 Update NEWS for OpenAFS 1.8.8 Finalize the release notes for the 1.8.8 release. Change-Id: I01b4527f708fbc8a733b3aa7754274c94683cb92 Reviewed-on: https://gerrit.openafs.org/14641 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 270bb0998f149485e4ae251fce802d8e80794e7c Author: Stephan Wiesand Date: Thu Jul 15 17:27:10 2021 +0200 Make OpenAFS 1.8.8pre2 Update version strings for the second 1.8.8 prerelease. Change-Id: Ie920e12fde0bc5043273d6dfceceaa1a4705ea3a Reviewed-on: https://gerrit.openafs.org/14699 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Reviewed-by: Stephan Wiesand commit 67e7662714a39d00d77b7689c3457fdcc689f160 Author: Stephan Wiesand Date: Thu Jul 15 21:09:12 2021 +0200 Update NEWS for 1.8.8pre2 Release notes for the second 1.8.8 prerelease. Change-Id: I178d09bfa6c8d24b129cfdf92d4a4fb641518087 Reviewed-on: https://gerrit.openafs.org/14700 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit d15cd1c8cfd431617ff29e9b83e79d82e1fa0d58 Author: Cheyenne Wills Date: Fri Jun 4 10:18:39 2021 -0600 cf: Resolve implicit function definition for memset The autoconf function OPENAFS_HAVE_STRUCT_FIELD can produce a compiler warning for an implicit function definition for memset, however with macOS 11 (Big Sur) the default compiler flags have been changed (-Werror=implicit-function-declaration) so that this is now flagged as an error. As an error this can lead to an incorrect result returned by OPENAFS_HAVE_STRUCT_FIELD. Add an include for to provide the necessary definition for memset. Note, both gcc and clang can produce the implicit function definition warning. Reviewed-on: https://gerrit.openafs.org/14631 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit fd5aa52ef8ce719502f970ab93ffde07d7ed4780) Change-Id: I6829f13ee2fb1698738e95b379928cfea383e348 Reviewed-on: https://gerrit.openafs.org/14668 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 6fbbc7b579dc21b9229c24b1d0d577f7a7bd14fa Author: Andrew Deason Date: Thu Jun 17 17:15:13 2021 -0500 afs: Free pioctlToken in extractPioctlToken Ever since it was introduced in commit 5ec5ad5 (New GetToken pioctl), extractPioctlToken has incorrectly freed pioctlToken by passing '&pioctlToken' to xdr_free (instead of 'pioctlToken'). This causes xdr_ktc_tokenUnion to interpret &pioctlToken (which is a struct ktc_tokenUnion **) as a struct ktc_tokenUnion *. This doesn't cause any corruption or panics, since ktc_tokenUnion doesn't contain any freeable fields unless its at_type is 2 (AFSTOKEN_UNION_KAD). So as long as the bogus 'at_type' from the misinterpreted pointer is not 2, the xdr_free call will just not free anything (and return an error, which we ignore). If the bogus at_type is 2, this would probably cause some memory corruption or other nastiness. For this to happen on 32-bit systems, the value of the 'pioctlToken' pointer itself would need to be 0x2. On 64-bit systems, the top or bottom 32-bits of the pointer would need to be 0x2 (depending on endianness). Those situations seem impossible or very unlikely on most systems, and have never been seen in the wild. FIXES 135238 Reviewed-on: https://gerrit.openafs.org/14651 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 966d5eb58f1f4fb333f263f018429c3a782be344) Change-Id: Ied9b6c42106fa2c4353cccd08e1a6b50190a8504 Reviewed-on: https://gerrit.openafs.org/14667 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5abea9b8b1164f203fe18b5abe7d64ac8cb514eb Author: Michael Meffie Date: Tue Jun 22 20:02:18 2021 -0400 bos: Let xdr allocate rpc output strings The bos client provides fixed sized buffers on the stack for RPC output strings instead of letting xdr allocate output strings. Unfortunately, the fixed sized buffers do not account for the terminating nul char when the output string is the maximum size defined for the bozo RPCs. To avoid potential buffer overflows, and to allow for larger xdr string sizes in the future, convert these to xdr allocated strings. Be sure to always free the xdr allocated strings. The following bozo RPCs have xdr output strings, and are addressed in this commit: BOZO_EnumerateInstance BOZO_GetCellHost BOZO_GetCellName BOZO_GetInstanceInfo BOZO_GetInstanceParm BOZO_GetInstanceStrings BOZO_GetStatus BOZO_ListSUsers Thanks to Cheyenne Wills for pointing out this issue. Reviewed-on: https://gerrit.openafs.org/14650 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit 9ae5b599c7289a6f3ea2b03f2646402da182bb5d) Change-Id: If8b23bbee3db83d65b7c7532fd47f3b5a16c424c Reviewed-on: https://gerrit.openafs.org/14666 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 6484bc7d5aa2dd15ed0fc6dbf7a3ddcf071f7dad Author: Mark Vitale Date: Tue Oct 6 00:02:53 2020 -0400 bos: do not assume fs just if dafs bnode is stopped If dafs is configured but stopped, 'bos salvage -forceDAFS' will fail with: bos: failed to get instance info for 'fs' (no such entity) bos: shutting down 'fs'. bos: can't stop 'fs' (no such entity) This is due to incomplete logic in IsDAFS, introduced with commit e46f10a0a0a930f318833a8a86b10c19744160c1 'bos: Do not assume DAFS just if DAFS bnode exists' Add logic to IsDAFS to work correctly when dafs is configured but stopped. Reviewed-on: https://gerrit.openafs.org/14382 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 48df3ac30210056ec046b48c28aee425b0690f92) Change-Id: Ib55b9e322f529d120f424813c21af133ca2e6acc Reviewed-on: https://gerrit.openafs.org/14665 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 0b55780042d8f856c33ad7a97c65825e3ddee5b7 Author: Michael Meffie Date: Thu Jul 1 20:14:12 2021 -0400 libadmin: Be sure to free the server list in ListCellsRPC Commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc added a check to avoid overrunning a buffer when the cell name returned by RXAFSCB_GetCellServDB is too large for the libadmin buffer, but in that case missed freeing the server list returned in the same rpc. Move the xdr_free() of the server list under the cleanup label so the server list returned by the RPC will always be freed. Thanks to Mark Vitale for finding this bug. Reviewed-on: https://gerrit.openafs.org/14690 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit a5c146116faccc9891ae6d50506cd43d52dadb70) Change-Id: Ic310d8d940588db2c966130a1e7b0a9543dd5e23 Reviewed-on: https://gerrit.openafs.org/14698 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 00423e6920fba66ce4ce7ab746210825830aae5b Author: Michael Meffie Date: Fri May 21 12:38:01 2021 -0400 libadmin: Let xdr allocate rpc output strings In most functions, the libadmin library provides fixed sized buffers for RPC output strings instead of letting xdr allocate the output string. Unfortunately the fixed sized buffers do not account for the terminating nul char when the output string is the maximum length possible for the xdr output strings. To avoid potential buffer overflows, and to allow for larger xdr string sizes in the future, convert these to xdr allocated strings and use safe string functions to copy the results to the application buffers. Fail with an error if the application buffer is too small, instead of overflowing the buffer or truncating results. Thanks to Cheyenne Wills for pointing out this issue. Reviewed-on: https://gerrit.openafs.org/14626 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc) Change-Id: Ia477d68ec62558470ae27544c86c340a7d2b7235 Reviewed-on: https://gerrit.openafs.org/14664 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5b557f37ade19c0eb7073ee39808a16cf9508fd5 Author: Andrew Deason Date: Wed Aug 21 11:48:53 2019 -0500 afs: Update style in afs_tokens.c Fix a few style nits and other minor edits in afs_tokens.c. Mark a few functions 'static' that are not referenced outside of that file. Reviewed-on: https://gerrit.openafs.org/13806 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 1d2a1002bd1bc8d82c05399c06836ede83f9eeea) Change-Id: I85b263674477e63cdc72d4dd9b4f714611b71d7e Reviewed-on: https://gerrit.openafs.org/14663 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit c978f92cbf9306c0b12eec68cd64ebac045c65e6 Author: Stephan Wiesand Date: Tue Jun 30 22:53:33 2020 +0200 Make OpenAFS 1.8.8pre1 Update version strings for the first 1.8.8 prerelease. Change-Id: Ia7468e6ae5ec93a81e13dda55842ec57135c2a03 Reviewed-on: https://gerrit.openafs.org/14264 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit e9cc2c3c71eba2f5a1b1be1f5d4198385b681d5c Author: Stephan Wiesand Date: Fri Feb 19 21:51:15 2021 +0100 Update NEWS for 1.8.8pre1 Release notes for the first 1.8.8 prerelease. Change-Id: I04762b28b3cc5528f31c2b5d8f1d7f906e46f62f Reviewed-on: https://gerrit.openafs.org/14540 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit f0283af65e81a4bc9aa4fa44eb8a4a45c6a0448e Author: Andrew Deason Date: Thu May 27 11:02:01 2021 -0600 afscp: Link against opr/roken/hcrypto Link afscp against libopr, libroken, and libafshcrypto, so afscp can be built again. Reviewed-on: https://gerrit.openafs.org/13656 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 4eeed830fa31b7b8b5487ba619acbc8d30642aaa) Change-Id: I73264df34743dcb6a8f6232267892ee602a76053 Reviewed-on: https://gerrit.openafs.org/14627 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand Tested-by: Stephan Wiesand commit d7900532e3e7897f8030a6ed31abff4ec0d32ebf Author: Mark Vitale Date: Fri Jan 29 01:30:47 2016 -0500 afs: free the Buffers array correctly during shutdown DInit() allocates 'Buffers' with afs_max_buffers = 4*nbuffers worth of buffer structs to allow for run-time expansion. But shutdown_bufferpackage() free 'Buffers' as if it only had nbuffers worth of buffer structs. Correct the size of Buffers passed to afs_osi_Free(). Discovered during Solaris shutdown testing with kmem_flags=x0f. This bug is not Solaris-specific, but it may be symptomless on other platforms. Introduced by commit e7c966354c428a5a5929a3db6a829ee71c8ba2fc 'Flexible client buffer growth'; this only affected cold shutdowns (afsd -shutdown). After commit 2336164d1bf63980419d3a870f908f1f384fdfc0 'afs: Actually free resources during warm shutdown', this bug also affects warm shutdowns (the default when /afs is unmounted). Reviewed-on: https://gerrit.openafs.org/12183 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason (cherry picked from commit d1c944ec167b8845d703a6b6a8d9492751056b98) Change-Id: I612b33a3788d2c9a0c39c5cb22a3473f8e1c01e1 Reviewed-on: https://gerrit.openafs.org/14616 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5cfee79d9a12e67720906cc5a985f7c12064db41 Author: Andrew Deason Date: Sun Jul 21 17:02:34 2019 -0500 afs: Actually free resources during warm shutdown Currently, the shutdown_*() code paths for several subsystems only free the memory for that subsystem for "cold" shutdowns, and not for "warm" shutdowns. This means the memory gets leaked during a "warm" shutdown, since we never free these resources anywhere else. Specifically, this happens in shutdown_bufferpackage, shutdown_AFS, and shutdown_osinet. To avoid these leaks for warm shutdowns, just move the afs_cold_shutdown check around a little, so we free the relevant items in either codepath. Reviewed-on: https://gerrit.openafs.org/13716 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 2336164d1bf63980419d3a870f908f1f384fdfc0) Change-Id: I1d2360ea777b7a7488e599b6e707c98295d8fbdd Reviewed-on: https://gerrit.openafs.org/14615 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 4d03c0cac0abe575ccf1a74078c3338245690462 Author: Mark Vitale Date: Thu Jul 30 16:42:19 2020 -0400 vol: ensure ih package defaults are set for salvage Like most OpenAFS components that work with ihandles, salvager relies on implicit invocation of ih_PkgDefaults via the one-shot in the first call to IH_INIT. Unfortunately, there is at least one reachable code path in salvager that asserts (panics) because vol_io_params has not yet been initialized. This is when salvaging a volume group that does not have a link table; the salvager then panics while attempting to create a new link table: SalvageFileSys -> SalvageFileSys1 -> DoSalvageVolumeGroup -> CreateLinkTable -> IH_CREATE -> namei_icreate -> icreate -> namei_SetLinkCount -> FDH_SYNC -> ih_fdsync -> osi_Assert(0) This path was discovered while testing the non-dafs salvager, but it has also been observed in the field with the DAFS salvageserver. It is possible that there are additional undiscovered paths where vol_io_params are required but uninitialized. Add an implicit ih_PkgDefaults call to icreate to avoid triggering the assert via the code path above. Reviewed-on: https://gerrit.openafs.org/14378 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 9d65bcf8833a826a74fc433777599380cd5b03b9) Change-Id: I8c7fb5acbaf2d84b290ce95e11a7baf0421b920d Reviewed-on: https://gerrit.openafs.org/14614 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 90e54b2a2010b4620b007ea5c8d3a5a7cbc30069 Author: Mark Vitale Date: Fri Oct 9 16:28:15 2020 -0400 vol: move ih_PkgDefaultsSet check inside ih_PkgDefaults Instead of repeating the oneshot check in each caller of ih_PkgDefaults, move the oneshot check into ih_PkgDefaults itself. While here, ensure that ih_PkgDefaults does its work under IH_LOCK. Finally, make ih_PkgDefaultsSet a local static variable (no longer exported). Reviewed-on: https://gerrit.openafs.org/14383 Reviewed-by: Benjamin Kaduk Reviewed-by: Mark Vitale Tested-by: BuildBot (cherry picked from commit 896524963ca1f1d8144a668dafefc8ce88ad440b) Change-Id: I179640df6e0a5fd6b9a97b57cfde6377213e1d14 Reviewed-on: https://gerrit.openafs.org/14613 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 1b794441fe2c7d3c22ca92135035b5ebe826431f Author: Mark Vitale Date: Thu Oct 1 17:13:51 2020 -0400 afsd: remove unused variable afs_shutdown Since the original IBM code import, the variable afs_shutdown has been set but never read. Remove it from the code base. No functional change is incurred by this commit. Reviewed-on: https://gerrit.openafs.org/14380 Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0761bb7c58260985fbbfcf477d597da3c5d64fc5) Change-Id: I35d657fb93b9e6f611d91d5a374899249cec5b88 Reviewed-on: https://gerrit.openafs.org/14612 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 553270ec9e02fc36bdb59924344fa4f470ee20cc Author: Mark Vitale Date: Thu Jan 28 23:38:59 2016 -0500 afs: remove duplicate declaration for afs_shutdown() Somehow there were two. Now there is but one. Reviewed-on: https://gerrit.openafs.org/12181 Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: BuildBot (cherry picked from commit 3e2fe677a2d3b9f76644175f3a59d392872b87f3) Change-Id: I19a2f0ebe2c79fd32800cc388e488fa11fd8f0ce Reviewed-on: https://gerrit.openafs.org/14611 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 7ebe9b70b994ba04d016a5bbf479f30934b7c632 Author: Mark Vitale Date: Thu Jan 28 10:01:13 2016 -0500 afs: afsd -shutdown sets afs_cold_shutdown too soon 'afsd -shutdown' always invokes syscall(AFSOP_SHUTDOWN) with parm2 set to 1 to indicate a "cold" shutdown. (There are no other callers to AFSOP_SHUTDOWN). AFSOP_SHUTDOWN sets global variable afs_cold_shutdown based on the value of parm2. Then it checks to see if AFS is still mounted; if so, we return early with EACCES. However, global afs_cold_shutdown remains set. Therefore, the next successful 'umount' after a "failed" 'afsd -shutdown' will always trigger a "cold" shutdown. This is contrary to the intent of the current implementation, which is to perform a "warm" shutdown upon 'umount' for most platforms. (Exceptions: AIX, OBSD, NBSD always specify a cold shutdown upon 'umount'). This bug would never be noticed on the "cold" exception platforms, but on the "warm" platforms the inconsistency of seeing an unexpected "COLD" shutdown may be confusing and surprising. Make shutdown operation more self-consistent by modifying AFSOP_SHUTDOWN to defer setting of afs_cold_shutdown until after the mount test. Reviewed-on: https://gerrit.openafs.org/12180 Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit c72ec68bcea646aa3e0395ad103afb2ee9ba9cde) Change-Id: I7b40728bcb56c9bb0d86912f140fed315e93bf64 Reviewed-on: https://gerrit.openafs.org/14610 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit de668dbafb55682a209f71cb1d09b5084d0c2af1 Author: Marcio Barbosa Date: Fri Apr 9 15:14:52 2021 +0000 macos: delegate sock_* calls to bkg daemons As part of Apple's ongoing effort to modernize macOS, improve security and reliability, the deprecation of kernel extensions was officially announced at WWDC19. According to this announcement, Kernel programming interfaces will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default. Unfortunately, the following KPIs, extensively used by rx, are included in the list of deprecated KPIs as of macOS 10.15: - sock_receivembuf - sock_close - sock_send - sock_socket - sock_setsockopt - sock_bind To workaround this problem, delegate calls to the functions mentioned above to bkg daemons forked by afsd. Notice that the ifadd_* and ifnet_* functions are also deprecated. Fortunately, these calls can be avoided enabling AFS_USERSPACE_IP_ADDR. Thanks to Andrew Deason for his assistance (ideas, suggestions, documentation, etc). Reviewed-on: https://gerrit.openafs.org/14431 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 70e5c4f6a45854ae3a4241568769279747a8b76f) Conflicts: src/config/afs_args.h Change-Id: I4370c0aa3978f208c763ed43c3cc5567ee74e730 Reviewed-on: https://gerrit.openafs.org/14600 Tested-by: BuildBot Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 7f7ff82c0ab57ee23f19c3ea783ab8ebf23ca045 Author: Andrew Deason Date: Tue Aug 14 15:53:20 2018 -0500 afs: Add AFS_USPC_SHUTDOWN bkg request When AFS_NEW_BKG was added, the kernel module indicated to the relevant afsd process that it's time to shutdown by returning -2. This works on DARWIN, but it's difficult to make this work on all platforms, because of the different way that platforms handle error codes from our pioctls and other AFS syscalls. Specifically, on LINUX, negative error codes are assumed to be negative errno codes, and so returning -2 from the syscall handler means we return -1 to userspace, with errno set to 2 (ENOENT). Getting this to work consistently across platforms is probably more trouble than its worth, so instead of relying on specific return codes from the syscall, just add a new background daemon operation called AFS_USPC_SHUTDOWN, which just tells the background daemon to exit. Reviewed-on: https://gerrit.openafs.org/13281 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 397199a1992d74d8b7e693a2d76df836f7a70080) Change-Id: Ib809a27476f49baef70dcbcc749eed95a4de8d2f Reviewed-on: https://gerrit.openafs.org/14605 Tested-by: BuildBot Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit a80e04a9eb6fb6b3d4cffce0a682931f63efc933 Author: Marcio Barbosa Date: Thu Jan 28 15:49:25 2021 -0800 macos: packaging support for MacOS X 11.0 This commit introduces the new set of changes / files required to successfully create the dmg installer on OS X 11.0 "Big Sur". Reviewed-on: https://gerrit.openafs.org/14430 Reviewed-by: Yadavendra Yadav Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 40c6f3aa5576d7e1ac23caff1ae4ffd69e74dc44) Change-Id: I55bab1631c41fdb636fa84359f2d76d4bfc2b6a1 Reviewed-on: https://gerrit.openafs.org/14598 Tested-by: BuildBot Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 3ea37d57106901e8d4e82537dcee3609f1ef2c1e Author: Marcio Barbosa Date: Thu Jan 28 14:45:10 2021 -0800 macos: add support for MacOS 11.0 This commit introduces the new set of changes / files required to successfully build the OpenAFS source code on OS X 11.0 "Big Sur". While here, refactor the code that checks if the "-Xlinker -kext" system-specific linker option is needed. Reviewed-on: https://gerrit.openafs.org/14429 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit acc955bc17e1a1e10f634e7017c1323954f07b31) Change-Id: Ie5b791c7444612c617eeb3b16e1165510fe9f251 Reviewed-on: https://gerrit.openafs.org/14597 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit c7a8bf889ddacf1935282da14e06abf0e63999f7 Author: Andrew Deason Date: Fri Dec 20 22:09:35 2019 -0600 rx: Indent ifdef maze in rx_kcommon.c Reviewed-on: https://gerrit.openafs.org/13997 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 08c769967ca12f1ac99c736789f1925763d8a115) Change-Id: I75d5ec5c9f75f79817adec3f259e546e79fc3629 Reviewed-on: https://gerrit.openafs.org/14599 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit efac54c67d527fb8a4fa118f53fc55ad75c7d2ff Author: Andrew Deason Date: Fri Dec 20 21:51:18 2019 -0600 afs: Indent ifdef maze in afs_server.c Reviewed-on: https://gerrit.openafs.org/13996 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 2a8db42664cc450c2db097fe19472fe7876203df) Change-Id: Iff5bb059ea7005c4f174401b9daa45f1ae6d092d Reviewed-on: https://gerrit.openafs.org/14604 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 7550806b15b3347c70520b23d5f7f59665e8d4a0 Author: Cheyenne Wills Date: Thu Mar 18 08:28:22 2021 -0600 bozo: Fix the test for bosserver '-cores none' The check for the '-cores none' parameter is incorrect resulting in the parameter to be taken as a directory path. Update the string comparison. Reviewed-on: https://gerrit.openafs.org/14559 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 000fe6b7e6e7bf140c7cca7becc8fb7e8006fec7) Change-Id: I45ac645bb7cdd6f3cd1dfd81d6ccdc9cda4547a8 Reviewed-on: https://gerrit.openafs.org/14589 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 3c19cf40f4016931accc97c555bc5b623b838e96 Author: Mark Vitale Date: Mon Dec 7 14:42:54 2020 -0500 vol: always build vol-bless utility In order to avoid future bit-rot, always build vol-bless. Also add it to the clean rule. However, continue to leave it undistributed and uninstalled by default. Reviewed-on: https://gerrit.openafs.org/14464 Tested-by: BuildBot Reviewed-by: Stephan Wiesand Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 1efa4e49f2dabe2f3a1ef235e21a96ae9d5ff6bf) Change-Id: I62b2f192e2bcb24221c94468e2e72aaa567568d4 Reviewed-on: https://gerrit.openafs.org/14601 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 91a298cc1fb93ffa8766f291b5a1c7ab29ad6f84 Author: Mark Vitale Date: Mon Dec 7 14:40:33 2020 -0500 vol: add vol-bless to .gitignore No functional change is incurred by this commit. Reviewed-on: https://gerrit.openafs.org/14463 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 986ee6a0a70d70f366baeb43670eb367f0525b97) Change-Id: I1819537c8ac26101a81100871f85a6de78408cea Reviewed-on: https://gerrit.openafs.org/14602 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit b6c9bf43988d5945e502be1c9455adc791539a72 Author: Mark Vitale Date: Mon Dec 7 13:13:28 2020 -0500 vol: make vol-bless buildable again The vol-bless utility is not built by default and so is subject to bit-rot. Thus commit 170dbb3ce301329ff127bb23fb588db31439ae8d 'rx: Use opr queues' overlooked vol-bless.c when adding includes for users of struct rx_queue. Add the required #include so vol-bless builds again. Note to maintainers: this change is only required for 1.8.x and later; vol-bless builds fine in 1.6.x and earlier releases. Reviewed-on: https://gerrit.openafs.org/14462 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit e1f20287a4d0cd80c6bfe7309b907fe5a4ac1464) Change-Id: I1f9acb176758bd34b7f63d5ebde54e9af191ad77 Reviewed-on: https://gerrit.openafs.org/14603 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 67385e65cbdb41a8b2895a7fe1d637c7b899ef5c Author: Tim Creech Date: Thu Oct 29 21:29:10 2020 -0400 FBSD: Add support for FreeBSD 12.2 Reviewed-on: https://gerrit.openafs.org/14474 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 96ebee44c322934b9eda1bab5907ee87b03d571f) Change-Id: I95dedbee8b67a2bb05a8bb3614045fa3a49f9a11 Reviewed-on: https://gerrit.openafs.org/14590 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit c58313fc4f1c04e1d3f94f53b966516b2560e4c2 Author: Tim Creech Date: Mon Dec 9 21:13:58 2019 -0500 FBSD: Add support for FreeBSD 12.1 Reviewed-on: https://gerrit.openafs.org/13982 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 71ce9fff8e682a77e17490a54e091656cbf96925) Change-Id: I4214101d314cac6d677a08f760ccf990a4441306 Reviewed-on: https://gerrit.openafs.org/14537 Reviewed-by: Tim Creech Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 4b14b60afbf28f5fcf325ee378a26657f7780254 Author: Marcio Barbosa Date: Tue Aug 18 13:56:26 2020 +0000 bos: suppress unnecessary warn if -noauth Commit d008089a7 (Add interface to select client security objects) consolidated the code that selects the client security objects into a set of new interfaces. Before this commit, the "bos: running unauthenticated" message, which warns the user when an unauthenticated connection is established, used to be suppressed if the -noauth flag was specified. Similarly to commit b3c16324e (ubik: Make ugen_ClientInit honor noAuthFlag), recover the original behavior avoiding warn messages about unauthenticated connections if the -noauth flag is provided. Reviewed-on: https://gerrit.openafs.org/14306 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit d5f0e16ac44475be55a7cc3e2895fc4a3a923ece) Change-Id: Id78494c2a189f2e99e25111200cabde32a4add2b Reviewed-on: https://gerrit.openafs.org/14546 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit c747b15dd2877e6d17e3e6b940ae78c1e1ccd3ea Author: Cheyenne Wills Date: Fri Mar 5 16:31:03 2021 -0700 Linux 5.12: Add user_namespace param to inode ops The Linux commits: "fs: make helpers idmap mount aware" (549c72977) and "attr: handle idmapped mounts" (2f221d6f7) that were merged into Linux-5.12-rc1 cause a build failure when creating the kernel module. Several functions within the inode_operations structure had their signature updated to include a user_namespace parameter. This allows a filesystem to support idmapped mounts. OpenAFS only implements some of the changed functions. LINUX/vnodeops function inode_operation ===================== =============== afs_notify_change setattr afs_linux_getattr getattr afs_linux_create create afs_linux_symlink symlink afs_linux_mkdir mkdir afs_linux_rename rename afs_linux_permission permission Update the autoconf tests to determine if the Linux kernel requires the user_namespace structure for inode_operations functions. If so, define a generic "IOP_TAKES_USER_NAMESPACE" macro. Update the above vnodeops functions to accept a 'struct user_namespace' parameter. When using the 'setattr_prepare' function a user namespace must be now provided. In order to provide compatibility as a non-idmapped mount filesystem the initial user namespace can be used. With OpenAFS, the initial user namespace obtained at kernel module load time is stored in a global variable 'afs_ns'. Update the call to setattr_prepare to pass the user namespace pointed to by the 'afs_ns' global variable. Update calls to setattr to pass the user namespace pointed to by the 'afs_ns' global variable. Notes: The changes introduced with Linux 5.12 allow a filesystem to support idmapped mounts if desired. This commit does not implement support for idmapped mounts, but will continue to use the same initial user namespace as prior to Linux 5.12. With Linux 5.12 the following autoconf checks fail: HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS HAVE_LINUX_SETATTR_PREPARE IOP_CREATE_TAKES_BOOL IOP_GETATTR_TAKES_PATH_STRUCT IOP_MKDIR_TAKES_UMODE_T The new macro 'IOP_TAKES_USER_NAMESPACE' covers the cases where these macros where used. Reviewed-on: https://gerrit.openafs.org/14549 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 1bd68506be3243c5670aaf53798b2e4e715d4c8b) Change-Id: I8cd54042da4e0295f3cf8417c84138bb0458f881 Reviewed-on: https://gerrit.openafs.org/14565 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 5a5d358b02b88d6d2c7a27a75149e35b1de7db38 Author: Cheyenne Wills Date: Mon Mar 8 09:22:04 2021 -0700 Linux: Create wrapper for setattr_prepare Move call to setattr_prepare/inode_change_ok into an osi_compat.h wrapper called 'afs_setattr_prepare'. This moves some of the #if logic out of the mainline code. Reviewed-on: https://gerrit.openafs.org/14548 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 12ae2beeeb172cebdfa24d5ea149f73fd85541f8) Change-Id: I1c7806893daf2404a8b3ac1b5c88ca04e6409226 Reviewed-on: https://gerrit.openafs.org/14564 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit cdec210405afb47ee338bfde9280710b64d7abc6 Author: Andrew Deason Date: Tue Jul 23 13:50:31 2019 -0500 LINUX: Introduce afs_d_path Move our preprocessor logic around d_path into an osi_compat.h wrapper, called afs_d_path. This just makes it a little easier to use d_path, and moves a tiny bit of #ifdef cruft away from real code. Reviewed-on: https://gerrit.openafs.org/13721 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 4c4fb6e36634e5663c8be25acd4a1ac872e4738c) Change-Id: I08763c71006e4ac6f2bf88d8ac71941fc44e6ab8 Reviewed-on: https://gerrit.openafs.org/14563 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 8cdd8ad84006b17bfe243b004f0c4191c7df3af5 Author: Andrew Deason Date: Sun Apr 12 22:28:29 2020 -0500 tests: Skip SIGBUS test on FreeBSD Currently, 'softsig-helper -buserror' causes a SIGBUS on most platforms, but can result in SIGSEGV on FreeBSD by default (at least on 11.3-RELEASE). Skip the test on FreeBSD, until we can provide a more reliable way to generate SIGBUS. Note that when the sysctl machdep.prot_fault_translation is set to 1, 'softsig-helper -buserror' generates a SIGBUS instead of SIGSEGV, suggesting that generating a SIGBUS here is the old 'compat' behavior. When machdep.prot_fault_translation is 0 (the default), the code path in the FreeBSD kernel that dictates whether to send a SIGBUS or SIGSEGV in this situation depends on some autodetection heuristics, and so may produce different results depending on FreeBSD releases or even compiler settings (due to detection of ABI based on some ELF notes in the relevant binary). For some details on this sysctl, see or the FreeBSD source code. In 11.3-RELEASE, the decision to issue a SIGBUS or SIGSEGV can be found around sys/amd64/amd64/trap.c:355. Reviewed-on: https://gerrit.openafs.org/14145 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit df5480057c2994914e22bd14b169dbcd8857485a) Change-Id: Ifd2c17c52a7a9be7a8a09776cf15500fdc9ca62d Reviewed-on: https://gerrit.openafs.org/14536 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 5c1aa944d73e20272fa886e46ba0d4e69c54e8db Author: Andrew Deason Date: Sun Sep 8 16:10:40 2019 -0500 FBSD: Remove MA_* abstractions In FBSD/osi_vnops.c, we have a few abstractions (e.g. MA_VOP_UNLOCK) that used to expand to different things for older FreeBSD versions. Currently, they always expand to the same thing, so just remove the abstractions. While we are changing these calls, also change one instance of MA_VOP_LOCK to vn_lock (instead of VOP_LOCK), since we're not usually supposed to call VOP_LOCK directly, according to the VOP_LOCK(9) manpage. The MA_VOP_LOCK call was added in commit bd707fb7 (freebsd-almost-working-client-20020216), seemingly by mistake. Reviewed-on: https://gerrit.openafs.org/13843 Reviewed-by: Tim Creech Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 7260c7164b9a2199c7b5f83279fa18af16e7d387) Change-Id: I831e798546da97eeba923965c24dd79be14a9b89 Reviewed-on: https://gerrit.openafs.org/14535 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit b03f8b684077c9224fe059abf8c316739096e0cd Author: Tim Creech Date: Fri Dec 13 22:24:57 2019 -0500 FBSD: Build vnode_if.h before libafs objs Currently, if we are building with -j2 or higher, we can easily fail to build some libafs objects because vnode_if.h does not exist yet. vnode_if.h is generated by the FreeBSD build, but none of our objects depend on it, so during parallel builds it may not be available by the time we build, for example, src/external/heimdal/hcrypto/sha256.c. This results in build errors that can look like this: --- sha256-kernel.o --- cc -I. -I.. -I../nfs [...]/src/external/heimdal/hcrypto/sha256.c In file included from [...]/src/external/heimdal/hcrypto/sha256.c:34: In file included from [...]/src/crypto/hcrypto/kernel/config.h:30: In file included from [...]/src/afs/sysincludes.h:354: /usr/src/sys/sys/vnode.h:588:10: fatal error: 'vnode_if.h' file not found #include "vnode_if.h" ^~~~~~~~~~~~ 1 error generated. *** [sha256-kernel.o] Error code 1 make[4]: stopped in [...]/src/libafs/MODLOAD 1 error To avoid this, make all of our libafs objects depends on vnode_if.h. [adeason@dson.org: Expanded commit message.] Reviewed-on: https://gerrit.openafs.org/13983 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0ee53d2fe9341e60f420662749d5ae8c6d4b5f24) Change-Id: I85696c23aeeabf8ebc38c8a9ea320fdcf8141ad9 Reviewed-on: https://gerrit.openafs.org/14534 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 8825b5346f67f2193e770d524d4524b2ff16d84a Author: Tim Creech Date: Sun Mar 5 18:15:58 2017 -0500 FBSD: Remove LOCKPARENT/ISLASTCN lookup logic Currently, our afs_vop_lookup on FBSD tries to only lock 'dvp' for ISDOTDOT requests when LOCKPARENT and ISLASTCN are set. There are a couple of problems with this: - The conditional locking logic involving LOCKPARENT/ISLASTCN is only relevant in very old FreeBSD releases (per-fs checking of these flags for parent locking went away around the FreeBSD 6 era). - Our current logic here is wrong anyway, since we try to lock 'dvp' twice when those flags are set. This was mostly introduced by commit 2f6be821 (FBSD: band-aid vnode locking in lookup), which added a lock/unlock pair for 'dvp' around the lock for 'vp', even though 'dvp' was unlocked several lines earlier. This means that if we hit the relevant code path, we will deadlock, since we try to lock 'dvp' twice. To avoid this, just remove the relevant logic for LOCKPARENT/ISLASTCN, since it is only relevant for old FreeBSD releases that are not supported by us or FreeBSD. Add and rearrange some comments around here to try to more explicitly explain the relevant locking rules. [adeason@dson.org: Commit message rewrite, adding comments, removing old FreeBSD code.] Reviewed-on: https://gerrit.openafs.org/12578 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 17a845c8d44f453b09b21afd59182e616234e872) Change-Id: I105dfe397bb723b0939bb626103d857007e1a7bf Reviewed-on: https://gerrit.openafs.org/14533 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 27268300531101748069741f9deaae5e160616a8 Author: Andrew Deason Date: Sun Apr 12 22:40:14 2020 -0500 FBSD: Remove unused 'wantparent' logic In afs_vop_lookup, the 'wantparent' variable doesn't actually change any logic in the function. In the if() clause that it's used, the value of 'wantparent' is only ever used if cnp->cn_nameiop is RENAME and ISLASTCN is set. But if both of those are true, then the second half of the if() conditional will always be true, so the value of 'wantparent' doesn't matter. So to remove this confusing unused logic, remove the 'wantparent' local var, and all its associated logic. Issue spotted by kaduk@mit.edu. Change-Id: Ia63b88d67d21cc2b81a0c25aa31ea60ab202b0a7 Reviewed-on: https://gerrit.openafs.org/14143 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 7df5c003ed6eb17a693d67ffdfc0556f0c569cc1) Reviewed-on: https://gerrit.openafs.org/14532 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit fa25fb8f53f8a31556b6aa189becef5850cc068a Author: Andrew Deason Date: Sun Aug 18 19:59:50 2019 -0500 FBSD: Add support for FreeBSD 11.3 Reviewed-on: https://gerrit.openafs.org/13792 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 7116de596a8f1d0be3da6eebe92d486f57aefd02) Change-Id: I9bbf3a72041dda4220b63963b6fc9bd8bd2342e8 Reviewed-on: https://gerrit.openafs.org/14531 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit ed6170582ce6fc9fc501349aa98ccc726c04501b Author: Andrew Deason Date: Sun Dec 1 15:39:04 2019 -0600 FBSD: Declare vnops/vfsops static Declare our vnode and vfs operations as static functions, since they are not referenced outside of osi_vfsops.c/osi_vnodeops.c. Shuffle around the definitions in osi_vnodeops.c so that we don't need forward declarations for the functions. Reviewed-on: https://gerrit.openafs.org/13973 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 37c5db3ce767868803135c916b282ff2e541d052) Change-Id: I8817e0e2a02bc4211dc84c0d9f8b418de756120e Reviewed-on: https://gerrit.openafs.org/14530 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 60f3f689c4a0bd152e1c5a2fe660a3c59933491e Author: Andrew Deason Date: Sun Aug 25 23:21:23 2019 -0500 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. Reviewed-on: https://gerrit.openafs.org/13812 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Benjamin Kaduk (cherry picked from commit 847b63af92dd527de31675a0c3c82c9a57e6c4b3) Change-Id: Icaaf660a95084a358d1ddf6fbc63944eff90492f Reviewed-on: https://gerrit.openafs.org/14529 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit dcda95f388426e6bf6ace5f86905f0cf695e8413 Author: Andrew Deason Date: Sun Jun 23 17:48:53 2019 -0500 libafs: Create debug KMODDIR for FBSD debug inst Commit 99418024 (libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst) made it so we create the kmod installation dir before copying our module into it. However, if we build a 'debug' variant of our module, the FreeBSD build process also installs debug symbols in a different directory, ${DESTDIR}${KERN_DEBUGDIR}${KMODDIR}, which may not exist. So do the same thing for that dir too, if --enable-debug-kernel is turned on, so the build still works. To do this, introduce the LIBAFS_REQ_DIRS var, to make it easier to keep track of which dirs we may need to create. Reviewed-on: https://gerrit.openafs.org/13690 Reviewed-by: Benjamin Kaduk Tested-by: Andrew Deason (cherry picked from commit 3bc03e7a5f8ef521e71a30cb8e66e07e2d1b4605) Change-Id: Idee5614e92b99bd1140a3cef971537fb68eec151 Reviewed-on: https://gerrit.openafs.org/14528 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 44d7a30657d8b507e5d382c68b8411b8437c2af2 Author: Andrew Deason Date: Sun Jul 14 17:31:30 2019 -0500 FBSD: Use ucontext for FreeBSD 10+ on amd64 Currently, running any LWP program on recent FreeBSD on amd64 causes (or can cause) a SIGBUS very quickly. This is possibly because our stack management code in LWP only ensures our stacks are 4 or 8-byte aligned in most cases (except DARWIN, which gets 16-byte-aligned stacks), according to the value of STACK_ALIGN. The amd64 ABI mandates that stacks be 16-byte-aligned, and some function calls assume that this is followed, causing a SIGBUS when it is not. FreeBSD on amd64 currently uses process.amd64.s for its savecontext() implementation, which does not do any checking or fixup of the stack alignment. This behavior has been observed on amd64 with FreeBSD 11 specifically, but it probably happens on any FreeBSD release when using clang. FreeBSD switched to clang as the default compiler with FreeBSD 10, so this probably occurs with FreeBSD 10 and newer. We could perhaps try to fix this by changing our stack management code, but we can also avoid most of this nonsense by just using ucontext instead of our custom assembly code. So, do that, by setting USE_UCONTEXT for FreeBSD 10+. Also enable the same 'stackvar'-based workaround in savecontext() as Linux uses, since otherwise 'topstack' appears to always be NULL, and triggers our stack overflow checks. Note that while LWP use is deprecated, as of this commit many small utilities (like 'fs') are still linked to LWP, and so are unusable without a fix like this. Reviewed-on: https://gerrit.openafs.org/13691 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 0a39efee224e8d4431ae79281ca353a7ba6fdce4) Change-Id: I8cb4c20eb32c12310f41e38a3f40b132c919bace Reviewed-on: https://gerrit.openafs.org/14527 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 56ec046f0137b217a55ff40cc66363c36b7e5c21 Author: Andrew Deason Date: Sun Jul 28 15:03:43 2019 -0500 FBSD: Set KERNBUILDDIR for --with-bsd-kernel-build Currently, specifying --with-bsd-kernel-build during configure causes us to set BSD_KERNEL_BUILD, which sets KBLD in MakefileProto.FBSD.in, but nothing ever uses KBLD. This means that when we use --with-bsd-kernel-build, we don't actually build against the configuration for that kernel, which can result in a libafs.ko that cannot be loaded or causes other errors. Specifically, if trying to build for a VIMAGE kernel, the kernel complains when trying to load libafs: [...] kernel: link_elf_obj: symbol in_ifaddrhead undefined [...] kernel: linker_load_file: Unsupported file type The FreeBSD module build system looks for KERNBUILDDIR for an alternative build, which it uses to pull in opt_global.h and other required pieces from the build tree. So just specify KERNBUILDDIR if we have one. At the same time, avoid setting our default value for BSD_KERNEL_BUILD for FBSD when the calculated dir doesn't exist. At least for the default GENERIC kernel on FreeBSD 11.2-RELEASE, there may not be a build dir on the running machine, and so setting BSD_KERNEL_BUILD to the calculated value causes the build to fail when it doesn't exist. Reviewed-on: https://gerrit.openafs.org/13746 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Benjamin Kaduk (cherry picked from commit 8f9c92a888df7b2fd61a3e84aaf1d2c96a8b10dd) Change-Id: I7afc54121ac3a9d81a7a8005d53eb2ed5df489c1 Reviewed-on: https://gerrit.openafs.org/14526 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit be3b02e7dee78f492090e89746167116e4f221fd Author: Tim Creech Date: Sun Mar 5 18:18:01 2017 -0500 FBSD: Call CURVNET_SET/CURVNET_RESTORE for VIMAGE In commit 9703b023 (FBSD: VIMAGE support), we changed a couple of our variable references to their V_* equivalents, to accommodate kernels with VIMAGE turned on. This allows us to build, but causes us to crash whenever we hit that code when VIMAGE is enabled, because the relevant macros reference 'curvnet', which is NULL outside of networking code. What we're supposed to do is to set 'curvnet' before entering networking code by calling 'CURVNET_SET(xxx)', and reset it afterwards by calling 'CURVNET_RESTORE()'. We must make exactly one _RESTORE call for each _SET, and they are supposed to be run at the same level of scope. So to avoid the crashes, make the relevant CURVNET_* calls whenever we look at networking info. We currently only do this in a few places: - In afs_SetServerPrefs, to try to detect if a given server address is in the same network as one our local interfaces (V_in_ifaddrhead) - In rxi_GetIFInfo, for some MTU-related info (V_ifnet) - In rxi_FindIfnet, for some MTU-related info (ifa_ifwithnet) As for what vnet we actually set 'curvnet' to, we could set it to the vnet of the current thread (TD_TO_VNET(curthread)), or we could set it to the vnet of an associated network object (a socket, an interface, etc). Since all of our network-related code goes through Rx, in this commit we set curvnet to the vnet of the Rx socket (rx_socket->so_vnet). Note that VIMAGE is optional in 11-RELEASE, but is turned on by default in 12.0-RELEASE. For more information, see: https://wiki.freebsd.org/VIMAGE/porting-to-vimage [adeason@dson.org: Reworded commit message; moved some code around.] Reviewed-on: https://gerrit.openafs.org/12580 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 1effc3517fdb4b4653d47c59bf67076567209324) Change-Id: I5fd8b2bf204790b1da6427fe72b8743a7aaa4f13 Reviewed-on: https://gerrit.openafs.org/14525 Reviewed-by: Tim Creech Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 642f9776c28933ac2769ef9ea67d316dd1c6cff5 Author: Andrew Deason Date: Sun Jul 14 22:53:39 2019 -0500 FBSD: Remove unnecessary explicit osi_fbsd_alloc AFS_KALLOC is already defined to be osi_fbsd_alloc on FBSD, so this extra #ifdef here is completely unnecessary. Remove it. Do the same for AFS_KFREE/osi_fbsd_free. Reviewed-on: https://gerrit.openafs.org/13708 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit ad1fe5e1a825a3b3f88c04fd84613e4105206443) Change-Id: Ib62b52d040ffd4170a0bb556684244ee1f372401 Reviewed-on: https://gerrit.openafs.org/14524 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 7a5f648e0ac84ecb6321752be5334e16b1b5051e Author: Andrew Deason Date: Sat Jul 20 23:09:27 2019 -0500 FBSD: Give 0 'rootrefs' to vflush on unmount Currently, in afs_unmount, we give vflush a 'rootrefs' arg of 1, indicating that we hold 1 reference on the root vnode. But ever since commit 6eb1088a (freebsd: properly track vcache references), we drop the ref for the root vnode at the beginning of this function. What happens currently in afs_unmount for a normal successful umount is something like this (at least, on FreeBSD 11.2-RELEASE): - We afs_PutVCache the afs_globalVp vcache, reducing its v_usecount and v_holdcnt to 0, and afs_globalVp is set to NULL. - vflush calls afs_root() to get the root vnode, which sees that afs_globalVp is NULL, and so calls afs_GetVCache for the root fid and returns it (and sets afs_globalVp to that vcache), with a v_usecount of 1. - vflush tries to vgonel() all of our vnodes, which calls our afs_vop_reclaim, which calls afs_FlushVCache(). For the root vnode specifically, vflush() sees that v_usecount is nonzero, and so skips calling vgonel() at first, but later calls vgone() on it specifically because we gave a nonzero 'rootrefs'. The resulting afs_FlushVCache() for the root vnode fails, because the root vnode's v_usecount is still 1. Since a failure from afs_vop_reclaim would cause a panic, we just log a warning and try to continue on anyway. - vflush() calls vrele() on the root vnode, right before returning. All of this allows the unmount to proceed, but this means that most of afs_FlushVCache() doesn't actually run for the root vcache, and it means we always log a warning like this on unmount: afs_vop_reclaim: afs_FlushVCache failed code 16 [...] In addition, this means that setting afs_globalVp at the beginning of afs_unmount() is largely pointless, since it gets set to a vcache again near the beginning of vflush(). To avoid all of this, stop lying to vflush about how many references to the root vnode we hold, and just say that we hold 0 references. Reviewed-on: https://gerrit.openafs.org/13709 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit d13b647aa392e1d802be1023930a8e1a07fb11ab) Change-Id: I7ca79ee5c10277d6ef94b5f317aa4ba091642ffd Reviewed-on: https://gerrit.openafs.org/14523 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit a4f5adb0cdc8493603f51422501b4a45b9e26c7f Author: Tim Creech Date: Sun Mar 5 18:17:23 2017 -0500 FBSD: Handle F_UNLCK in VOP_ADVLOCK When a_fl->type is F_UNLCK, FreeBSD gives our VOP_ADVLOCK an a_op of F_UNLCK, instead of F_SETLK like we expect. This causes afs_lockctl to return EINVAL, since F_UNLCK isn't a normal fcntl lock op, and so userspace requests to unlock fcntl-style locks always fail. This can be seen, for example, when trying to use sqlite3 to access a database that lives in afs. This F_UNLCK behavior in FreeBSD seems a bit peculiar, but has been around effectively forever (since 4.4BSD-Lite). So just work around it. [adeason@dson.org: minor style adjustments and commit message/comment rewording.] Reviewed-on: https://gerrit.openafs.org/12579 Reviewed-by: Tim Creech Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit f5acf1b1bfe940faf0a6f4bd11c55d6c90f60242) Change-Id: I52d0c513aeabd54019fc6d7bb6c3b542e95b2dee Reviewed-on: https://gerrit.openafs.org/14522 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Reviewed-by: Stephan Wiesand commit 908be3fadb642578f1fb331d229910b386e559c9 Author: Andrew Deason Date: Sun Jun 23 17:48:53 2019 -0500 libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst We rely on bsd.kmod.mk for our actual rules during 'make install', but that tries to install our kernel module into $(DESTDIR)$(KMODDIR), without creating it first. If the user tries to 'make install DESTDIR=/some/path' and that path doesn't exist, we will fail with something like: make DESTDIR=/home/adeason/git/destdir single_instdir_libafs /usr/bin/install -c -T release -o root -g wheel -m 555 libafs.ko /home/adeason/git/destdir/boot/modules/ install: /home/adeason/git/destdir/boot/modules/: No such file or directory *** Error code 71 To avoid this, add a dependency on the 'install' target which causes our target dir to be created. Reviewed-on: https://gerrit.openafs.org/13653 Tested-by: BuildBot Reviewed-by: Tim Creech Reviewed-by: Benjamin Kaduk (cherry picked from commit 99418024276c94da5982d7dad6126a8d53924d7e) Change-Id: I439b7b9514b3ab060c887003e0af19557fd2c812 Reviewed-on: https://gerrit.openafs.org/14521 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 8d0651efeb11b248a2d1b9a00b97c2de9724c3d1 Author: Stephan Wiesand Date: Fri Mar 22 12:46:17 2019 +0100 Add param.h files and sysnames for FreeBSD 11.2 Thanks to Måns Nilsson for filing the bug. Note that this change differs from the proposed patch in the report, in that it doesn't define the 10.4 symbols in the 11.2 param.h files. FIXES 134850 Reviewed-on: https://gerrit.openafs.org/13534 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Stephan Wiesand (cherry picked from commit 2ee35afa339731f6a60f1e5e99ccaf63baa6c891) Change-Id: I6ba8ba41df12f1a5977f5b530aa1353902de5ebe Reviewed-on: https://gerrit.openafs.org/14520 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit b7bddcf63339a15d0e4c5cd0d56b3b44c428ed54 Author: Michael Meffie Date: Tue May 31 16:23:41 2016 -0400 SOLARIS: provide cache manager stats via kstat Provide statistical information via the solaris kstat framework. Data can be examined with the kstat tool or the kstat userspace api. The kstat module is called openafs. Three kstat names are provided. The "param" name provides cache manager parameters as given by the cmdebug -cache program. # kstat -m openafs -n param The "cache" name provides cache manager statistics as given by the xstats plus some additional cache related stats. The "cache" name also provides the libafs kernel module version string and the current local cellname. # kstat -m openafs -n cache The "rx" name provides general rx statistics as given by rxdebug -rxstat. # kstat -m openafs -n rx Reviewed-on: https://gerrit.openafs.org/13170 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 9338cb5fce2e38b864b8f957b6ea4c56c78d20f8) Change-Id: Ic70d766d7a112d673b6c5898da43b3eea11b1065 Reviewed-on: https://gerrit.openafs.org/14518 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 4d768b764dbba492805d9e4a4af8474e1f7e0d2e Author: Mark Vitale Date: Thu Aug 9 17:40:09 2018 -0400 afs: consolidate duplicated wait-for-cache-drain code Consolidate duplicated logic into a new routine afs_MaybeWaitForCacheDrain(). Reviewed-on: https://gerrit.openafs.org/13278 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 23bd776b0140deb596287869872a41de555ba99a) Change-Id: I31b04da2170dcdf795b8a50ea7ab78d964eeebf5 Reviewed-on: https://gerrit.openafs.org/14517 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit afa3802d065375f32876e150588cbce3b88c61e3 Author: Michael Meffie Date: Mon Jun 20 15:29:45 2016 -0400 afs: more cache truncation stats Add counters for cache too full and waiting to drain occurrences. These will be used in later commits to indicate how often the cache truncation is required and how often the cache manager is waiting for cache truncation to complete. Reviewed-on: https://gerrit.openafs.org/13168 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 25792e246362a201743533a970f90dbc77d0ed5c) Change-Id: I659cce58951c869ce40ff47b13aa79ab33cd26aa Reviewed-on: https://gerrit.openafs.org/14516 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit eee6a0cddcd31dafb1c67b3cf909496c232bca09 Author: Mark Vitale Date: Thu Aug 20 16:09:02 2020 -0400 vol: prevent salvage segfault for orphaned vnode with out-of-range parent While salvaging a RW volume, salvager may segfault if it encounters an orphaned directory with a parent vnode that does not exist. For example, if the large vnode index contains a maximum vnode of 2901, any parent vnode encountered that is larger than 2901 will result in an out-of-bounds reference to our vnode essence array, leading to a segfault or undefined behavior. Modify the logic to check for out-of-bounds parent vnodes, and log them rather than segfaulting. Reviewed-on: https://gerrit.openafs.org/14385 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 750628da77bb71e24ed3061431bbb913ff8d5f72) Change-Id: Ib0cabde440d59394704967dd3ab2eb73f07aec22 Reviewed-on: https://gerrit.openafs.org/14515 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 9e608659f67da53213f376623526638bc10743e5 Author: Mark Vitale Date: Fri Apr 20 00:57:28 2018 -0400 rx: prevent leakage of non-cached rx_connections (pthread) The rxi_connectionCache (AFS_PTHREAD_ENV only) allows applications to reuse rx_connection structs. Cached rx_connections are obtained via rx_GetCachedConnection and released via rx_ReleaseCachedConnection. This feature is used most heavily by libadmin and kauth, but there are other users in the tree as well. For instance, ubikclient routines ubik_ClientInit and ubik_ClientDestroy call rx_ReleaseCachedConnections (if AFS_PTHREAD_ENV) when disposing of their rx_connections. Unfortunately, in many cases these rx_connections were obtained via rx_NewConnection, _not_ from the cache via rx_GetCachedConnection. In those cases, rx_ReleaseCachedConnection will not find the rx_connection in the rxi_connectionCache, and thus it returns without doing anything. Therefore, when ubik_ClientInit is passed an existing ubik_client (for re-initialization) that contains rx_connections NOT allocated via rx_GetCachedConnection, those connections are not destroyed, but will be silently leaked. Similarly, ubik_ClientDestroy will leak its rx_connections when it frees the ubik_client struct. For example, the fileserver host package calls ubik_ClientInit (via hpr_Initialize) and ubik_ClientDestroy (via hpr_End) to manage connections to the ptserver. However, these connections were obtained via rx_NewConnection, not rx_GetCachedConnection. If the fileserver has a failed call to the ptserver that sets prfail=1, the next RPC scheduled for that client (in CallPreamble) will refresh the thread's ubik_client (viced_uclient_key) by calling hprEnd -> ubik_ClientDestroy -> rx_ReleaseCachedConnection. The "released" connections will be leaked. This problem exists in all versions of OpenAFS going back to IBM 1.0. Starting with 1.8.x, many components that were formerly LWP-only are now pthreaded and thus susceptible to this leak. It seems difficult and error-prone to identify all possible code paths that may pass a non-cached rx_connection to rx_ReleaseCachedConnection, and convert them to obtain connections via rx_GetCachedConnection. Instead, prevent all existing and future leaks by modifying the connection cache to: - flag all rx_connections it allocates - correctly release any rx_connection it is passed, whether they came from the cache or not. Reviewed-on: https://gerrit.openafs.org/13042 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit bb5397e4c409e3c075ee73d6bf54a3b6eacc0060) Change-Id: Ia48e29a53a83211c1011eba24c16f78f7253d84b Reviewed-on: https://gerrit.openafs.org/14514 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 1e5496856b71dca6cc2fd0e54ea8dea4444e3867 Author: Mark Vitale Date: Mon Apr 30 18:34:28 2018 -0400 rx: fix out-of-range value for RX_CONN_NAT_PING Commit 496fb87372555f6acddd4fd88b03c94c85f48511 ("rx: avoid nat ping until connection is attached") introduced functionality to defer turning on NAT ping for server connections until after reachability had been established for the client. Unfortunately, this feature could never work correctly because it assigned an out-of-range flag value of 256 (0x100) for the u_char flags field. Instead of calling this out as an error, both gcc and Solaris cc elide this flag so that it is never set in rx_SetConnSecondsUntilNatPing(), Furthermore, the test in rxi_ConnClearAttachWait() will always fail; therefore rxi_ScheduleNatKeepAliveEvent is never called after attach wait has ended. Fortunately, this bug is currently moot - not actually exposed in OpenAFS. (It was discovered by inspection). This is because there are currently no rx_connection objects in the tree that have both NAT ping and checkReach (rx_SetCheckReach) enabled. I also searched git history and found no time when this bug could ever have been exposed. This does raise the question of why the original commit was needed; but instead of reverting the original commit, this commit attempts to fix it. To prevent problems if NAT ping and checkReach are ever both enabled for an rx_connection, enlarge the rx_connection flags member so that the RX_CONN_NAT_PING value is no longer out of range. Reviewed-on: https://gerrit.openafs.org/13041 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 55fca11421055d0bcee79f118ea2a035393cc6e5) Change-Id: I9b02ff06d7bf6ba0dfa30ed5ca17ddb89b517987 Reviewed-on: https://gerrit.openafs.org/14513 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 8453eada315a87ce8fa3cbd54abecb94ed99a947 Author: Andrew Deason Date: Wed Dec 23 12:44:35 2020 -0600 afs: Fix XBSD check for VNOVAL va_uid Commit e86eb73e (obsd-vattrs-20040125) introduced an XBSD-specific check to detect some unchanged attributes. But the #ifdef for XBSD for the va_uid section was added in the middle of an HPUX-specific block by mistake. Move this #ifdef one level higher, so it's actually used on BSD platforms. Reviewed-on: https://gerrit.openafs.org/14473 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Tim Creech Reviewed-by: Benjamin Kaduk (cherry picked from commit cd35aa9e2aec16d622177eeea1e1b3ec8aacdd45) Change-Id: I6a840cffc1e3dfc6df1237261aa3a21bb3b73fbc Reviewed-on: https://gerrit.openafs.org/14512 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit ee53dd3bc087a05e22fc4111297a51ddb30013f0 Author: Cheyenne Wills Date: Fri Jan 22 07:57:55 2021 -0700 Linux 5.11: Test 32bit compat with in_compat_syscall Linux 5.11 removed the TIF_IA32 thread flag with commit: x86: Reclaim TIF_IA32 and TIF_X32 (8d71d2bf6efec) The flag TIF_IA32 was being used by openafs to determine if the task was handling a syscall request from a 32 bit process. Building against a Linux 5.11 kernel results in a build failure as TIF_IA32 is undefined. The function 'in_compat_syscall' was introduced in Linux 4.6 as the preferred method to determine if a syscall needed to handle a compatible call (e.g. 32bit application). To resolve the build problem, use 'in_compat_syscall' if present (Linux 4.6 and later) to determine if the syscall needs to handle a compatibility mode call. Add autoconf check for in_compat_syscall. Notes about in_compat_syscall: In Linux 4.6 'in_compat_syscall' was defined for all architectures with a generic return of 'is_compat_task', but allows architecture specific overriding implementations (x86 and sparc). At 4.6 (and later), the function 'is_compat_task' is defined only for the following architectures to return: Arch Returns ======= ============================== arm64 test_thread_flag(TIF_32BIT); mips test_thread_flag(TIF_32BIT_ADDR) parisc test_ti_thread_flag(task_thread_info(t), TIF_32BIT) powerpc is_32bit_task() s390 test_thread_flag(TIF_31BIT) sparc test_thread_flag(TIF_32BIT) If the Linux kernel is not built with compat mode, is_compat_task and in_compat_syscall is set to always return 0 Linux commit that introduced in_compat_syscall: compat: add in_compat_syscall to ask whether we're in a compat syscall (5180e3e24fd3e8e7) Reviewed-on: https://gerrit.openafs.org/14499 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 78ef922612bef5f5fd6904896e84b9d2ea802404) Change-Id: I4eca62f19ae58fd830915feff5098cec2825f099 Reviewed-on: https://gerrit.openafs.org/14511 Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 4ad1057ab8fd206c9fa8d5e3bdde4f1a8417afdb Author: Cheyenne Wills Date: Fri Jan 29 11:32:36 2021 -0700 Linux: Refactor test for 32bit compat Refactor the preprocessor checks for determining the method to test for 32bit compatibility (64bit kernel performing work for a 32bit task) into a common inline function, 'afs_in_compat_syscall' that is defined in LINUX/osi_machdep.h. Update osi_ioctl.c and afs_syscall.c to use afs_in_compat_syscall. Add include afs/sysincludes into osi_machdep.h to ensure linux/compat.h is pulled for the functions called in afs_in_compat_syscall. Reviewed-on: https://gerrit.openafs.org/14500 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 32cc6b0796495e596262d84c428172a511f757c4) Change-Id: I746e5777737d49381c4a74627b79d2a61cbd4f8e Reviewed-on: https://gerrit.openafs.org/14510 Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit aaa7043a154d35838e65bc28473355c452339bcc Author: Andrew Deason Date: Thu Jan 28 16:59:47 2021 -0600 LINUX: Fix includes for fatal_signal_pending test Commit 8b6ae289 (LINUX: Avoid lookup ENOENT on fatal signals) added a configure test for fatal_signal_pending(). However, this check fails incorrectly ever since Linux 4.11, because fatal_signal_pending() was moved from linux/sched.h to linux/sched/signal.h in Linux commit 2a1f062a (sched/headers: Move signal wakeup [...]). Fix this by including linux/sched/signal.h if we have it during the configure test. A false negative on this configure test doesn't break the build, but it disables one of our safeguards preventing incorrect negative dentries at runtime. The function fatal_signal_pending() hasn't changed in quite some time (except for what header it lives in); it was introduced in Linux 2.6.25 via Linux commit f776d12d (Add fatal_signal_pending). So to try to avoid this mistake again in the future, make it so a missing fatal_signal_pending() breaks the build if we're on Linux 2.6.25+. Reviewed-on: https://gerrit.openafs.org/14508 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 0c1465e4f3310daa54f1e799f76237604222666d) Change-Id: I1334c060f8ab5733461ebf7c191dffa7be830021 Reviewed-on: https://gerrit.openafs.org/14509 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 25d6d88dec67b3ab2a04a1f94baf04291fdb63d6 Author: Andrew Deason Date: Thu Sep 19 12:18:08 2019 -0500 rx: Avoid new server calls for big-seq DATA pkts We currently never open our receive window to more than 32 packets. If we received a DATA packet for an unrecognized call with a seq of 33 or more, the packet is almost certainly from a previously-running call that we were restarted during. As described in commit 7b204946 (rx: Avoid lastReceiveTime update for invalid ACKs) and commit "rx: Avoid new server calls for non-DATA packets", clients can get confused when we respond to calls in these situations, so drop the packets instead. Reviewed-on: https://gerrit.openafs.org/13876 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit a36832e2d891caab8644a3b4641c7c94fab4105f) Change-Id: I72f903b81a205bb3e64862da03f9c1c76cc37b75 Reviewed-on: https://gerrit.openafs.org/14507 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5bbbbe37ac7ffece710f55c471a34e5fc89543a8 Author: Mark Vitale Date: Thu Aug 8 18:18:22 2019 -0400 rx: Avoid new server calls for non-DATA packets Normally, a client starts a new Rx call by sending DATA packets for that call to a server, and rxi_ReceiveServerCall on the server creates a new call struct for that call (since we don't recognize it as an existing call). Under certain circumstances, it's possible for a server to see a non-DATA packet as the first packet for a call, and currently rxi_ReceiveServerCall will create a new server call for any packet type. The call cannot actually proceed until the server receives data from the client (and goes through the challenge/response auth handshake, if needed), but usually this is harmless, since the existence of any packets for a particular call channel indicate that the client is trying to run such a call. The server will respond to the client with ACKs to indicate that it is missing the needed DATA packet(s), and the client will send them and the call can proceed. However, if a call is in the middle of running when the server is restarted, the client may be sending ACKs for a pre-existing call that the server doesn't know about. In this case, the server generates ACKs that indicate the server has not received any DATA packets, which may appear to violate the protocol, depending on the prior state of the call (e.g. the server appears to try to move the window backwards). Clients should be able to detect this and kill the call, but many do not. For many OpenAFS releases before commit 7b204946 (rx: Avoid lastReceiveTime update for invalid ACKs), the client will get confused in this situation and will keep the call open forever, never making progress. There isn't any benefit to creating a new server call in these situations, so just ignore non-DATA packets for unrecognized calls, to avoid stalled calls from such clients. Those clients will not get a response from the server, and so the call will eventually die from the normal Rx call timeout. Reviewed-on: https://gerrit.openafs.org/13758 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 3f9a08db86f951df3f6f69f1143f17dd7b43b150) Change-Id: Iaf8ee360f8aa634b5a7728866e41de267389e1f3 Reviewed-on: https://gerrit.openafs.org/14506 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit d5743ef92a92fe298d68ae4095bf4d4515971f7f Author: Andrew Deason Date: Tue Aug 27 22:58:23 2019 -0500 rx: Avoid lastReceiveTime update for invalid ACKs Currently, we ignore ACK packets in a few cases: - If the ACK appears to move the window backwards (if firstPacket is smaller than call->tfirst). - If the ACK appears to have been received out of order (if previousPacket is smaller than call->tprev). - If the ACK packet appears truncated. In all of these cases, we ignore the ACK packet completely in our ACK processing code (rxi_ReceiveAckPacket), but we still process the packet at higher levels (rxi_ReceivePacket). Notably, this means we update call->lastReceiveTime after rxi_ReceiveAckPacket returns, even for ACK packets we haven't really looked at. Normally this does not cause any noticeable problems, because such packets should either never be encountered, or only consist of a small number of packets that are mixed in with valid packets. However, if our peer is a server, and it is restarted in the middle of a call, our peer may exclusively send us packets that fall into the above categories. (This does not happen if our peer is a client, because clients just ignore packets for calls they do not recognize.) For example: Consider a call where a client is sending data to a server, and the server restarts after the client has sent a DATA packet with sequence number 1000. The server may then start responding to the client with ACKs with firstPacket set to 1, since the restarted server has no knowledge of the call's state. In this case, a firstPacket of 1 is well below where our window was, so all of the ACKs from the server are ignored. But we keep updating call->lastReceiveTime for all of these packets, and so the call stays alive forever until an idle-dead or hard-dead timeout activates (if any are set). As another example, consider the case where a client is sending data to a server, and the server receives a full window of packets (say, 16 packets), has not yet passed any data to the application yet, and the server restarts. The restarted server then starts responding to the client with ACKs with firstPacket set to 1, and previousPacket set to 0. We also ignore all of the ACKs from the server in this case, because even though firstPacket looks sane, it looks like previousPacket has gone backwards. We still update call->lastReceiveTime for each ignored ACK we get, keeping the call alive. Before commit 4e71409f (Rx: Reject out of order ACK packets) was introduced in 1.6.0, neither of these issues could occur. That commit introduced the issue specifically if previousPacket goes backwards; that is, if the server restarts before firstPacket moves forwards. Commit 8d359e6d (rx: Remove duplicate out of order ACK check) in 1.8.0 introduced the issue when 'firstPacket' goes backwards, since previously the FIRSTACKOFFSET-based check caused us to ignore those packets without updating call->lastReceiveTime. That is, if the server restarts after firstPacket moves forwards. In this commit, we still ignore packets in the above cases, but we also avoid updating lastReceiveTime when we update such packets, to make sure that we do not keep a call alive solely from receiving these invalid packets. Alternatively, we could change our logic to immediately abort calls where firstPacket moves backwards (since this violates the Rx protocol), or to not ignore some packets where previousPacket goes backwards (since these calls may be recoverable). And we could also skip updating lastReceiveTime for invalid packets of other types. But for now, this commit just avoids updating lastReceiveTime for invalid ACK packets, in order to just try to restore our behavior before 1.6.0, while still retaining the benefits of ignoring out-of-order ACKs. Further changes in this area can potentially be handled separately by future commits. Also increment the spuriousPacketsRead counter for packets that we ignore in this way (which we used to do for some packets before commit 8d359e6d), so we are not entirely silent about ignoring them. Written in collaboration with mvitale@sinenomine.net. Reviewed-on: https://gerrit.openafs.org/13875 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 7b204946010673506e0f74991f59a0865292199c) Change-Id: I8e0299bdeedb005fe49a2d1c4a00a21301fbbb04 Reviewed-on: https://gerrit.openafs.org/14505 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 49975e8b07c340cb675445015f41474dc39cd535 Author: Andrew Deason Date: Wed Aug 28 17:12:53 2019 -0500 rx: Introduce ack_is_valid Take some of our existing logic for ignoring invalid ACK packets and split it out into a separate function, ack_is_valid. This just makes it easier to add more complex logic in here and write longer comments explaining the decisions. Note that the bug mentioned regarding the previousPacket field was introduced in IBM AFS 3.5, and was fixed in OpenAFS in commit bbf92017 (rx: rxi_ReceiveDataPacket do not set rprev on drop), included in OpenAFS 1.6.23. This commit incurs no functional change; it is just code reorganization. Reviewed-on: https://gerrit.openafs.org/13874 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit f6490629e1239c412002f316804c656c9be61400) Change-Id: I5d0ee9b7fc56659e445705a01d5d90141eb8cfe2 Reviewed-on: https://gerrit.openafs.org/14504 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit c32ad5017d48640ea7f6430f844324b3d7fd90b5 Author: Andrew Deason Date: Mon Nov 2 13:52:25 2020 -0600 rx: For AFS_RXERRQ_ENV, retry sendmsg on error When AFS_RXERRQ_ENV is defined, we currently end up doing something like this for our sendmsg abstractions: if (sendmsg(...) < 0) { while (rxi_HandleSocketError(sock)) ; return error; } return success; This means that when sendmsg() returns an error, we process the socket error queue before returning an error. The problem with this is that when we receive an ICMP error on our socket, it creates a pending socket error that is returned for any operation on the socket. So, if we receive an ICMP error after trying to contact any peer, sendmsg() could return an error when trying to send for any other peer. Even though there is no issue preventing us from sending the packet, we'll fail to actually send the packet because sendmsg() returned an error. This effectively causes an extra outgoing packet drop, possibly delaying the related RPC. To avoid this, change Rx to retry the sendmsg call when it returns an error, since the error may be due to an unrelated ICMP error. To avoid needing to implement this retry loop in multiple places, move around our sendmsg code for AFS_RXERRQ_ENV, so that the higher-level function rxi_NetSend performs the retry and checks for socket errors (instead of the lower-level rxi_Sendmsg or osi_NetSend). Also change our functions to process socket errors to be more consistent between kernel and userspace: now we always have rxi_HandleSocketErrors, which runs a loop around the platform-specific osi_HandleSocketError. With this commit, osi_HandleSocketError is now required to be implemented when AFS_RXERRQ_ENV is defined. We hadn't been implementing this for UKERNEL, so just turn off AFS_RXERRQ_ENV for UKERNEL. Thanks to mbarbosa@sinenomine.net for discovering and providing information about the relevant issue. Reviewed-on: https://gerrit.openafs.org/14424 Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 5c9234694543f206174d30e21886286d419fd8df) Change-Id: I1b21ba4d2b98abae240cb683d6061462db028431 Reviewed-on: https://gerrit.openafs.org/14503 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit a6173b39a874d7cce3a826d7b4dce58ee6a48983 Author: Andrew Deason Date: Mon Nov 2 13:16:41 2020 -0600 rx: Save errno in pthread rxi_Sendmsg Currently, our pthread version of rxi_Sendmsg uses 'errno' in some logic if sendmsg fails, but we do so after calling functions that might alter errno (e.g. fflush). To make sure we get the correct errno value, save the value of errno right after sendmsg returns an error. Reorganize this function a bit to help make the logic easier to follow. Reviewed-on: https://gerrit.openafs.org/14423 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit eff7fa4b2eb9a3001dc18dca157ccbd5f19f89b6) Change-Id: Ie761bf8fbf930718d933fdc2d0ad6961b2660607 Reviewed-on: https://gerrit.openafs.org/14502 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 5b6ea9e9bd37d17b1cf29bb8ef377091ffccae69 Author: Andrew Deason Date: Thu Jan 9 12:38:45 2020 -0600 aklog: Make dummy write AIX-specific This weird write() call exists to work around some old AIX-specific bug. The ifdef looks like it is intended to restrict this to pre-5 AIX, but it also turns this on for all non-AIX platforms. Make this area AIX-specific, to avoid this weird write on other platforms that have nothing to do with the relevant workaround. Reviewed-on: https://gerrit.openafs.org/14022 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 6ee2d6de7d87c93c849f3afbe4326906e4c10852) Change-Id: Iaa84f1c1df57f9b0749c2577e496fbf8740e48c1 Reviewed-on: https://gerrit.openafs.org/14483 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 7d7b3f06bb72aa2969b164ff71d61d723628f52c Author: Yadavendra Yadav Date: Wed Aug 28 17:26:41 2019 +0530 aklog: avoid infinite lifetime tokens by default Currently we get tokens for infinite lifetime using aklog impersonate feature. Based on inputs from Ben, this was done for server to server tickets to be valid forever. However on 1.8.x we have other mechanisms that were usable for server-to-server authentication with strong enctypes, so we do not need to provide user level akimpersonate to generate tokens for infinite lifetime. For this we have added new option -token-lifetime , this can take values from 0 to 720 hours. If 0 is specified it means tokens will have infinite lifetime. By default 10 hours will be token lifetime for akimpersonate tokens. Reviewed-on: https://gerrit.openafs.org/13828 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 1de602aaada15df1008140784092c2a76a2613a1) Change-Id: I032431ab1b8b174ac8d80322b688dc2a7285b8fa Reviewed-on: https://gerrit.openafs.org/14482 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 97400f8a8c1b5756f67cf5434a65faa9a5d3d22b Author: Yadavendra Yadav Date: Wed Aug 28 17:04:31 2019 +0530 aklog: use any enctype in get_credv5 We currently always pass DES as the requested enctype to get_credv5_akimpersonate, but this means we will fail to use our service princ if we're using another enctype (say, AES) with rxkad-k5. To allow this to work with any enctype, just don't pass any requested enctypes, and just use the enctype inside the 'entry' returned to us from krb5_kt_get_entry. Remove all of the logic associated with the now-unused "allowed_enctypes" argument. Also remove the logic handling the case where "service_principal" is NULL (since no callers pass a NULL service_principal), to make it easier to take out the allowed_enctypes related code. Reviewed-on: https://gerrit.openafs.org/13827 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 276bd5c7f8a2ec7673d2ad084566203eb2055938) Change-Id: Ia4b2cab3b2cd81214683dc00d7092a302d5af1bd Reviewed-on: https://gerrit.openafs.org/14481 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 93f21573642f01e906f6711bae13006cc708f0d3 Author: Yadavendra Yadav Date: Wed Aug 28 16:43:35 2019 +0530 aklog: retry getting tokens for KRB5_KT_NOTFOUND error If we're creating tokens with -keytab and our AFS service principal is afs@, we'll first try creating tokens with afs/@ and krb5_kt_get_entry will fail with KRB5_KT_NOTFOUND. Since we do not retry for KRB5_KT_NOTFOUND error, we will not get tokens. So in order to get tokens for principal afs@ we should retry for KRB5_KT_NOTFOUND error. Thanks to jpjanosi@us.ibm.com for finding this issue and suggesting a fix. Reviewed-on: https://gerrit.openafs.org/13826 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 7a13bce2513baf5a3a61db94f3d88232241cea5b) Change-Id: I4f4dfb4c1372aef88a938d1b96d012a3f6bb4218 Reviewed-on: https://gerrit.openafs.org/14480 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 26c1720b2c18cdda1807424d96547342248aa64c Author: Yadavendra Yadav Date: Wed Aug 28 16:25:49 2019 +0530 aklog: Use HAVE_ENCODE_KRB5_ENC_TKT_PART for aklog impersonate In get_credv5_akimpersonate we use HAVE_ENCODE_KRB5_ENC_TKT which is not defined, due to this we always return -1 from this routine for non Heimdal case. We have a another define i.e HAVE_ENCODE_KRB5_ENC_TKT_PART which is defined if encode_krb5_enc_tkt_part function is present. In current code encode_krb5_enc_tkt_part is called from krb5_encrypt_tkt_part and krb5_encrypt_tkt_part is called from get_credv5_akimpersonate for non Heimdal case. So we should change HAVE_ENCODE_KRB5_ENC_TKT to HAVE_ENCODE_KRB5_ENC_TKT_PART. Also while we're here, add a declaration for the internal function encode_krb5_ticket, so we can build this newly-enabled code without warnings. Reviewed-on: https://gerrit.openafs.org/13825 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 6559297610de0f71c9050f3582d4d146e0cc1f3c) Change-Id: Ia89cdbf23160c71e5b65b8220e1c1f73f1055064 Reviewed-on: https://gerrit.openafs.org/14479 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit e262f3a22d209b147d56e302634f95ffc37b007b Author: Yadavendra Yadav Date: Sat Aug 10 02:54:38 2019 +0530 aklog: Free client/server princs in get_credv5 Inside get_credv5, client_principal is static so the first time get_credv5 runs we'll allocate memory for it, and on subsequent calls we'll reuse the same value. However, if we call get_credv5_akimpersonate, we'll free client_principal and never change what client_principal points to. If we need to call get_credv5 again (because we need to retry getting creds), we'll reuse the old value for client_principal, but since it points to free memory we'll segfault or cause other problems. To avoid this, change get_credv5 so we allocate the client and server principals on each invocation of get_credv5 and free them before returning from get_credv5. Since we free the client and server principals inside get_credv5, remove freeing the client and server principals inside get_credv5_akimpersonate. Reviewed-on: https://gerrit.openafs.org/13761 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit ab8b28540ef17d67db02d5dbcb7585443c164e45) Change-Id: I818202660be4522bd49bf207c59d202ed8adf88d Reviewed-on: https://gerrit.openafs.org/14478 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 8e98d9c1cad3afef5508dcc16cc04946be43d9b8 Author: Yadavendra Yadav Date: Sat Aug 10 02:41:01 2019 +0530 aklog: free kbr5_creds before returning from rxkad_get_token rxkad_get_ticket allocates 'v5cred' which should be freed when we return from rxkad_get_token. Reviewed-on: https://gerrit.openafs.org/13760 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 130a92214cc0b9a8f4ea24a3dcd3ed04575e3c4e) Change-Id: I02720f37c71ee56b4bd3d79d5f3e06c3ee647c9b Reviewed-on: https://gerrit.openafs.org/14477 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 563f5b2915a4a43b2642dba8287b3d6d36d5b3c8 Author: Andrew Deason Date: Sat Jan 9 12:47:09 2021 -0600 WINNT: Restore missing '#ifdef PC' Commit 339167ef (Remove dead code) meant to remove the '#ifdef notdef' block in here, but we accidentally also removed the subsequent '#ifdef PC'. This file may not be very important, since WINNT still builds with this mistake, but an unbalanced #ifdef is potentially super confusing, so fix it. Reviewed-on: https://gerrit.openafs.org/14487 Tested-by: BuildBot Reviewed-by: Stephan Wiesand Reviewed-by: Benjamin Kaduk (cherry picked from commit 2971dcb3b4da04fff3f4bd9c3d3e3f0ab7a94cae) Change-Id: I273ad30d38d7a41e7ec662994d91e084c24194bb Reviewed-on: https://gerrit.openafs.org/14490 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 734c7650597b461848829f0706b6a5be29e9fbb9 Author: Andrew Deason Date: Wed Jul 10 15:14:28 2019 -0500 Remove dead code There is a perhaps-surprisingly large amount of code disabled behind directives like '#if 0', '#ifdef notdef', and '#ifdef notyet'. At best, this code is clutter, and at worst some of it is confusing/outdated, and/or confusingly nested inside other preprocessor conditionals. Sometimes this disabled code shows up when grepping the tree, and causes a nuisance when refactoring related areas of code. Get rid of all of it. If anyone ever wants this code back, it can always be restored by reverting portions of this commit. Also delete some comments that clearly refer to the disabled code, and in some cases, adjust the adjacent comments to make sense accordingly. This commit doesn't touch any files in src/external/. Reviewed-on: https://gerrit.openafs.org/13683 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 339167ef1fda899655969f4572ff95271dfdb7cf) Change-Id: I440b01de0fdb0ef2602557bf3fa35dcdf9a22cdc Reviewed-on: https://gerrit.openafs.org/14476 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 7e42148ee75ff523cd232658fd3f46945f5920ce Merge: 5004f88 06b800f Author: Benjamin Kaduk Date: Thu Jan 14 14:24:38 2021 -0800 Merge branch 'openafs-stable-1_8_7-branch' into openafs-stable-1_8_7 Record the history of the 1.8.7 emergency patch release. Resolve the nominal conflict in configure.ac due to 1.8.7 bumping the version and openafs-stable-1_8_x removing the LINUX_PKGREL variable. Change-Id: Ifa719bcec3948b2634841fba90e835f9db088dd6 commit 06b800f6f1022fa4b86eb9023b75028f2e2cfeab Author: Benjamin Kaduk Date: Thu Jan 14 13:08:41 2021 -0800 Make OpenAFS 1.8.7 Update version strings for the 1.8.7 emergency patch release. Change-Id: I665bedad864b1c2cbbe55978d6b06e917ed26faa commit f3b5c62660a48f693897d2faa1cecfd1c10307de Author: Benjamin Kaduk Date: Thu Jan 14 13:06:18 2021 -0800 Update NEWS for 1.8.7 Add the release notes for the 1.8.7 emergency patch release. Change-Id: I813f11e4e72c12cb927f66472b099febbf3d899f commit 81a3600bfdcc122d43c75720e83317dcc2a9e6a1 Author: Benjamin Kaduk Date: Thu Jan 14 10:20:59 2021 -0800 Remove overflow check from update_nextCid The rx_nextCid global has been an unsigned type since http://gerrit.openafs.org/11106 (which was actually merged before the refactoring of overflow check to avoid signed integer overflow) and thus there is no need to avoid signed overflow. The per-connection cid has been unsigned since the IBM import. The natural unsigned behavior on overflow of wrapping is the desired behvaior here, so just remove the extra logic and always increment. Reviewed-on: https://gerrit.openafs.org/14496 Reviewed-by: Jeffrey Hutzelman Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13) Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d Reviewed-on: https://gerrit.openafs.org/14497 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Cheyenne Wills (cherry picked from commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8) commit 6f898c4c711d0aff7ea452670164802b5e423c18 Author: Jeffrey Altman Date: Thu Jan 14 09:57:13 2021 -0500 rx: update_nextCid overflow handling is broken The overflow handling in update_nextCid() produces a rx_nextCid value of 0x80000001 which itself is out of the valid range. When used to construct the first call of a new connection the connection id for the call becomes 0x80000002, and all subsequent connections also trigger the overflow handling and thus also receive connection id 0x80000002. If the same connection id is used for multiple connections from the same endpoint the accepting rx peer will be very confused. When authenticated connections are used, the CHALLENGE/RESPONSE will fail because of a mismatch in the connection's callNumber array. If an initiator makes only a single connection to a given rx peer, that connection would succeed, but once multiple connections are initiated all communication from a broken initiator to any rx peer will fail. The incorrect overflow calculation was introduced by 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core"). This change corrects the overflow value to become 1 << RX_CIDSHIFT Reviewed-on: https://gerrit.openafs.org/14492 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 2c0a3901cbfcb231b7b67eb0899a3133516f33c8) Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d Reviewed-on: https://gerrit.openafs.org/14494 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason (cherry picked from commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7) commit 54c56dfa423bac14db117f5ec641ebe0eda705e3 Author: Jeffrey Altman Date: Thu Jan 14 09:41:39 2021 -0500 rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core") introduced the use of RAND_bytes() to generate the initial 'rx_nextCid' but failed to remove the rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT; assignment inherited from IBM/Transarc. At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation overflows the value CID range. This triggers broken overflow logic in update_nextCid(). Reviewed-on: https://gerrit.openafs.org/14491 Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Jeffrey Hutzelman Reviewed-by: Cheyenne Wills Tested-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473) Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8 Reviewed-on: https://gerrit.openafs.org/14493 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk Reviewed-by: Andrew Deason (cherry picked from commit a41fe24be574f35ca852fc3ea9750e370cdb71d0) commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8 Author: Benjamin Kaduk Date: Thu Jan 14 10:20:59 2021 -0800 Remove overflow check from update_nextCid The rx_nextCid global has been an unsigned type since http://gerrit.openafs.org/11106 (which was actually merged before the refactoring of overflow check to avoid signed integer overflow) and thus there is no need to avoid signed overflow. The per-connection cid has been unsigned since the IBM import. The natural unsigned behavior on overflow of wrapping is the desired behvaior here, so just remove the extra logic and always increment. Reviewed-on: https://gerrit.openafs.org/14496 Reviewed-by: Jeffrey Hutzelman Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13) Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d Reviewed-on: https://gerrit.openafs.org/14497 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Cheyenne Wills commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7 Author: Jeffrey Altman Date: Thu Jan 14 09:57:13 2021 -0500 rx: update_nextCid overflow handling is broken The overflow handling in update_nextCid() produces a rx_nextCid value of 0x80000001 which itself is out of the valid range. When used to construct the first call of a new connection the connection id for the call becomes 0x80000002, and all subsequent connections also trigger the overflow handling and thus also receive connection id 0x80000002. If the same connection id is used for multiple connections from the same endpoint the accepting rx peer will be very confused. When authenticated connections are used, the CHALLENGE/RESPONSE will fail because of a mismatch in the connection's callNumber array. If an initiator makes only a single connection to a given rx peer, that connection would succeed, but once multiple connections are initiated all communication from a broken initiator to any rx peer will fail. The incorrect overflow calculation was introduced by 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core"). This change corrects the overflow value to become 1 << RX_CIDSHIFT Reviewed-on: https://gerrit.openafs.org/14492 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 2c0a3901cbfcb231b7b67eb0899a3133516f33c8) Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d Reviewed-on: https://gerrit.openafs.org/14494 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason commit a41fe24be574f35ca852fc3ea9750e370cdb71d0 Author: Jeffrey Altman Date: Thu Jan 14 09:41:39 2021 -0500 rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core") introduced the use of RAND_bytes() to generate the initial 'rx_nextCid' but failed to remove the rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT; assignment inherited from IBM/Transarc. At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation overflows the value CID range. This triggers broken overflow logic in update_nextCid(). Reviewed-on: https://gerrit.openafs.org/14491 Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Jeffrey Hutzelman Reviewed-by: Cheyenne Wills Tested-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473) Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8 Reviewed-on: https://gerrit.openafs.org/14493 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk Reviewed-by: Andrew Deason commit b65b33da4e65e2c981ce264ef4fa4e3e4c94b732 Author: Michael Meffie Date: Mon Aug 17 15:44:55 2020 -0400 vldb_check: Check for volume lock inconsistencies Verify the a lock timestamp is set if, and only if, a lock volume operation flag is also set. When running vldb_check with the -fix option, fix the inconsistent entries by setting the lock timestamp to the current time if a lock flag is set, or by setting the VLOP_DELETE flag if the lock timestamp is set but no lock flags are set. (The VLOP_DELETE flag is the flag set by the 'vos lock command, and is shown in vos output as "delete/misc".) Volume lock fields can be put into an inconsistent state, at least, by interupted vos rename operations, due to bugs in vos rename. When the volume lock timestamp and lock flags are in this inconsistent state, the volume is locked, but that is not indicated by 'vos listvldb'. The volume can be unlocked by issuing 'vos unlock'. Reviewed-on: https://gerrit.openafs.org/14307 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit 4c33820525af510a8a937289005e39d5b6683b19) Change-Id: Ia894139145d92948b2af43bd115792556131cd5a Reviewed-on: https://gerrit.openafs.org/14450 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 37187ba29454cba5a79eebff6251d6ff145907cf Author: Andrew Deason Date: Mon May 18 12:09:38 2020 -0500 auth: Close fd on SetExtendedCellInfo write error Currently, and since OpenAFS 1.0, if write() fails here, we leak the file descriptor. A write() failure should be very unlikely, but close the fd to make sure we avoid the leak. Reviewed-on: https://gerrit.openafs.org/14213 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit c81579dc7b0c0ac6bc34f63384d705a4445c2bbd) Change-Id: I4dd96cca2fd9c01390fb508ab12d507ab1a56c8b Reviewed-on: https://gerrit.openafs.org/14461 Reviewed-by: Benjamin Kaduk Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit b201d2a3a97830d34ea5b76c9c2d5d3adc1a54a6 Author: Andrew Deason Date: Thu Jul 26 15:48:00 2018 -0500 Remove DUX/OSF code Remove code for DUX/OSF platforms. DUX code was removed from the libafs client in commit 392dcf67 ("Complete removal of DUX client code") and the alpha_dux* param files were removed in dc4d9d64 ("afs: Remove AFS_BOZONLOCK_ENV"). This code has always been disabled since those commits, so remove any code referencing AFS_DUX*_ENV, AFS_OSF_ENV, and related symbols. Reviewed-on: https://gerrit.openafs.org/13260 Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 6534b10a4180ec10bceebbc11405718e7969fa21) Change-Id: I632636fe6c5111b60c5b586c346ecc10ccfa8f3c Reviewed-on: https://gerrit.openafs.org/14452 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit c55607d732a65f8acb1dfc6bf93aee0f4409cecf Author: Andrew Deason Date: Mon Oct 26 12:35:32 2020 -0500 LINUX: Return errors in our d_revalidate In our d_revalidate callback (afs_linux_dentry_revalidate), we currently 'goto bad_dentry' when we encounter any error. This can happen if we can't allocate memory or some other internal errors, or if the relevant afs_lookup call fails just due to plain network errors. For any of these cases, we'll treat the dentry as if it's no longer valid, so we'll return '0' and call d_invalidate() on the dentry. However, the behavior of d_invalidate changed, as mentioned in commit afbc199f1 (LINUX: Avoid d_invalidate() during afs_ShakeLooseVCaches()). After a certain point in the Linux kernel, d_invalidate() will also effectively d_drop() the given dentry, unhashing it. This can cause getcwd() calls to fail with ENOENT for those directories (as mentioned in afbc199f1), and can cause bind-mount calls to fail similarly during a small window. To avoid all of this, when we encounter an error that prevents us from checking if the dentry is valid or not, we need to return an error, instead of saying 'yes' or 'no'. So, change afs_linux_dentry_revalidate to jump to the 'done' label when we encounter such errors, and avoid calling d_drop/d_invalidate in such cases. This also lets us remove the 'lookup_good' variable and consolidate some of the related logic. Important note: in older Linux kernels, d_revalidate cannot return errors; callers just interpreted its return value as either 'valid' (non-zero) or 'not valid' (zero). The treatment of negative values as errors was introduced in Linux commit bcdc5e019d9f525a9f181a7de642d3a9c27c7610, which was included in 2.6.19. This is very old, but technically still above our stated requirements for the Linux kernel, so try to handle this case, by jumping to 'bad_dentry' still for those old kernels. Just do this with a version check, since no configure check can detect this (no function signatures changed), and the only Linux versions that are a concern are quite old. Reviewed-on: https://gerrit.openafs.org/14417 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 78e5e1b0e54b31bb08b7578e86a6a2a95770d94c) Change-Id: I9f9e2cd3a10cc8fa30a770cabd6ae9757f412ce5 Reviewed-on: https://gerrit.openafs.org/14451 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit dc5e7825fb166ecdb32fc7b63b4a5316037de652 Author: Mark Vitale Date: Mon Apr 20 14:51:08 2020 -0400 vos: avoid 'half-locked' volume after interrupted 'vos rename' Reported symptoms: If a 'vos rename' is interrupted after it has locked the volume and replaced the VLDB entry, but before it has unlocked the volume, the volume will remain locked. However, the locked volume will NOT be listed as locked in any vos commands that display locked status (see below for details). Background: Most vos write operations lock the VLDB volume entry before proceeding, then release the volume lock when finished. This is accomplished via VL_SetLock and VL_ReleaseLock, respectively. VL_SetLock always sets these members in the VLDB volume entry: - flags is modified to set the required VLOP_* code bit as specified - LockAFSid is set to 0 (never implemented) - LockTimestamp is set to the current time VL_ReleaseLock always sets them as follows: - flags is cleared of any VLOP_* code bit - LockAFSid is set to 0 (never implemented) - LockTimestamp is set to 0 VL_ReplaceEntry(N) may also optionally clear each of these members: - flags operation bits may be explicitly cleared via LOCKREL_OPCODE - LockAFSid may be explicitly cleared via LOCKREL_AFSID - LockTimestamp may be explicitly cleared via LOCKREL_TIMESTAMP When all 3 options are specified, VL_ReplaceEntry also does the functional equivalent of a VL_ReleaseLock. Most vos operations use this method. However, when no lock release options are specified on VL_ReplaceEntry(N), the VLDB entry is simply replaced with the supplied entry. This includes whatever flags values are specified in the supplied entry; therefore, this amounts to an additional, implicit way to set or modify the flags. Root cause: 'vos rename' (UV_RenameVolume) is the only vos operation that does all of the following things: - accepts a replacement volume entry that was obtained before VL_SetLock (and thus does NOT have any lock flags set) - issues VL_SetLock (which sets the lock flag in the VLDB) - issues VL_ReplaceEntry(N) with the original unlocked entry, and with no lock release options (thus with explicit intent to leave the lock flag unchanged, but inadvertently doing an implicit clear of the lock flag in the VLDB) - (performs some additional volserver work) - issues VL_ReleaseLock to release the volume lock Therefore, if 'vos rename' is cancelled or killed before reaching the final VL_ReleaseLock step, the VLDB entry is left with the lock flags cleared but the LockTimestamp still set. As we will see below, this 'half-locked' state produces confusing results from other vos commands. Detection of locked state: The 'vos lock' command (and all other vos commands that issue VL_SetLock) use the lock timestamp to determine if a volume is locked. However, several other vos commands ('vos listvldb ', 'vos examine ', 'vos listvldb -locked') use the VLDB entry's lock flags (not the lock timestamp) to determine if the volume is locked. Therefore, if the lock flags have been cleared but the lock timestamp is still set, these commands fail to detect that the volume is still locked. Yet an administrator's 'vos lock ' will still fail with: Could not lock VLDB entry for volume VLDB: vldb entry is already locked This is the external manifestation of the 'half-locked' state. Workaround and fix: This scenario has a simple workaround: 'vos unlock '. However, to avoid this confusing outcome in the first place, modify the 'vos rename' logic so that the lock flags are no longer inadvertently cleared. Now, if the 'vos rename' is interrupted before the volume is unlocked, it will still appear locked in normal vos command output. Change-Id: Iefc6ef54ea4b0e95e3ae8e8a43d3ded0f15af0fa Reviewed-on: https://gerrit.openafs.org/14157 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Reviewed-on: https://gerrit.openafs.org/14449 Reviewed-by: Mark Vitale Reviewed-by: Stephan Wiesand commit a518b0c439b40886dcb2337919d49b3009a00b4d Author: Cheyenne Wills Date: Thu Nov 5 13:50:59 2020 -0700 vos: Cleanup function definitions The functions defined within vos.c are not referenced outside of vos.c but are not declared as static. Convert the functions within vos.c to static declarations. Reviewed-on: https://gerrit.openafs.org/14009 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 56aa396d8359276d778d41aa509041c8c75b4e96) Change-Id: Idca045431959bb3e4b31d12ef754a883d4118a89 Reviewed-on: https://gerrit.openafs.org/14448 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ab30c00f6ab663e0907830e76e76b44710712a07 Author: Cheyenne Wills Date: Thu Nov 5 13:49:54 2020 -0700 vos: Remove dead code Clean out dead code from vos.c GetVolumeType - not referenced anywhere CompareVLDBEntry - commented out since 1st git commit osi_audit - Comment indicates this might have been needed at one point. Builds without it. Does not look like the vos executable is pulling in any of the audit code. RestoreVolume - remove stale comment about typo previous to openafs 1.0 RemoveSite - remove commented out partition check Reviewed-on: https://gerrit.openafs.org/14008 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit a3be2c74a95489f63837840af8ec42049ce021bf) Change-Id: I71a78d2a46b8d64cdde9db05a0079e9db954d191 Reviewed-on: https://gerrit.openafs.org/14447 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 00095ea2eff4d8570af78044b88c2b2877ce4e2a Author: Cheyenne Wills Date: Tue Nov 10 09:17:16 2020 -0700 vos: Cleanup indentation whitespace Fix the indentation whitespace in vos.c, and remove double blank lines. No functional change. Reviewed-on: https://gerrit.openafs.org/14007 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit c17c157641d83226fee5bc20f588f14bb132bb68) Change-Id: Iecde7505a3f59c4b6e59d4644b7a1e56127c272d Reviewed-on: https://gerrit.openafs.org/14446 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ebbeb69286ae408b59878074d06bc350001ad669 Author: Michael Meffie Date: Fri Dec 27 11:53:05 2019 -0500 vsprocs: Remove dead code Remove the dead code in UV_VolumeMove() commented out with the macro ENABLE_BUGFIX_1165. Remove two commented out lines of code in UV_ConvertRO(). Reviewed-on: https://gerrit.openafs.org/14004 Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Reviewed-by: Michael Meffie Tested-by: BuildBot (cherry picked from commit 6779e30d372b2cd5e7995da23ed5e2971124b79c) Change-Id: Ibeddebdf24ca50341bba3031c6f8548cab245b8a Reviewed-on: https://gerrit.openafs.org/14445 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 32742e3171e32970ee86449ef41d04df388a37f4 Author: Mark Vitale Date: Tue Oct 6 10:18:11 2020 -0400 bozo: defer audit open until log dir is created and current On a new OpenAFS install where the log directory has not yet been created. 'bosserver -auditlog /usr/afs/logs/' (absolute path) fails with ENOENT because the log directory doesn't exist yet. Furthermore, 'bosserver -auditlog ' (relative path) succeeds, but the audit file is created in the current working directory when bosserver was started, not in the expected log directory (Transarc /usr/afs/logs). Both problems have been present since bosserver audit log support was introduced by commit 16d67791dce45e5d4ee9b854c796492ffcde2113 'auditlogs-for-everyone-20050702'. Reorder the bosserver initialization steps to ensure that the log directory has been created and is the current working directory, before creating and opening the audit log. Reviewed-on: https://gerrit.openafs.org/14381 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit f372ec041a83288a5d096360f0ad8589e4db666a) Change-Id: I14a0a4a2a23c8e9b3b658d52511872ecaa4010af Reviewed-on: https://gerrit.openafs.org/14444 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 2473cfb5b98a0226c79e25649cb5cc52b9aea09b Author: Andrew Deason Date: Sat Oct 17 20:51:51 2020 -0500 bozo: Properly detect presence of -auditlog cmd_OptionAsString returns non-zero if the given option _isn't_ given (CMD_MISSING), so we need to call osi_audit_file only when cmd_OptionAsString returns 0. Since commit f6cdf71 (bozo: Use libcmd for command line options), this causes bosserver to complain on startup if no -auditlog was given: $ bosserver Warning: auditlog (null) not writable, ignored. To fix this, skip calling osi_audit_file if -auditlog was not given. While we're changing this anyway, change our processing of our audit-related options to more closely match what other daemons do, like ptserver or viced, so it's easier to see if we're doing the right thing. That is, just call cmd_OptionAsString() without a conditional, and just test if auditFileName is non-NULL later on, after options processing. Reviewed-on: https://gerrit.openafs.org/14402 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 87041d676c93dfe35a085b9b5aaa73e74c08bc90) Change-Id: Ic05e5453c28b4c408300ea35439a519adc282486 Reviewed-on: https://gerrit.openafs.org/14443 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 633712a321f4cf51ffc6f97d2f9fabbb59b32a09 Author: Cheyenne Wills Date: Fri Aug 21 12:53:30 2020 -0600 bozo: Use libcmd for command line options Update bosserver to use libcmd for command line parsing. Reviewed-on: https://gerrit.openafs.org/13845 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit f6cdf7165b4e66772ee06314658b7c209928d611) Change-Id: I8fdf27d099f81c08a37db728846bd7596a8cf62e Reviewed-on: https://gerrit.openafs.org/14442 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit de0ec465625f18668325dfbe29337650ed98b560 Author: Mark Vitale Date: Fri Oct 28 18:12:19 2016 -0400 afs: prevent double release of global lock afs_xvcb afs_GetServer calls ReleaseWriteLock(&afs_xvcb) twice within a few lines. The second one is spurious. Commits b18653de7ae90491c2e75f4a98410581655d776c 'xserver lock order violation' and f2bf60ed4f1323cd6f74f2f01114f7e4f714db53 'xvcb lock order violation' were written by the same author at the same time and apparently were victims of a bad merge. Discovered during a lock audit project as a panic during afsd startup: assertion failed: (&afs_xvcb)->excl_locked == WRITE_LOCK, file: /home/mvitale/src/sna-openafs/src/afs/afs_server.c, line: 2089 afs_GetServer is called frequently by many threads and so this bug could easily have released another thread's write lock on afs_xvcb. Remove the spurious second release. Reviewed-on: https://gerrit.openafs.org/14411 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit e8702e6a615a160cdbe464f76bd6f100667720d2) Change-Id: I3165a63e774296b97e09c374b068b012224776e1 Reviewed-on: https://gerrit.openafs.org/14441 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit b33c832facc53ff966071fd3ff0e5d6b33deb9cb Author: Mark Vitale Date: Mon Sep 18 19:45:10 2017 -0400 stats: incorrect clock square algorithm Since the original IBM code import, OpenAFS has an algorithm for squaring clock values, implemented identically in three different places. This algorithm does not account correctly for microsecs overflow into seconds, resulting in incorrect "sum-of-squares" values for queue and execution time in several OpenAFS performance utilities. Specifically, this code: t1.tv_usec += (2 * t2.tv_sec * t2.tv_usec) % 1000000 \ + (t2.tv_usec / 1000)*(t2.tv_usec / 1000) \ + 2 * (t2.tv_usec / 1000) * (t2.tv_usec % 1000) / 1000 \ + (((t2.tv_usec % 1000) > 707) ? 1 : 0); \ Can allow for the tv_usec field to be increased by a theoretical max of around: t1.tv_usec += 999998 \ + 999*999 \ + 2 * 999 * 999 / 1000 \ + 1; \ Or: t1.tv_usec += 1999996; \ If t1.tv_usec is already 999999, after this calculation its value could be as high as 2999995. So just checking once if t1.tv_usec is over 1000000 is not sufficient, since the resulting value (1999995) is still over 1000000. Correct all implementations by repeatedly checking if tv_usec is over 1000000 after the above calculation: macro affected utility ===================== ============================ afs_stats_SquareAddTo xstat_cm_test fs_stats_SquareAddTo xstat_fs_test clock_AddSq rxstat_get_process and _peer Reviewed-on: https://gerrit.openafs.org/14376 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit e1e5df918fee00d4d9152c31c24cc1e7f23b71a6) Change-Id: I4055ed61311ed7d6ac435b8660d5b7c55f467699 Reviewed-on: https://gerrit.openafs.org/14440 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 489308de9f62a3f881cd5f89d648c168a488c4d7 Author: Mark Vitale Date: Mon Sep 28 16:35:38 2020 -0400 rxstats: correctly report vlserver VL_* RPC stats Since the original IBM code import, rxstat_get_process and rxstat_get_peer have reported vlserver VL_* RPC stats as for the "volserver interface". Correct this to read "vlserver interface". Reviewed-on: https://gerrit.openafs.org/14375 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit e985d43d99d93172b5608a3c73fd3201d3b3a212) Change-Id: Ifbbe4df8ede22b287ab7c67d20e9ccd951367765 Reviewed-on: https://gerrit.openafs.org/14439 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ffc5b608ab3e99d654561b1a3f4b3a873a6af1c0 Author: Mark Vitale Date: Mon Sep 28 15:40:34 2020 -0400 rxstats: correctly distinguish client and server stats Commit d3eaa39da3693bba708fa2fa951568009e929550 'rx: Make the rx_call structure private' inadvertently caused all rxstats (aka rpcstats) to be recorded as client stats by hardcoding the value for isServer to 1. Therefore, when peer or process rxstats are enabled for a OpenAFS component, the rxstat_get_process and rxstat_get_peer utilities will erroneously report both client and server stats as "accessed as a client". This is particularly problematic for ubik VOTE_* and DISK_* RPC stats, for which a given ubik server may be both client and server over time. In this case, both client and server stats are conflated into the same "accessed as a client" counters. Instead, properly pass the value of isServer from rx_RecordCallStatistics through to rxi_IncrementTimeAndCount. Note to maintainers: This bug is only in master and all 1.8.x releases; no 1.6.x releases are affected. Note: Confusingly, isServer=1 indicates client stats and isServer=0 indicates server stats. However, this is a quirk of the original implementation and wire format of the RXSTATS_* RPCs and cannot be changed. isServer is actually shorthand for "remote is server"; thus all RPC client stubs record their rxstats with isServer == 1, and all RPC server stubs record their rxstats with isServer == 0. Reviewed-on: https://gerrit.openafs.org/14374 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 18c345a9f8ee9b2ff73f23dae68757b19d3283f5) Change-Id: I6d41d015803967363f3702f5dda7083ccbf7508a Reviewed-on: https://gerrit.openafs.org/14438 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5d863b4f6e817b1cc2615265c7747e17a2037ae6 Author: Andrew Deason Date: Mon Oct 26 12:19:19 2020 -0500 afs: Log pid with disk cache read errors Log the current pid (and procname) when we complain about an error when reading from CacheItems in afs_UFSGetDSlot. These errors can result in confusing situations, so it can be helpful to know at least what process saw the error. Our logic for logging this information is getting a bit large, so also move this to a new function, LogCacheError. Reviewed-on: https://gerrit.openafs.org/14416 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 1caeeea43c038011306dd1c391680c24fc318e3d) Change-Id: Ia159eeea47191f71fc5892cbc54af79b55bf4828 Reviewed-on: https://gerrit.openafs.org/14437 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit c7c8f75ebf812f1943aa9efd76dde26be99c96b1 Author: Andrew Deason Date: Mon Nov 12 15:06:09 2018 -0600 vlserver: Return VL_DBBAD on unhash failure If we try to delete a vlentry, and the vlentry cannot be found on one of its hash chains, we cannot unhash the vlentry properly and the operation fails with VL_NOENT. This results in the following error messages to the user: $ vos delentry 123456 Could not delete entry for volume 123456 You must specify a RW volume name or ID (the entire VLDB entry will be deleted) VLDB: no such entry Deleted 0 VLDB entries This is confusing, because VL_NOENT can also occur if the user specifies a volume that does actually not exist. This situation is indicative of database corruption, usually because of a ubik transaction that was only half-applied, or because of other ubik bugs in the past. The situation can only really be fixed by repairing the database, so return VL_DBBAD in this case instead, to more clearly indicate that something is wrong with the database, and not a problem with the arguments the caller provided. Reviewed-on: https://gerrit.openafs.org/13384 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit fd6add0aca03a5a17f7109c785b6027a76f13cdf) Change-Id: Ib1cf72b7f0d6c65e37c13f00d6f6049a3049b644 Reviewed-on: https://gerrit.openafs.org/14436 Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 751aa775da1c76a495cf1b0754185cb4cdc23fbe Author: Andrew Deason Date: Mon Nov 12 14:41:44 2018 -0600 vlserver: Add VL_DBBAD error code The VL_ error table currently doesn't have an error code to indicate that an operation cannot succeed because the database is corrupted. There are a few error codes for specific cases of errors that are probably the result of corruption (like VL_IDALREADYHASHED, or VL_EMPTY), but these are only for specific cases and indicate rather low-level internal problems. There are some instances where the real problem preventing an operation from succeeding is that the database is just corrupt or inconsistent in some way, and the administrator must repair the database before it can succeed. And we currently don't have any way of indicating that situation via an error code. So, introduce the VL_DBBAD code, to indicate this situation. Error codes already exist in other tables for similar situations, such as PRDBBAD, and KADATABASEINCONSISTENT. This commit does not use the new error code anywhere; we just introduce it into the VL_ error table, so comerr-using applications will be able to interpret it. Note that the VL_DBBAD error code has been recognized by the AFS Assigned Numbers Registry as recorded in the ticket history of Reviewed-on: https://gerrit.openafs.org/13383 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit 878d27c845157bb64c32bbd6c3cacce17c681d70) Change-Id: I93b4916890ec9e4f6f5453ecf28c8a8ce04af7ea Reviewed-on: https://gerrit.openafs.org/14435 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 27a2cdadd221d4a870d5ce9b936bb103c605cafb Author: Andrew Deason Date: Mon Nov 12 15:01:18 2018 -0600 vlserver: Warn when we cannot unhash deleted entry If we are trying to delete an entry from the vldb, we fail with VL_NOENT if we cannot find the given entry on one of its hash chains. This is indicative of corruption in the vldb (since we have an entry not on a hash chain), but we don't really indicate this clearly. There are no log messages, and the user running 'vos' only sees an error like this: $ vos delentry 123456 Could not delete entry for volume 123456 You must specify a RW volume name or ID (the entire VLDB entry will be deleted) VLDB: no such entry Deleted 0 VLDB entries Which is the exact same error message if the user tries to delete a volume that does not actually exist. We currently do not have an error code that clearly says that the database appears corrupted and needs to be fixed, but we can at least log an error in VLLog for this case, to give the administrator a chance at fixing the situation. So, log a message in this situation. Reviewed-on: https://gerrit.openafs.org/13382 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 3e3fce24da31a31ca9a3f4ad356c4e4eaf0ad897) Change-Id: Ia76c5d7a19c3d21a89fc502e14922672afd8a84f Reviewed-on: https://gerrit.openafs.org/14434 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 757b90ef33f7d5f00c4b1990c2300f6502a3b74a Author: Marcio Barbosa Date: Thu Sep 3 23:57:34 2020 +0000 volser: take RO volume offline during convertROtoRW The vos convertROtoRW command converts a RO volume into a RW volume. Unfortunately, the RO volume is not checked out from the fileserver during this process. As a result, accesses to the volume being converted can leave volume objects in an inconsistent state. Moreover, consider the following scenario: 1. Create a volume on host_b and add replicas on host_a and host_b. $ vos create host_b a vol_1 $ vos addsite host_b a vol_1 $ vos addiste host_a a vol_1 2. Mount the volume: $ fs mkmount /afs/.mycell/vol_1 vol_1 $ vos release vol_1 $ vos release root.cell 3. Shutdown dafs on host_b: $ bos shutdown host_b dafs 4. Remove RO reference to host_b from the vldb: $ vos remsite host_b a vol_1 5. Attach the RO copy by touching it: $ fs flushall $ ls /afs/mycell/vol_1 6. Convert RO copy to RW: $ vos convertROtoRW host_a a vol_1 Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving the volume object for the RO copy set as VOL_STATE_ATTACHED (on success, this volume should be set as VOL_STATE_DELETED). 7. Add replica on host_a: $ vos addsite host_a a vol_1 8. Wait until the "inUse" flag of the RO entry is cleared (or force this to happen by attaching multiple volumes). 9. Release the volume: $ vos release vol_1 Failed to start transaction on volume 536870922 Volume not attached, does not exist, or not on line Error in vos release command. Volume not attached, does not exist, or not on line Notice that this happens because we cannot mark an attached volume as destroyed (FSYNC_com_VolDone). To avoid the problem mentioned above and to prevent accesses to the volume being converted, take the RO volume offline before converting it to RW. Reviewed-on: https://gerrit.openafs.org/14340 Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 45a69b61133ae8ca8e49a002ddc1895386796d51) Change-Id: I94e08d09d5044f3c0cac7c700f26ec6e7b111d6f Reviewed-on: https://gerrit.openafs.org/14433 Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand Tested-by: Stephan Wiesand commit 199d485ee862c21c43008e1fd4b226517d20068c Author: Marcio Barbosa Date: Thu Sep 3 20:11:34 2020 +0000 volser: Close dirp on error in ConvertROtoRW Currently, if SAFSVolConvertROtoRWvolume cannot create a new transaction for the volume to be converted, it returns without closing the directory stream opened by it. To prevent this leak, go through a new 'goto done' destructor if NewTrans fails. Reviewed-on: https://gerrit.openafs.org/14342 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit f18b58f8227df2ab420d69eb5937a99f747c7692) Change-Id: I81b5f7a330548eaecba1acfdc7231d2a953a365b Reviewed-on: https://gerrit.openafs.org/14432 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit cc6b15564eaf94bcb41f930f396f1c1e4804fa18 Author: Michael Meffie Date: Thu Apr 16 16:29:09 2020 -0400 vlserver: fix missing read-only entries from ListAttributesN2 The ListAttributesN2() RPC can fail to list read-only entries under certain circumstances. This RPC is used by the `vos listvldb` command to retrieve vldb entries (unless the -name option is given). The `vos listvldb` command fails to list volume entries when run with the '-server' option for volumes that have read-only replicas, but have not been released. Consider the following example volume: $ vos create fs1.example.com a test $ vos addsite fs1.example.com a test $ vos addsite fs2.example.com a test $ vos listvldb ... test RWrite: 536870921 number of sites -> 3 server fs1.example.com partition /vicepa RW Site server fs1.example.com partition /vicepa RO Site -- Not released server fs2.example.com partition /vicepa RO Site -- Not released `vos listvldb` fails to find the volume when the search is limited to server 'fs2': $ vos listvldb -server fs2.example.com VLDB entries for server fs2.example.com Total entries: 0 Instead of the expected results: $ vos listvldb -server fs2.example.com test RWrite: 536870921 number of sites -> 3 server fs1.example.com partition /vicepa RW Site server fs1.example.com partition /vicepa RO Site -- Not released server fs2.example.com partition /vicepa RO Site -- Not released This situation makes it difficult to remove old server addresses from the vldb. In this situation, 'vos remaddrs' and 'vos changeaddr -remove' commands will complain the server addresses are still in use by volume entries, however running 'vos listvldb -server' will not show which volumes entries are in use. The entries are not listed for unreleased volumes because the ListAttributesN2() RPC is currently checking the volume VLF_ROEXISTS flag, instead of the server site flags (serverFlags) to determine when the entry is a read-only site. The volume VLF_ROEXISTS flag is set when a volume is released. To fix this, make ListAttributesN2 check for the VLSF_ROVOL site flag, instead of the VLF_ROEXISTS entry flag. Reviewed-on: https://gerrit.openafs.org/14154 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 904f5bd398db248c11b30ef7e360ce5141dcd1f3) Change-Id: Iea4bbbc9fb0c42ac5e109ee94688436fdcc42a67 Reviewed-on: https://gerrit.openafs.org/14427 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit b7ddd1262117332871e7cd537aa6065b78a41bb2 Author: Andrew Deason Date: Thu Jun 18 21:16:09 2020 -0500 LINUX: Close cacheFp if no ->readpage in fastpath In afs_linux_readpage_fastpath, if we discover that our disk cache fs has no ->readpage function, we'll 'goto out', but we never close our cacheFp. To make sure we close it, add a filp_close() call to the 'goto out' cleanup code. Reviewed-on: https://gerrit.openafs.org/14252 Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit f9d20c631d7280ce00125a1208331931a6e3f31c) Change-Id: If409c50e5515cd80f77171a90fd96e2d3fb575a8 Reviewed-on: https://gerrit.openafs.org/14421 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 610e50b70c666f72a6d8b02e1759ac1dece10dd3 Author: Michael Meffie Date: Fri Aug 28 11:24:10 2020 -0400 bozo: Log each dir and file with bad access rights The bosserver directory and file access check stops after finding one directory or file with incorrect permissions or owner. A log message is written for this first one found, but more than one directory or file may have incorrect access rights. Instead check all of them so the bosserver logs a warning message for each incorrect director or file permission found. This should make it easier to fix all of the file permission problems at once. Reviewed-on: https://gerrit.openafs.org/14330 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 47d809d4434f6724d0b6fbe2dcb54749486eeddb) Change-Id: Ieffac018628e1b3a1ad930b72312f596ee452b43 Reviewed-on: https://gerrit.openafs.org/14420 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 712ef18ac1902fabc540883827b1925769e0a050 Author: Michael Meffie Date: Fri Aug 28 11:23:00 2020 -0400 bozo: Add KeyFileExt and rxkad.keytab to access rights check When the KeyFileExt and rxkad.keytab were added to OpenAFS, they were not added to the bosserver's access rights check. Add these files to the bosserver access checks, with the same access rights needed for the original KeyFile. Also, add the full path for KeyFileExt to the dirpath package (not just the filename), which was not done when the KeyFileExt was introduced. This is needed to perform the access checks. Reviewed-on: https://gerrit.openafs.org/14329 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit a6b14ea90259fbc4ead62f5f4288e435801db81e) Change-Id: I94d9027f9455ee8a8f307864ffa49debaf579e71 Reviewed-on: https://gerrit.openafs.org/14419 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 62beb979b4e43c361db54fbf3084f876fd2c11da Author: Andrew Deason Date: Mon Jul 16 16:53:34 2018 -0500 afs: Skip bulkstat if stat cache looks full Currently, afs_lookup() will try to prefetch dir entries for normal dirs via bulkstat whenever multiple pids are reading that dir. However, if we already have a lot of vcaches, ShakeLooseVCaches may be struggling to limit the vcaches we already have. Entering afs_DoBulkStat can make this worse, since we grab afs_xvcache repeatedly, we may kick out other vcaches, and we'll possibly create 30 new vcaches that may not even be used before they're evicted. To try to avoid this, skip running afs_DoBulkStat if it looks like the stat cache is really full. Reviewed-on: https://gerrit.openafs.org/13256 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 9ff45e73cf3d91d12f09e108e1267e37ae842c87) Change-Id: I1b84ab3bb918252e8db5e4379730a517181bc9d8 Reviewed-on: https://gerrit.openafs.org/14400 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 28794011085d35b293d5e829adadb372b2a2b3fd Author: Andrew Deason Date: Mon Jul 16 16:44:14 2018 -0500 afs: Log warning when we detect too many vcaches Currently, afs_ShakeLooseVCaches has a kind of warning that is logged when we fail to free up any vcaches. This information can be useful to know, since it may be a sign that users are trying to access way more files than our configured vcache limit, hindering performance as we constantly try to evict and re-create vcaches for files. However, the current warning is not clear at all to non-expert users, and it can only occur for non-dynamic vcaches (which is uncommon these days). To improve this, try to make a general determination if it looks like the stat cache is "stressed", and log a message if so after afs_ShakeLooseVCaches runs (for all platforms, regardless of dynamic vcaches). Also try to make the message a little more user-friendly, and only log it (at most) once per 4 hours. Determining whether the stat cache looks stressed or not is difficult and arguably subjective (especially for dynamic vcaches). This commit draws a few arbitrary lines in the sand to make the decision, so at least something will be logged in the cases where users are constantly accessing way more files than our configured vcache limit. Reviewed-on: https://gerrit.openafs.org/13255 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0532f917f29bdb44f4933f9c8a6c05c7fecc6bbb) Change-Id: Ic7260f276e00f3e34541207955df841d4ed27844 Reviewed-on: https://gerrit.openafs.org/14399 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 47ab46e1e9fe56b5bf8147eab0b652e74078cbe7 Author: Andrew Deason Date: Mon Jul 16 16:08:13 2018 -0500 afs: Split out bulkstat conditions into a function Our current if() statement for determining whether we should run afs_DoBulkStat to prefetch dir entries is a bit large, and grows over time. Split this logic out into a separate function to make it easier to maintain, and add some comments to help explain each condition. This commit should have no visible effects; it's just code reorganization. Reviewed-on: https://gerrit.openafs.org/13254 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 19cd454f11997d286bc415e9bc9318a31f73e2c6) Change-Id: Ida322c518d11787fd794df7534135fbc2dec2935 Reviewed-on: https://gerrit.openafs.org/14398 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 738eb3e4976947657f877ec107d517d63a66a907 Author: Andrew Deason Date: Sun Jul 8 15:00:02 2018 -0500 afs: Bound afs_DoBulkStat dir scan Currently, afs_DoBulkStat will scan the entire directory blob, looking for entries to stat. If all or almost all entries are already stat'd, we'll scan through the entire directory, doing nontrivial work on each entry (we grab afs_xvcache, at least). All of this work is pretty pointless, since the entries are already cached and so we won't do anything. If many processes are trying to acquire afs_xvcache, this can contribute to performance issues. To avoid this, provide a constant bound on the number of entries we'll search through: nentries * 4. The current arbitrary limits cap nentries at 30, so this means we're capping the afs_DoBulkStat search to 120 entries. Reviewed-on: https://gerrit.openafs.org/13253 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit ba8b92401b8cb2f5a5306313c2702cb36cba083c) Change-Id: Icf82f88328621cb5a9e0ad52f873b8a7d74b1f3a Reviewed-on: https://gerrit.openafs.org/14397 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit fbba8e4cbf00f32181b5075e8d7a876cccd2a046 Author: Andrew Deason Date: Thu Jul 13 17:40:36 2017 -0500 afs: Avoid needless W-locks for afs_FindVCache The callers of afs_FindVCache must hold at least a read lock on afs_xvcache; some hold a shared or write lock (and set IS_SLOCK or IS_WLOCK in the given flags). Two callers (afs_EvalFakeStat_int and afs_DoBulkStat) currently hold a write lock, but neither of them need to. In the optimal case, where afs_FindVCache finds the given vcache, this means that we unnecessarily hold a write lock on afs_xvcache. This can impact performance, since afs_xvcache can be a very frequently accessed lock (a simple operation like afs_PutVCache briefly holds a read lock, for example). To avoid this, have afs_DoBulkStat hold a shared lock on afs_xvcache, upgrading to a write lock when needed. afs_EvalFakeStat_int doesn't ever need a write lock at all, so just convert it to a read lock. Reviewed-on: https://gerrit.openafs.org/12656 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 6c808e05adb0609e02cd61e3c6c4c09eb93c1630) Change-Id: Id517d1098b4c3a02db646b2a74535f77cb684ec3 Reviewed-on: https://gerrit.openafs.org/14396 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 5c476b91fd2259e9c34070be8ba201dd471ad974 Author: Andrew Deason Date: Thu Jul 13 17:40:21 2017 -0500 afs: Change VerifyVCache2 calls to VerifyVCache afs_VerifyVCache is a macro that (on most platforms) effectively expands to: if ((avc->f.states & CStatd)) { return 0; } else { return afs_VerifyVCache2(...); } Some callers call afs_VerifyVCache2 directly, since they already check for CStatd for other reasons. A few callers currently call afs_VerifyVCache2, but without guaranteeing that CStatd is not set. Specifically, in afs_getattr and afs_linux_VerifyVCache, CStatd could be set while afs_CreateReq drops GLOCK. And in afs_linux_readdir, CStatd could be cleared at multiple different points before the VerifyVCache call. This can result in afs_VerifyVCache2 acquiring a write-lock on the vcache, even when CStatd is already set, which is an unnecessary performance hit. To avoid this, change these call sites to use afs_VerifyVCache instead of calling afs_VerifyVCache2 directly, which skips the write lock when CStatd is already set. Reviewed-on: https://gerrit.openafs.org/12655 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit a05d5b7503e466e18f5157006c1de2a2f7d019f7) Change-Id: I05bdcb7f10930ed465c24a8d7e51077a027b1a4b Reviewed-on: https://gerrit.openafs.org/14395 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 150ee65f286409e37fcf94807dbeaf4b79ab0769 Author: Andrew Deason Date: Sun Apr 26 17:26:02 2020 -0500 rx: Use _IsLast to check for last call in queue Ever since commits 170dbb3c (rx: Use opr queues) and d9fc4890 (rx: Fix test for end of call queue for LWP), rx_GetCall checks if the current call is the last one on rx_incomingCallQueue by doing this: opr_queue_IsEnd(&rx_incomingCallQueue, cursor) But opr_queue_IsEnd checks if the given pointer is the _end_ of the last; that is, if it's the end-of-list sentinel, not an item on the actual list. Testing for the last item in a list is what opr_queue_IsLast is for. This is the same convention that the old Rx queues used, but 170dbb3c just accidentally replaced queue_IsLast with opr_queue_IsEnd (instead of opr_queue_IsLast), and d9fc4890 copied the mistake. So because this is inside an opr_queue_Scan loop, opr_queue_IsEnd will never be true, so we'll never enter this block of code (unless we are the "fcfs" thread). This means that an incoming Rx call can get stuck in the incoming call queue, if all of the following are true: - The incoming call consists of more than 1 packet of incoming data. - The incoming call "waits" when it comes in (that is, there are no free threads or the service is over quota). - The "fcfs" thread doesn't scan the incoming call queue (because it is idle when the call comes in, but the relevant service is over quota). To fix this, just use opr_queue_IsLast here instead of opr_queue_IsEnd. Reviewed-on: https://gerrit.openafs.org/14158 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit befc72749884c6752c7789479343ba48c7d5cea1) Change-Id: If724245414798ae7a86dfa048cf99863317aef8e Reviewed-on: https://gerrit.openafs.org/14394 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 12aed9ef2988a69187910bada5ba7325cb6144ab Author: Andrew Deason Date: Sun Jul 21 18:48:51 2019 -0500 rx: Avoid osi_NetSend during rx shutdown Commit 8d939c08 (rx: avoid nat ping during shutdown) added a call to shutdown_rx() inside the DARWIN shutdown sequence, before the rx socket was closed. From the commit message, it sounds like this was done to avoid NAT pings from calling osi_NetSend during the shutdown sequence after the rx socket was closed; calling shutdown_rx() before closing the socket would cause any connections we had to be destroyed first, avoiding that. The problem with this is that this means shutdown_rx() is called when osi_StopNetIfPoller is called, which is much earlier than some other portions of the shutdown sequence; some of which may hold references to e.g. rx connections. If we try to, for instance, destroy an rx connection after shutdown_rx() is called, we could panic. An earlier version of that commit (gerrit PS1) just tried to insert a check before the relevant osi_NetSend call, making us just skip the osi_NetSend if the shutdown sequence had been started. So to avoid the above issue, try to implement that approach instead. And instead of doing it just for NAT pings, we can do it for almost all osi_NetSend calls (besides those involved in the shutdown sequence itself), by checking this in rxi_NetSend. Also return an error (ESHUTDOWN) if we skip the osi_NetSend call, so we're not completely silent about doing so. This means we also remove the call to shutdown_rx() inside DARWIN's osi_StopNetIfPoller(). This allows us to interact with Rx objects during more of the shutdown process in cross-platform code. Reviewed-on: https://gerrit.openafs.org/13718 Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 9866511bb0a5323853e97e3ee92524198813776e) Change-Id: Ie62c1a68d8a8889f7a8aa3eff3973c219b45a95c Reviewed-on: https://gerrit.openafs.org/14393 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 7f59989cf84df1e2077f4fcf5649c9624e79a5d2 Author: Andrew Deason Date: Sun Jul 21 18:31:53 2019 -0500 rx: Introduce rxi_NetSend Introduce a small wrapper around osi_NetSend, called rxi_NetSend. This small wrapper allows future commits to change the code around our osi_NetSend calls, without needing to change every single call site, or every implementation of osi_NetSend. Change most call sites to use rxi_NetSend, instead of osi_NetSend. Do not change a few callers in the platform-specific kernel shutdown sequence, since those call osi_NetSend for platform-specific reasons. This commit on its own does not change any behavior with osi_NetSend; it is just code reorganization. Reviewed-on: https://gerrit.openafs.org/13717 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 2a33a80f7026df6b5e47e42319c55d8b7155675a) Change-Id: I6af8541953a582d044fb668eb4a91720536bc8e1 Reviewed-on: https://gerrit.openafs.org/14392 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 38f613f5e15552938cb425c68b22c166e35284be Author: Andrew Deason Date: Tue Oct 13 20:18:59 2020 -0500 ubik: Remove unused sampleName The RPC-L type sampleName and related constant UMAXNAMELEN are not referenced by anything, and have been unused since OpenAFS 1.0. Remove the unused definitions. Reviewed-on: https://gerrit.openafs.org/14386 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 83ce8d41c68a5ebcc84132d77af9024c6d285e05) Change-Id: I1d6c583d9c630fc9704578ba3329132e16b3a803 Reviewed-on: https://gerrit.openafs.org/14401 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit f7374a883505aa34a3db34ddd1163367c544bb0c Author: Andrew Deason Date: Sat May 2 23:54:55 2020 -0500 afs: Drop GLOCK for RXAFS_GetCapabilities We are hitting the net here; we certainly should not be holding AFS_GLOCK while waiting for the server's response. Found via FreeBSD WITNESS. Reviewed-on: https://gerrit.openafs.org/14181 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 44b7b93b593371bfdddd0be0ae603f4f8720f78b) Change-Id: I186e08c89136cc3109fd2519bb0d2abbb52f9ba0 Reviewed-on: https://gerrit.openafs.org/14391 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 02fb067d3fded0eee5c9326c56e66b512a75d71c Author: Michael Meffie Date: Mon Mar 23 09:46:05 2020 -0400 build: remove unused LINUX_PKGREL from configure.ac This change removes the unused LINUX_PKGREL definition from the configure.ac file. Commit 6a27e228bac196abada96f34ca9cd57f32e31f5c converted the setting of the RPM package version and release values in the openafs.spec file from autoconf to the makesrpm.pl script. That commit left LINUX_PKGREL in configure.ac because it was still referenced by the Debian packaging, which was still in-tree at that time. Commit ada9dba0756450993a8e57c05ddbcae7d1891582 removed the last trace of the Debian packaging, but missed the removal of the LINUX_PKGREL. Reviewed-on: https://gerrit.openafs.org/14117 Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 8ae4531c5720baff9e11e4b05706eab6c82de5f9) Conflicts: configure.ac Change-Id: I69925f89c52aef32aea5bc308140936517b1aeb0 Reviewed-on: https://gerrit.openafs.org/14363 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 2f2cbff766650e7c25eb332d5385f4a3fca8676d Author: Andrew Deason Date: Mon Apr 20 13:03:15 2020 -0500 ubik: Avoid unlinking garbage during recovery In urecovery_Interact, if any of our operations fail around calling DISK_GetFile, we will jump to FetchEndCall and eventually unlink 'pbuffer'. But if we failed before opening our .DB0.TMP file, the contents of 'pbuffer' will not be initialized yet. During most iterations of the recovery loop, the contents of 'pbuffer' will be filled in from previous loops, and it should always stay the same, so it's not a big problem. But if this is the first iteration of the loop, the contents of 'pbuffer' may be stack garbage. Solve this in two ways. To make sure we don't use garbage contents in 'pbuffer', memset the whole thing to zeroes at the beginning of urecovery_Interact(). And then to make sure we're not reusing 'pbuffer' contents from previous iterations of the loop, also clear the first character to NUL each time we arrive at this area of the recovery code. And avoid unlinking anything if pbuffer starts with a NUL. Commit 44e80643 (ubik: Avoid unlinking garbage) fixes the same issue, but only fixed it in the SDISK_SendFile codepath in remote.c. Reviewed-on: https://gerrit.openafs.org/14153 Tested-by: BuildBot Reviewed-by: Marcio Brito Barbosa Reviewed-by: Benjamin Kaduk (cherry picked from commit 98b5ffb52117aefac5afb47b30ce9b87eb2fdebf) Change-Id: I5cadb88e466ddd326ef1e4138d5b1bf89fdb27dc Reviewed-on: https://gerrit.openafs.org/14365 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 8993e35578e4ae51dd5e8941f77c18bb975e51af Author: Andrew Deason Date: Fri Sep 18 14:03:37 2020 -0600 WINNT: Make opr_threadname_set a no-op We don't supply an implementation for opr_threadname_set for WINNT; don't pretend that we do. Reviewed-on: https://gerrit.openafs.org/13817 Tested-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit f895a9b51671ffdc920fd9b4284337c5b737a0ef) Change-Id: Ie8df82550f5420e2b024dea29aae0e39e3ee506f Reviewed-on: https://gerrit.openafs.org/14369 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 045a97dfbc8dd6a2794b74e16f47984dc5f8eccf Author: Andrew Deason Date: Fri Sep 18 12:11:36 2020 -0600 Move afs_pthread_setname_self to opr Move the functionality in afs_pthread_setname_self from libutil to opr, in a new function opr_threadname_set. This allows us to more easily use the routine in more subsystems, since most code already uses opr. Reviewed-on: https://gerrit.openafs.org/13655 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 9d28f7390332c92b3d9e863c6fe70c26db28b5ad) Change-Id: Ic6bbb615bc3494a7a114a0f4cae711b65ebec111 Reviewed-on: https://gerrit.openafs.org/14368 Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 41f4bb48741065da6a69ffcb05e451e5c7dac757 Author: Marcio Barbosa Date: Mon Aug 31 19:56:56 2020 +0000 Revert "vos: take RO volume offline during convertROtoRW" This reverts commit 32d35db64061e4102281c235cf693341f9de9271. While that commit did fix the mentioned problem, depending on "vos" to set the volume to be converted as "out of service" is not ideal. Instead, this volume should be set as offline by the SAFSVolConvertROtoRWvolume RPC, executed on the volume server. The proper fix for this problem will be introduced by another commit. Reviewed-on: https://gerrit.openafs.org/14339 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 85893ac3df0c2cb48776cf1203ec200507b6ce7d) Change-Id: Ie125d2dae1301ca5a4f8323099e6e42bc57b6d28 Reviewed-on: https://gerrit.openafs.org/14361 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 29cdc0af10cb2a0f4cb4d1b05e72d6f066a1a7a5 Author: Yadavendra Yadav Date: Wed Apr 15 05:33:00 2020 -0500 LINUX: Always crref after _settok_setParentPag Commit b61eac78 (Linux: setpag() may replace credentials) changed PSetTokens2 to call crref() after _settok_setParentPag(), since changing the parent PAG may change our credentials structure. But that commit did not update the old pioctl PSetTokens, so -setpag functionality remained broken on Linux for utilities that called the old pioctl ('klog' is one such utility). To fix this, we could copy the same code from PSetTokens2 into PSetTokens. But instead just move this code into _settok_setParentPag itself, to avoid code duplication. This commit also refactors _settok_setParentPag a little to make the platform-specific ifdefs a little easier to read through. Reviewed-on: https://gerrit.openafs.org/14147 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Yadavendra Yadav Reviewed-by: Benjamin Kaduk (cherry picked from commit 8002a46125e8224ba697c194edba5ad09e4cfc44) Change-Id: I6a9d10428fe470cb38e3ca669f273dde0fa9c875 Reviewed-on: https://gerrit.openafs.org/14328 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 9553128008c7656d78759aa685a574906d352f3c Author: Yadavendra Yadav Date: Wed Apr 15 05:33:00 2020 -0500 LINUX: Copy session keys to parent in SetToken Commit 48589b5d (Linux: Restore aklog -setpag functionality for kernel 2.6.32+) added code to SetToken() to copy our session keyring to the parent process, in order to implement -setpag functionality. But this was removed from SetToken() in commit 1a6d4c16 (Linux: fix aklog -setpag to work with ktc_SetTokenEx), when the same code was moved to ktc_SetTokenEx(). Add this code back to SetTokens(), so -setpag functionality can work again with utilities that use older functions like ktc_SetToken, like 'klog'. Reviewed-on: https://gerrit.openafs.org/14146 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 826bb826274e48c867b41cb948d031a423373901) Change-Id: I1ae90d92efa27bce2ff59ff9b9dcca370eaf4730 Reviewed-on: https://gerrit.openafs.org/14327 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 01dfdf2608c5643714da61950637c1e7d1994023 Author: Yadavendra Yadav Date: Fri Aug 21 01:54:00 2020 +0530 afs: Avoid NatPing event on all connection Inside release_conns_user_server, connection vector is traversed and after destroying a connection new eligible connection is found on which NatPing event will be set. Ideally there should be only one connection on which NatPing should be set but in current code while traversing all connection of server a NatPing event is set on all connections to that server. In cases where we have large number of connection to a server this can lead to huge number of “RX_PACKET_TYPE_VERSION” packets sent to a server. Since this happen during Garbage collection of user structs, to simulate this issue below steps were tried - had one script which “cd” to a volume mount and then script sleeps for large time. - Ran one infinite while loop where above script was called using PAG based tokens (As new connection will be created for each PAG) - Instrumented the code, so that we hit above code segment where NatPing event is set. Mainly reduced NOTOKTIMEOUT to 60 sec. To fix this issue set NatPing on one connection and once it is set break from “for” loop traversing the server connection. Reviewed-on: https://gerrit.openafs.org/14312 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason (cherry picked from commit b968875a342ba8f11378e76560b46701f21391e8) Change-Id: I8c70108ab3eb73ed1d9e598381bc29b87ca42aa0 Reviewed-on: https://gerrit.openafs.org/14364 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit e4103743d91bcdba1c57c850eb07b0b03abe72d6 Author: Andrew Deason Date: Mon Jun 22 22:54:52 2020 -0500 volser: Don't NUL-pad failed pread()s in dumps Currently, the volserver SAFSVolDump RPC and the 'voldump' utility handle short reads from pread() for vnode payloads by padding the missing data with NUL bytes. That is, if we request 4k of data for our pread() call, and we only get back 1k of data, we'll write 1k of data to the volume dump stream followed by 3k of NUL bytes, and log messages like this: 1 Volser: DumpFile: Error reading inode 1234 for vnode 5678 1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960 This can happen if we hit EOF on the underlying file sooner than expected, or if the OS just responds with fewer bytes than requested for any reason. The same code path tries to do the same NUL-padding if pread() returns an error (for example, EIO), padding the entire e.g. 4k block with NULs. However, in this case, the "padding" code often doesn't work as intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k in this example), like so: if (n < howMany) Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and so compilers will promote 'n' to the unsigned type, causing this conditional to fail when n is -1. As a result, all of the relevant log messages are skipped, and the data in the dumpstream gets corrupted (we skip a block of data, and our 'howFar' offset goes back by 1). So this can result in rare silent data corruption in volume dumps, which can occur during volume releases, moves, etc. To fix all of this, remove this bizarre NUL-padding behavior in the volserver. Instead: - For actual errors from pread(), return an error, like we do for I/O errors in most other code paths. - For short reads, just write out the amount of data we actually read, and keep going. - For premature EOF, treat it like a pread() error, but log a slightly different message. For the 'voldump' utility, the padding behavior can make sense if a user is trying to recover volume data offline in a disaster recovery scenario. So for voldump, add a new switch (-pad-errors) to enable the padding behavior, but change the default behavior to bail out on errors. Reviewed-on: https://gerrit.openafs.org/14255 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 4498bd8179e5e93a33468be3c8e7a30e569d560a) Change-Id: Idf89d70c9d4d650dbf7b73e67c5b71b9bab7c3f4 Reviewed-on: https://gerrit.openafs.org/14367 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 9947625a1d67b4ffdc0582e9081000e34be2b46b Author: Michael Meffie Date: Fri May 15 12:01:44 2020 -0400 vos: avoid CreateVolume when restoring over an existing volume Currently, the UV_RestoreVolume2 function always attempts to create a new volume, even when doing a incremental restore over an existing volume. When the volume already exists, the volume creation operation fails on the volume server with a VVOLEXISTS error. The client will then attempt to obtain a transaction on the existing volume. If a transaction is obtained, the incremental restore operation will proceed. If a full restore is being done, the existing volume is removed and a new empty volume is created. Unfortunately, the failed volume creation is logged to by the volume server, and so litters the log file with: Volser: CreateVolume: Unable to create the volume; aborted, error code 104 To avoid polluting the volume server log with these messages, reverse the logic in UV_RestoreVolume2. Assume the volume already exists and try to get the transaction first when doing an incremental restore. Create a new volume if the transaction cannot be obtained because the volume is not present. When doing a full restore, remove the existing volume, if one exists, and then create a new empty volume. Reviewed-on: https://gerrit.openafs.org/14208 Tested-by: BuildBot Reviewed-by: Marcio Brito Barbosa Tested-by: Marcio Brito Barbosa Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit f5051b87a56b3a4f7fd7188cbd16a663eee8abbf) Change-Id: I422b81e0c800ff655ac8851b2872f4d7160d79a8 Reviewed-on: https://gerrit.openafs.org/14326 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 967aa95fe23f98c911b8a618132442159eda3f77 Author: Yadavendra Yadav Date: Wed Apr 29 05:10:05 2020 +0000 rxkad: Use krb5_enctype_keysize in tkt_DecodeTicket5 Inside tkt_DecodeTicket5 (rxkad/ticket5.c) function, keysize is calculated using krb5_enctype_keybits and then dividing number of bits by 8. For 3DES number of keybits are 168, so keysize comes out to 21(168/8). However actual keysize of 3DES key is 24. This keysize is passed to _afsconf_GetRxkadKrb5Key where keysize comparison happens, since there is keysize mismatch it returns AFSCONF_BADKEY. To fix this issue get keysize from krb5_enctype_keysize function instead of krb5_enctype_keybits. Thanks to John Janosik (jpjanosi@us.ibm.com) for analyzing and fixing this issue. Reviewed-on: https://gerrit.openafs.org/14203 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 5d53ed0bdab6fea6d2426691bdef2b6f9cb7f2fe) Change-Id: I16cd7a803a139802671a8045dac09e10ef4ad6cb Reviewed-on: https://gerrit.openafs.org/14325 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit 28e96b954fe17810d1ebdd9fdd4702511e870a67 Author: Jan Iven Date: Tue Sep 1 14:51:25 2020 +0200 ptserver: Remove duplicate ubik_SetLock in listSuperGroups It looks like a call to ubik_SetLock(.. LOCKREAD) was left in place in listSuperGroups after locking was moved to ReadPreamble in commit a6d64d70 (ptserver: Refactor per-call ubik initialisation) When compiled with 'supergroups', and once contacted by "pts mem -expandgroups ..", ptserver will therefore abort() with Ubik: Internal Error: attempted to take lock twice This patch removes the superfluous ubik_SetLock. FIXES 135147 Reviewed-on: https://gerrit.openafs.org/14338 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 696f2ec67b049639abf04905255a7d6173dbb19e) Change-Id: I62bfe44e374b398278658b61f2ecf9a66fab18ae Reviewed-on: https://gerrit.openafs.org/14345 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit c7a3154382376ca2e5effdfed2c447c86b9f6eed Author: Michael Meffie Date: Wed Jul 1 21:50:09 2020 -0400 redhat: Add make to the dkms-openafs pre-requirements If `make` is not installed before dkms-openafs, the OpenAFS kernel module is not built during the dkms-openafs package installation. The failure happens in the "checking if linux kernel module build works" configure step, which invokes `make` to check the linux buildsystem. configure fails when `make` is not available, and gives the unhelpful suggestion (in this case) of configuring with --disable-kernel module. Running the configure.log in the dkms build directory shows: configure:7739: checking if linux kernel module build works make -C /lib/modules/4.18.0-193.6.3.el8_2.x86_64/build M=/var/lib/dkms/openafs/... ./configure: line 7771: make: command not found configure: failed using Makefile: Avoid this build failure by adding `make` to the list of dkms-openafs package pre-requirements. Reviewed-on: https://gerrit.openafs.org/14266 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit e61ab9353e99d3298815296abf6b02c50ebe3df0) Change-Id: I9b2bb73acabfabc1cf8b5514c8aa66572cc96066 Reviewed-on: https://gerrit.openafs.org/14314 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ddaf6a74ff3e0aeb4c8b2b15886eaa5c90db59bf Author: Cheyenne Wills Date: Fri Aug 28 10:32:01 2020 -0600 INSTALL: document the minimum Linux kernel level The change associated with gerrit #14300 removed support for older Linux kernels (2.6.10 and earlier). The commit 'Import of code from autoconf-archive' (d8205bbb4) introduced a check for Autoconf 2.64. Autoconf 2.64 was released in 2009. The commit 'regen.sh: Use libtoolize -i, and .gitignore generated build-tools' (a7cc505d3) introduced a dependency on libtool's '-i' option. Libtool supported the '-i' option with libtool 1.9b in 2004. Update the INSTALL instructions to document a minimum Linux kernel level and the minimum levels for autoconf and libtool. Notes: RHEL4 (EOL in 2017) had a 2.6.9 kernel and RHEL5 has a 2.6.18 kernel. RHEL5 has libtool 1.5.22 and autoconf 2.59, RHEL6 has libtool 2.2.6 and autoconf 2.63, and RHEL7 has libtool 2.4.2 and autoconf 2.69. Reviewed-on: https://gerrit.openafs.org/14305 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 16bae98ec525fa013514fb46398df682d7637ae0) Change-Id: I7aaf434928204df77851dd2d651d43b86f5b53d2 Reviewed-on: https://gerrit.openafs.org/14331 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit fee39617c350623dc659e7a21287a1791bdff5d2 Author: Andrew Deason Date: Wed Apr 1 22:59:38 2020 -0500 vos: Print "done" in non-verbose 'vos remsite' Currently, 'vos remsite' always prints the message "Deleting the replication site for volume %lu ...", and then calls VDONE if the operation is successful. VDONE prints the trailing "done", but only if -verbose is turned on, and so if -verbose is not specified, the output of 'vos remsite' looks broken: $ vos remsite fs1 vicepa vol.foo Deleting the replication site for volume 1234 ...Removed replication site fs1 /vicepa for volume vol.foo To fix this, unconditionally print the trailing "done", instead of going through VDONE, so 'vos remsite' output now looks like this: $ vos remsite fs1 vicepa vol.foo Deleting the replication site for volume 1234 ... done Removed replication site fs1 /vicepa for volume vol.foo Reviewed-on: https://gerrit.openafs.org/14127 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit f16d40ad26df3ec871f8c73952594ad2e723c9b4) Change-Id: I4cd7cb2156391004e57cd42437d7174a6bd70992 Reviewed-on: https://gerrit.openafs.org/14311 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ff5b64d074376992d0be02e19b4da789c20d6bab Author: Marcio Barbosa Date: Thu Feb 13 00:39:00 2020 -0300 vos: take RO volume offline during convertROtoRW The vos convertROtoRW command converts a RO volume into a RW volume. Unfortunately, the RO volume in question is not set as "out of service" during this process. As a result, accesses to the volume being converted can leave volume objects in an inconsistent state. Consider the following scenario: 1. Create a volume on host_b and add replicas on host_a and host_b. $ vos create host_b a vol_1 $ vos addsite host_b a vol_1 $ vos addiste host_a a vol_1 2. Mount the volume: $ fs mkmount /afs/.mycell/vol_1 vol_1 $ vos release vol_1 $ vos release root.cell 3. Shutdown dafs on host_b: $ bos shutdown host_b dafs 4. Remove RO reference to host_b from the vldb: $ vos remsite host_b a vol_1 5. Attach the RO copy by touching it: $ fs flushall $ ls /afs/mycell/vol_1 6. Convert RO copy to RW: $ vos convertROtoRW host_a a vol_1 Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving the volume object for the RO copy set as VOL_STATE_ATTACHED (on success, this volume should be set as VOL_STATE_DELETED). 7. Add replica on host_a: $ vos addsite host_a a vol_1 8. Wait until the "inUse" flag of the RO entry is cleared (or force this to happen by attaching multiple volumes). 9. Release the volume: $ vos release vol_1 Failed to start transaction on volume 536870922 Volume not attached, does not exist, or not on line Error in vos release command. Volume not attached, does not exist, or not on line To fix this problem, take the RO volume offline during the vos convertROtoRW operation. Reviewed-on: https://gerrit.openafs.org/14066 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 32d35db64061e4102281c235cf693341f9de9271) Change-Id: Ie4cfab2f04a8859ddfcaece371198ac544066770 Reviewed-on: https://gerrit.openafs.org/14310 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 696d9ce83e3556bda2d3945326937c63dd3560ed Author: Michael Meffie Date: Tue Apr 19 20:46:33 2016 -0400 ubik: positional io for db reads and writes The ubik library was written before positional i/o was available and issues an lseek system call for each database file read and write. This change converts the ubik database accesses to use positional i/o on platforms where pread and pwrite are available, in order to reduce system call load. The new inline uphys_pread and uphys_pwrite functions are supplied on platforms which do not supply pread and pwrite. These functions fall back to non-positional i/o. If these symbols are present in the database server binary then the server process will continue to call lseek before each read and write access of the database file. This change does not affect the whole-file database synchronization done by ubik during database recovery (via the DISK_SendFile and DISK_GetFile RPCs), which still uses non-positional i/o. However, that code does not share file descriptors with the phys.c code, so there is no possibility of mixing positional and non-positional i/o on the same FDs. Reviewed-on: https://gerrit.openafs.org/12272 Reviewed-by: Andrew Deason Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit f62fb17b3cf1c886f8cfc2fabe9984070dd3eec4) Change-Id: Iccc8f749c89659f4acebd74a1115425f69610ba8 Reviewed-on: https://gerrit.openafs.org/14142 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Marcio Brito Barbosa Reviewed-by: Stephan Wiesand commit fffd6e07c87e36cd9a4a36858c3df0c282622195 Author: Michael Meffie Date: Wed Apr 20 18:17:16 2016 -0400 ubik: remove unnecessary lseeks in uphys_open The ubik database file access layer has a file descriptor cache to avoid reopening the database file on each file access. However, the file offset is reset with lseek on each and every use of the cached file descriptor, and the file offset is set twice when reading or writing data records. This change removes unnecessary and duplicate lseek system calls to reduce the system call load. Reviewed-on: https://gerrit.openafs.org/12271 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 6892bfbd701899281b34ee337637d438c7d8f8c6) Change-Id: I5ea7857796d94eb5b659d868e79b9fea2411f301 Reviewed-on: https://gerrit.openafs.org/14141 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Marcio Brito Barbosa Reviewed-by: Stephan Wiesand commit 438bc2c4caf96485e12eda9e7591fc4bd887ebad Author: Andrew Deason Date: Thu Nov 9 12:47:57 2017 -0600 asetkey: Add new 'delete' command variants The current 'delete' command from asetkey only lets the user delete old-style rxkad keys. Add a couple of new variants to allow specifying the key type and subtype, so the user can delete specific key types and enctypes if they want. Reviewed-on: https://gerrit.openafs.org/12767 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 5120409cc998284f2fb0467c2f88030976140341) Change-Id: I8c762839b50f4faf5e583fb5c510bf2ff9dd2259 Reviewed-on: https://gerrit.openafs.org/14293 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 1c395cd1bcf5770f70dce36ef29f9bd7ba98acaa Author: Kailas Zadbuke Date: Thu May 7 23:55:39 2020 -0400 salvaged: Fix "-parallel all" parsing In salavageserver -parallel option takes "all" argument. However the code does not parse the numeric part correctly. Due to this, only single instance of salvageserver process was running even if we provide the larger number with "all" argument. With this fix, numeric part of "all" argument will be parsed correctly and will start required number of salvageserver instances. Reviewed-on: https://gerrit.openafs.org/14201 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 4512d04a9b721cd9052c0e8fe026c93faf6edb9e) Change-Id: I8910fb514986a404b22256e8a514955a684c8a27 Reviewed-on: https://gerrit.openafs.org/14285 Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Kailas Zadbuke Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 38f7e123c33c1c11eb275e0619080ee874244afd Author: Cheyenne Wills Date: Tue Jun 16 15:20:20 2020 -0600 tests: Use usleep instead of nanosleep Commit "Build tests by default" 68f406436cc21853ff854c514353e7eb607cb6cb changes the build so tests are always built. On Solaris 10 the build fails because nanosleep is in librt, which we do not link against. Replace nanosleep with usleep. This avoids introducing extra configure tests just for Solaris 10. Note that with Solaris 11 nanosleep was moved from librt to libc, the standard C library. Reviewed-on: https://gerrit.openafs.org/14244 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 22a66e7b7e1d73437a8c26c2a1b45bc4ef214e77) Change-Id: Ic24c5a149451955b5c130e7b36cec27e02688d83 Reviewed-on: https://gerrit.openafs.org/14291 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 264d6b786c2fd0aff0e4abe835e42868f936afce Author: Andrew Deason Date: Tue Mar 24 11:59:48 2020 -0500 tests: Wait for server start in auth/superuser-t The auth/superuser-t test runs an Rx server and client in two child processes. If the client process tries to contact the server before the server has started listening on its port, some tests involving RPCs can fail (notably test 39, "Can run a simple RPC"). Normally if we try to contact a server that's not there, Rx will try resending its packets a few times, but on Linux with AFS_RXERRQ_ENV, if the port isn't open at all, we can get an ICMP_PORT_UNREACH error, which causes the relevant Rx call to die immediately with RX_CALL_DEAD. This means that if the auth/superuser-t client is only just a bit faster than the server starting up, tests can fail, since the server's port is not open yet. To avoid this, we can wait until the server's port is open before starting the client process. To do this, have the server process send a SIGUSR1 to the parent after rx_Init() is called, and have the parent process wait for the SIGUSR1 (waiting for a max of 5 seconds before failing). This should guarantee that the server's port will be open by the time the client starts running. Note that before commit 086d1858 (LINUX: Include linux/time.h for linux/errqueue.h), AFS_RXERRQ_ENV was mistakenly disabled on Linux 3.17+, so this issue was probably not possible on recent Linux before that commit. Reviewed-on: https://gerrit.openafs.org/14109 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Cheyenne Wills (cherry picked from commit 66d0f91791695ac585f0511d0dadafd4e570b1bf) Change-Id: Ia6c06ca9a05e33b3bc35238d9c0d18e7ff339438 Reviewed-on: https://gerrit.openafs.org/14290 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit eaa552d27074cd7e1c862d606916b063e6d89a27 Author: Andrew Deason Date: Tue Dec 31 12:04:48 2019 -0600 tests: Introduce afstest_GetProgname Currently, in tests/volser/vos-t.c we call afs_com_err as "authname-t", which is clearly a mistake during some code refactoring (introduced in commit 2ce3fdc5, "tests: Abstract out code to produce a Ubik client"). We could just change this to "vos-t", but instead of specifying constant strings everywhere, change this to figure out what the current command is called, and just use that. Put this code into a new function, afstest_GetProgname, and convert existing tests to use that instead of hard-coding the program name given to afs_com_err. Reviewed-on: https://gerrit.openafs.org/13991 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit a21a2f8edb79d6190976e920a9a90d0878411146) Change-Id: I3d410d6de132f8a0fffeb9cce32a912fe3bbdc20 Reviewed-on: https://gerrit.openafs.org/14289 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit fe57174d84cab19a13eea9a8f31f0ac71c8cf838 Author: Cheyenne Wills Date: Wed Aug 5 09:23:36 2020 -0600 butc: fix int to float conversion warning Building with clang-10 results in 2 warnings/errors associated with with trying to convert 0x7fffffff to a floating point value. tcmain.c:240:18: error: implicit conversion from 'int' to 'float' changes value from 2147483647 to 2147483648 [-Werror, -Wimplicit-int-float-conversion] if ((total > 0x7fffffff) || (total < 0)) /* Don't go over 2G */ and the same conversion warning on the statement on the following line: total = 0x7fffffff; Use floating point and decimal constants instead of the hex constants. For the test, use 2147483648.0 which is cleanly represented by a float. Change the comparison in the test from '>' to '>='. If the total value exceeds 2G, just assign the max value directly to the return variable. Reviewed-on: https://gerrit.openafs.org/14277 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 37b55b30c65d0ab8c8eaabfda0dbd90829e2c46a) Change-Id: I16e0acd893049b01a2c5e4c7e71de3fa40e28d3e Reviewed-on: https://gerrit.openafs.org/14299 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit e7902252f15acfc28453c531f6fa3b29c9c91b92 Author: Cheyenne Wills Date: Fri Aug 21 10:37:51 2020 -0600 LINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL Linux-5.9-rc1 commit 'fs: remove the HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL defines' (4e24566a) removed the two referenced macros from the kernel. The support for unlocked_ioctl and compat_ioctl were introduced in Linux 2.6.11. Remove references to HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL using the assumption that they were always defined. Notes: With this change, building against kernels 2.6.10 and older will fail. RHEL4 (EOL in March 2017) used a 2.6.9 kernel. RHEL5 uses a 2.6.18 kernel. In linux-2.6.33-rc1 the commit messages for "staging: comedi: Remove check for HAVE_UNLOCKED_IOCTL" (00a1855c) and "Staging: comedi: remove check for HAVE_COMPAT_IOCTL" (5d7ae225) both state that all new kernels have support for unlocked_ioctl/compat_ioctl so the checks can be removed along with removing support for older kernels. Reviewed-on: https://gerrit.openafs.org/14300 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 13a49aaf0d5c43bce08135edaabb65587e1a8031) Change-Id: I6dc5ae5b32031641f4a021a31630390a91d834fe Reviewed-on: https://gerrit.openafs.org/14315 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 99232fa48020bde90f6b245da4374bc63399654f Author: Cheyenne Wills Date: Wed Aug 5 09:19:02 2020 -0600 afs: Set AFS_VFSFSID to a numerical value Currently when UKERNEL is defined, AFS_VFSFSID is always set to AFS_MOUNT_AFS, which is a string for many platforms for UKERNEL. Update src/afs/afs.h to insure that the define for AFS_VFSFSID is a numeric value when building UKERNEL. Clean up the preprocessor indentation in src/afs/afs.h in the area around the AFS_VFSFSID defines. Thanks to adeason@sinenomine.net for pointing out a much easier solution for resolving this problem. Reviewed-on: https://gerrit.openafs.org/14279 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 446457a1240b88fd94fc34ff5715f2b7f2f3ef12) Change-Id: Ic0f9c2f1f4baeb9f99da19e1187f1bc9f5d7f824 Reviewed-on: https://gerrit.openafs.org/14297 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 7e2a62fb594a7713a5c694b9e0401b5e3c2648c8 Author: Cheyenne Wills Date: Wed Aug 5 09:18:49 2020 -0600 afs: Avoid using logical OR when setting f_fsid Building with clang-10 produces the warning/error message warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] for the expression abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID; The message is because a logical OR '||' is used instead of a bitwise OR '|'. The result of this expression will always set the f_fsid member to a 1 and not the intended value of AFS_VFSMAGIC combined with AFS_VFSFSID. Update the expression to use a bitwise OR instead of the logical OR. Note: This will change value stored in the f_fsid that is returned from statfs. Using a logical OR has existed since OpenAFS 1.0 for hpux/solaris and in UKERNEL since OpenAFS 1.5 with the commit 'UKERNEL: add uafs_statvfs' b822971a. Reviewed-on: https://gerrit.openafs.org/14292 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit c56873bf95f6325b70e63ed56ce59a3c6b2b753b) Change-Id: I2e3fe6a84ef6ce73fff933f137d4806efefa5949 Reviewed-on: https://gerrit.openafs.org/14298 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit fc32922236122b9013ed9bdedda8c54c2e8c75d8 Author: Andrew Deason Date: Fri May 1 15:02:08 2020 -0500 vlserver: Return error when growing beyond 2 GiB In the vlserver, when we add a new vlentry or extent block, we grow the VLDB by doing something like this: vital_header.eofPtr += sizeof(item); Since we don't check for overflow, and all of our offset-related variables are signed 32-bit integers, this can cause some odd behavior if we try to grow the database to be over 2 GiB in size. To avoid this, change the two places in vlserver code that grow the database to use a new function, grow_eofPtr(), which checks for 31-bit overflow. If we are about to overflow, log a message and return an error. See the following for a specific example of our "odd behavior" when we overflow the 2 GiB limit in the VLDB: With 1 extent block, we can create 14509076 vlentries successfully. On the 14509077th vlentry, we'll attempt to write the entry to offset 2147483560 (0x7FFFFFA8). Since a vlentry is 148 bytes long, we'll write all the way through offset 2147483707 (0x8000003B), which is over the 31-bit limit. In the udisk subsystem, this results in writing to page numbers 2097151, and -2097152 (since our ubik pages are 1k, and going over the 31-bit limit causes us to treat offsets as negative). These pages start at physical offsets 2147482688 (0x7FFFFC40) and -2147483584 (-0x7FFFFFC0) in our vldb.DB0 (where offset is page*1024+64). Modifying each of these pages involves reading in the existing page first, modifying the parts we are changing, and writing it back. This works just fine for 2097151, but of course fails for -2097152. The latter fails in DReadBuffer when eventually our pread() fails with EINVAL, and causes ubik to log the message: Ubik: Error reading database file: errno=22 But when DReadBuffer fails, DReadBufferForWrite assumes this is due to EOF, and just creates a new buffer for the given page (DNewBuffer). So, the udisk_write() call ultimately succeeds. When we go to flush the dirty data to disk when committing the transaction, after we have successfully written the transaction log, DFlush() fails for the -2097152 page when the pwrite() call eventually fails with EINVAL, causing ubik to panic, logging the messages: Ubik PANIC: Writing Ubik DB modifications When the vlserver gets restarted by bosserver, we then process the transaction log, and perform the operations in the log before starting up (ReplayLog). The log records the actual data we wrote, not split into pages, and the log-replaying code writes directly to the db usying uphys_write instead of udisk_write. So, because of this, the write actually succeeds when replaying the log, since we just write 148 bytes to offset 2147483624 (0x7FFFFFE8), and no negative offsets are used. The vlserver will then be able to run, but will be unable to read that newly-created vlentry, since it involves reading a ubik page beyond the 31-bit boundary. That means trying to lookup that entry will fail with i/o errors, and as well as any entry on the same hash chains as the new entry (since the new entry will be added to the head of the hash chain). Listing all entries in the database will also just show an empty database, since our vital_header.eofPtr will be negative, and we determine EOF by comparing our current blockindex to the value in eofPtr. Reviewed-on: https://gerrit.openafs.org/14180 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Cheyenne Wills (cherry picked from commit d01398731550b8a93b293800642c3e1592099114) Change-Id: I72302a8c472b3270e99e58a573f5cf25dd34b9c5 Reviewed-on: https://gerrit.openafs.org/14288 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 03979eaa174de0cff188af451806fb7ae10d3a62 Author: Andrew Deason Date: Tue Apr 7 13:15:31 2020 -0500 vlserver: Correctly pad nvlentry for "O" RPCs For our old-style "O" RPCs (e.g. VL_CreateEntry, instead of VL_CreateEntryN), vlserver calls vldbentry_to_vlentry to convert to the internal 'struct nvlentry' format. After all of the sites have been copied to the internal format, we fill the remaining sites by setting the serverNumber to BADSERVERID. For nvldbentry_to_vlentry, we do this for NMAXNSERVERS sites, but for vldbentry_to_vlentry, we do this for OMAXNSERVERS. The thing is, both functions are filling in entries for a 'struct nvlentry', which has NMAXNSERVERS 'serverNumber' entries. So for vldbentry_to_vlentry, we are skipping setting the last few sites (specifically, NMAXNSERVERS-OMAXNSERVERS = 13-8 = 5). This can easily cause our O-style RPCs to write out entries to disk that have uninitialized sites at the end of the array. For example, an entry with one site should have server numbers that look like this: serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255} That is, one real serverid (a '1' here), followed by twelve BADSERVERIDs. But for a VL_CreateEntry call, the 'struct nvlentry' is zeroed out before vldbentry_to_vlentry is called, and so the server numbers in the written entry look like this: serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0} That is, one real serverid (a '1' here), followed by seven BADSERVERIDs, followed by five '0's. Most of the time, this is not noticeable, since our code that reads in entries from disk stops processing sites when we encounter the first BADSERVERID site (see vlentry_to_nvldbentry). However, if the entry has 8 sites, then none of the entries will contain BADSERVERID, and so we will actually process the trailing 5 bogus sites. This would appear as 5 extra volume sites for a volume, most likely all for the same server. For VL_CreateEntry, the vlentry struct is always zeroed before we use it, so the trailing sites will always be filled with 0. For VL_ReplaceEntry, the trailing sites will be unchanged from whatever was read in from the existing disk entry. To fix this, just change the relevant loop to go through NMAXNSERVERS entries, so we actually go to the end of the serverNumber (et al) array. This may appear similar to commit ddf7d2a7 (vlserver: initialize nvlentry elements after read). However, that commit fixed a case involving the old vldb database format (which hopefully is not being used). This commit fixes a case where we are using the new vldb database format, but with the old RPCs, which may still be used by old tools. Reviewed-on: https://gerrit.openafs.org/14139 Tested-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 7e41ee0bd50d39a356f0435ff370a0a7be40306f) Change-Id: I68ecc41e7268efd0424e6c129aa914cd04115b59 Reviewed-on: https://gerrit.openafs.org/14287 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 986ee1fd422d1608553af5a6a02bd60349b864ac Author: Cheyenne Wills Date: Fri Jun 19 08:01:14 2020 -0600 afs: Avoid panics on failed return from afs_CFileOpen afs_CFileOpen is a macro that invokes the open "method" of the afs_cacheOps structure, and for disk caches the osi_UFSOpen function is used. Currently osi_UFSOpen will panic if there is an error encountered while opening a file. Prepare to handle osi_UFSOpen function returning a NULL instead of issuing a panic (future commit). Update callers of afs_CFileOpen to test for an error and to return an error instead of issuing a panic. While this commit eliminates some panics, it does not address some of the more complex cases associated with errors from afs_CFileOpen. Reviewed-on: https://gerrit.openafs.org/14241 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit d2d27f975df13c3833898611dacff940a5ba3e2a) Change-Id: Ia30711748b3cffd56eb3120961aa1747dfae0f23 Reviewed-on: https://gerrit.openafs.org/14286 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit a00fe9fd4253b2436ae649b05b329d0d52c8b6f6 Author: Yadavendra Yadav Date: Thu Mar 5 07:21:55 2020 +0000 LINUX: Initialize CellLRU during osi_Init When OpenAFS kernel module gets loaded, it will create certain entries in "proc" filesystem. One of those entries is "CellServDB", in case we read "/proc/fs/openafs/CellServDB" without starting "afsd" it will result in crash with NULL pointer deref. The reason for crash is CellLRU has not been initialized yet (since "afsd" is not started) i.e afs_CellInit is not yet called, because of this "next" and "prev" pointers will be NULL. Inside "c_start()" we do not check for NULL pointer while traversing CellLRU and this causes crash. To avoid this initialize CellLRU during module intialization. Reviewed-on: https://gerrit.openafs.org/14093 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 8d90a9d27b0ef28ddcdd3eb041c8a9d019b84b50) Change-Id: I9ed97d3751943331c9d9bc9dfc73acc24231187b Reviewed-on: https://gerrit.openafs.org/14284 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 6824d45c2ab83e52350c3f366e4cb6f1eb263088 Author: Kailas Zadbuke Date: Wed Jun 3 15:44:08 2020 +0530 util: Handle serverLogMutex lock across forks If a process forks when another thread has serverLogMutex locked, the child process inherits the locked serverLogMutex. This causes a deadlock when code in the child process tries to lock serverLogMutex, since we can never unlock serverLogMutex because the locking thread no longer exists. This can happen in the salvageserver, since the salvageserver locks serverLogMutex in different threads, and forks to handle salvage jobs. To avoid this deadlock, we register handlers using pthread_atfork() so that the serverLogMutex will be held during the fork. The fork will be blocked until the worker thread releases the serverLogMutex. Hence the serverLogMutex will be held until the fork is complete and it will be released in the parent and child threads. Thanks to Yadavendra Yadav(yadayada@in.ibm.com) for working with me on this issue. Reviewed-on: https://gerrit.openafs.org/14239 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit e44d6441c8786fdaaa1fad1b1ae77704c12f7d60) Change-Id: I09c04c0bd99b10433857ccdaeb4ee6a4cd50f768 Reviewed-on: https://gerrit.openafs.org/14283 Tested-by: BuildBot Reviewed-by: Kailas Zadbuke Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit 179a418ea5063785a23e4faf35134f063a6f3e1c Author: Andrew Deason Date: Fri Mar 13 13:00:35 2020 -0500 LINUX: Properly revert creds in osi_UFSTruncate Commit cd3221d3 (Linux: use override_creds when available) caused us to force the current process's creds to the creds of afsd during osi_file.c file ops, to avoid access errors in some cases. However, in osi_UFSTruncate, one code path was missed to revert our creds back to the original user's creds: when the afs_osi_Stat call fails or deems the truncate unnecessary. In this case, the calling process keeps the creds for afsd after osi_UFSTruncate returns, causing our subsequent access-checking code to think that the current process is in the same context as afsd (typically uid 0 without a pag). This can cause the calling process to appear to transiently have the same access as non-pag uid 0; typically this will be unauthenticated access, but could be authenticated if uid 0 has tokens. To fix this, modify the early return in osi_UFSTruncate to go through a 'goto done' destructor instead, and make sure we revert our creds in that destructor. Thanks to cwills@sinenomine.net for finding and helping reproduce the issue. Reviewed-on: https://gerrit.openafs.org/14098 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Jeffrey Hutzelman Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills (cherry picked from commit 57b4f4f9be1e25d5609301c10f717aff32aef676) Change-Id: I714eb2dea9645ffe555f26b5d69707a7afbe8d81 Reviewed-on: https://gerrit.openafs.org/14099 Reviewed-by: Andrew Deason Reviewed-by: Jeffrey Hutzelman Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit ee578e92d9f810d93659a9805d0c12084fe2bb95 Author: Jeffrey Hutzelman Date: Thu May 2 16:02:47 2019 -0400 Linux: use override_creds when available Linux may perform some access control checks at the time of an I/O operation, rather than relying solely on checks done when the file is opened. In some cases (e.g. AppArmor), these checks are done based on the current tasks's creds at the time of the I/O operation, not those used when the file was open. Because of this, we must use override_creds() / revert_creds() to make sure we are using privileged credentials when performing I/O operations on cache files. Otherwise, cache I/O operations done in the context of a task with a restrictive AppArmor profile will fail. Reviewed-on: https://gerrit.openafs.org/13751 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit cd3221d3532a28111ad22d4090ec913cbbff40da) Change-Id: I8955ff6150462fecba9a10a8f99bce9ee8163435 Reviewed-on: https://gerrit.openafs.org/14082 Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Jeffrey Hutzelman Reviewed-by: Stephan Wiesand commit facff58b840a47853592510617ba7a1da2e3eaa9 Author: Cheyenne Wills Date: Fri Jul 3 10:35:06 2020 -0600 LINUX 5.8: use lru_cache_add With Linux-5.8-rc1 commit 'mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()' (6058eaec), the lru_cache_add_file function is removed since it was functionally equivalent to lru_cache_add. Replace lru_cache_add_file with lru_cache_add. Introduce a new autoconf test to determine if lru_cache_add is present For reference, the Linux changes associated with the lru caches: __pagevec_lru_add introduced before v2.6.12-rc2 lru_cache_add_file introduced in v2.6.28-rc1 __pagevec_lru_add_file replaces __pagevec_lru_add in v2.6.28-rc1 vmscan: split LRU lists into anon & file sets (4f98a2fee) __pagevec_lru_add removed in v5.7 with a note to use lru_cache_add_file mm/swap.c: not necessary to export __pagevec_lru_add() (bde07cfc6) lru_cache_add_file removed in v5.8 mm: fold and remove lru_cache_add_anon() and lru_cache_add_file() (6058eaec) lru_cache_add exported mm: fold and remove lru_cache_add_anon() and lru_cache_add_file() (6058eaec) Openafs will use: lru_cache_add on 5.8 kernels lru_cache_add_file from 2.6.28 through 5.7 kernels __pagevec_lru_add/__pagevec_lru_add_file on pre 2.6.28 kernels Reviewed-on: https://gerrit.openafs.org/14249 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Yadavendra Yadav Reviewed-by: Benjamin Kaduk (cherry picked from commit 7d85ce221d6ccc19cf76ce7680c74311e4ed2632) Change-Id: Iba6ef4441687dbf60d227a708e2a032c2c0dc79f Reviewed-on: https://gerrit.openafs.org/14269 Tested-by: BuildBot Reviewed-by: Michael Laß Reviewed-by: Stephan Wiesand commit 335f37be13d2ff954e4aeea617ee66502170805e Author: Cheyenne Wills Date: Fri Jul 3 10:34:42 2020 -0600 LINUX 5.8: do not set name field in backing_dev_info Linux-5.8-rc1 commit 'bdi: remove the name field in struct backing_dev_info' (1cd925d5838) Do not set the name field in the backing_dev_info structure if it is not available. Uses an existing config test 'STRUCT_BACKING_DEV_INFO_HAS_NAME' Note the name field in the backing_dev_info structure was added in Linux-2.6.32 Reviewed-on: https://gerrit.openafs.org/14248 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit d8ec294534fcdee77a2ccd297b4b167dc4d5573d) Change-Id: I3d9e18092db998a4c4f26bd63ee3b75383a53d4c Reviewed-on: https://gerrit.openafs.org/14268 Tested-by: BuildBot Reviewed-by: Michael Laß Reviewed-by: Stephan Wiesand commit d7fc5bf9bf031089d80703c48daf30d5b15a80ca Author: Cheyenne Wills Date: Fri Jul 3 10:33:51 2020 -0600 LINUX 5.8: Replace kernel_setsockopt with new funcs Linux 5.8-rc1 commit 'net: remove kernel_setsockopt' (5a892ff2facb) retires the kernel_setsockopt function. In prior kernel commits new functions (ip_sock_set_*) were added to replace the specific functions performed by kernel_setsockopt. Define new config test 'HAVE_IP_SOCK_SET' if the 'ip_sock_set' functions are available. The config define 'HAVE_KERNEL_SETSOCKOPT' is no longer set in Linux 5.8. Create wrapper functions that replace the kernel_setsockopt calls with calls to the appropriate Linux kernel function(s) (depending on what functions the kernel supports). Remove the unused 'kernel_getsockopt' function (used for building with pre 2.6.19 kernels). For reference Linux 2.6.19 introduced kernel_setsockopt Linux 5.8 removed kernel_setsockopt and replaced the functionality with a set of new functions (ip_sock_set_*) Reviewed-on: https://gerrit.openafs.org/14247 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit c48072b9800759ef1682b91ff1e962f6904a2594) Change-Id: I2724fad06b1882149d2066d13eced55eff5ee695 Reviewed-on: https://gerrit.openafs.org/14267 Tested-by: BuildBot Reviewed-by: Michael Laß Reviewed-by: Stephan Wiesand commit 0f67e733e82a9001f3f9253c5e1880be845d537b Author: Cheyenne Wills Date: Thu Apr 2 13:27:50 2020 -0600 LINUX: Include linux/time.h for linux/errqueue.h The configuration test for errqueue.h fails with an undefined structure error on a Linux 3.17 (or higher) system. This prevents setting HAVE_LINUX_ERRQUEUE_H, which is used to define AFS_RXERRQ_ENV. Linux commit f24b9be5957b38bb420b838115040dc2031b7d0c (net-timestamp: extend SCM_TIMESTAMPING ancillary data struct) - which was picked up in linux 3.17 added a structure that uses the timespec structure. After this commit, we need to include linux/time.h to pull in the definition of the timespec struct. Reviewed-on: https://gerrit.openafs.org/13950 Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 086d185872da5f19447cf5ec7846e7ce5104563f) Change-Id: I67d01b11c5ea95b8b87832fc833f8fc850ade684 Reviewed-on: https://gerrit.openafs.org/14130 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand commit 5a14bd0abe83b580f0cc7a200ae963399ab7de5f Author: Cheyenne Wills Date: Tue May 26 12:11:28 2020 -0600 vol: Fix format-truncation warning with gcc-10.1 Building with gcc-10.1 produces a warning (error if --enable-checking) in vol-salvage.c error: ‘%s’ directive output may be truncated writing up to 755 bytes into a region of size 255 [-Werror=format-truncation=] 809 | snprintf(inodeListPath, 255, "%s" OS_DIRSEP "salvage.inodes.%s.%d", tdir, name, Use strdup/asprintf to allocate the buffer dynamically instead of using a buffer with a hardcoded size. Reviewed-on: https://gerrit.openafs.org/14207 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit d73680c5f70ee5aeb634a9ec88bf1097743d0f76) Change-Id: I8d3bf244a70f723f585738905deea7ddfb1bb862 Reviewed-on: https://gerrit.openafs.org/14232 Reviewed-by: Mark Vitale Tested-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit d5fc5283e91ea94a67df8364a5b8bf8970ffe934 Author: Michael Meffie Date: Mon Oct 9 22:16:09 2017 -0400 afsmonitor: remove unused LWP_WaitProcess Remove the unimplemented once-only flag and the unused LWP_WaitProcess call. Reviewed-on: https://gerrit.openafs.org/12745 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 7c27365ea24aed5787f6fc03f30f6085c78ece51) Change-Id: I3b61f9fb4f45564304b0e35878d3535a10e31d02 Reviewed-on: https://gerrit.openafs.org/14226 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit a2eec64374d6b754b29c509b554573cb6e53eb46 Author: Cheyenne Wills Date: Fri May 22 12:16:48 2020 -0600 Avoid duplicate definitions of globals GCC 10 changed a default flag from -fcommon to -fno-common. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 for some background. The change in gcc 10 results in build link-time errors. For example: ../../src/xstat/.libs/liboafs_xstat_cm.a(xstat_cm.o):(.bss+0x2050): multiple definition of `numCollections'; Ensure that only one definition for global data objects exist and change references to use "extern" as needed. To ensure that future changes do not introduce duplicated global definitions, add the -fno-common flag to XCFLAGS when using the configure --enable-checking setting. [cwills@sinenomine.net: Note for 1.8.x: renamed terminationEvent to cm_terminationEvent/fs_terminationEvent instead of deleting it.] Reviewed-on: https://gerrit.openafs.org/14106 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 0e2072ae386d4111bef161eb955964b649c31386) Change-Id: I54ca61d372cf763e4a28c0b0829ea361219f6203 Reviewed-on: https://gerrit.openafs.org/14217 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 278592ef2d766c77de821b9da80359f24fec5b62 Author: Mark Vitale Date: Mon Jan 27 12:26:41 2020 -0500 uss: more gcc9 truncation warning appeasement uss_procs_PickADir needs a larger buffer to avoid a truncation warning. While here, replace some magic numbers with existing symbols. Reviewed-on: https://gerrit.openafs.org/14049 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit 6c54bc9e121b923ec5fdd60ee510171987e55017) Change-Id: I5cb76a8a9b2a9b342a1ddae2f41ecab82f762326 Reviewed-on: https://gerrit.openafs.org/14140 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Stephan Wiesand commit ff07fa706e00f6dde13c58588d2f75e7fc26ecf5 Author: Michael Meffie Date: Fri Jan 10 09:06:38 2020 -0500 tests: do not resolve addresses in vos/vl test The vos-t test adds a set of 10.* test addresses to a test vlserver and runs vos to read them back. When the test is run in an environment where hosts have been assigned in the 10.* internal network, vos will resolve the addresses to hostnames and the test fails. Pass the -noresolve option to vos for this test when checking for the expected list of addresses. Example test output before this commit: ./vos-t ... # seen: 10.0.0.0 10.0.0.1 myhost.example.com 10.0.0.3 ... not ok 5 - vos output matches Reviewed-on: https://gerrit.openafs.org/14020 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit dcf44ab5fc5c1f5e2e759ea4b6156f7e1faa4b7a) Change-Id: Ie2a6d97070fe47886a1ccf8c0ddf03012f805beb Reviewed-on: https://gerrit.openafs.org/14105 Tested-by: BuildBot Reviewed-by: Stephan Wiesand