From 9e626f9fc0169ba784843e80a39eef06907889ddb98910152f9f2abe7a7ceba8 Mon Sep 17 00:00:00 2001 From: Christof Hanke Date: Wed, 4 Aug 2021 07:22:38 +0000 Subject: [PATCH] Accepting request 910047 from home:hauky:branches:filesystems - update to openafs version 1.8.8 - remove linux-kmp.patch. Not required at the minute. OBS-URL: https://build.opensuse.org/request/show/910047 OBS-URL: https://build.opensuse.org/package/show/filesystems/openafs?expand=0&rev=82 --- ChangeLog | 5709 ++++++++++++++++++++++++++++++ RELNOTES-1.8.7 | 11 - RELNOTES-1.8.8 | 200 ++ linux-kmp.patch | 1573 -------- openafs-1.8.7-doc.tar.bz2 | 3 - openafs-1.8.7-doc.tar.bz2.md5 | 1 - openafs-1.8.7-doc.tar.bz2.sha256 | 1 - openafs-1.8.7-src.tar.bz2 | 3 - openafs-1.8.7-src.tar.bz2.md5 | 1 - openafs-1.8.7-src.tar.bz2.sha256 | 1 - openafs-1.8.8-doc.tar.bz2 | 3 + openafs-1.8.8-doc.tar.bz2.md5 | 1 + openafs-1.8.8-doc.tar.bz2.sha256 | 1 + openafs-1.8.8-src.tar.bz2 | 3 + openafs-1.8.8-src.tar.bz2.md5 | 1 + openafs-1.8.8-src.tar.bz2.sha256 | 1 + openafs.changes | 6 + openafs.spec | 8 +- 18 files changed, 5928 insertions(+), 1599 deletions(-) delete mode 100644 RELNOTES-1.8.7 create mode 100644 RELNOTES-1.8.8 delete mode 100644 linux-kmp.patch delete mode 100644 openafs-1.8.7-doc.tar.bz2 delete mode 100644 openafs-1.8.7-doc.tar.bz2.md5 delete mode 100644 openafs-1.8.7-doc.tar.bz2.sha256 delete mode 100644 openafs-1.8.7-src.tar.bz2 delete mode 100644 openafs-1.8.7-src.tar.bz2.md5 delete mode 100644 openafs-1.8.7-src.tar.bz2.sha256 create mode 100644 openafs-1.8.8-doc.tar.bz2 create mode 100644 openafs-1.8.8-doc.tar.bz2.md5 create mode 100644 openafs-1.8.8-doc.tar.bz2.sha256 create mode 100644 openafs-1.8.8-src.tar.bz2 create mode 100644 openafs-1.8.8-src.tar.bz2.md5 create mode 100644 openafs-1.8.8-src.tar.bz2.sha256 diff --git a/ChangeLog b/ChangeLog index 4efb3b5..17d6ce9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,2627 @@ +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 @@ -129,3 +2753,3088 @@ Date: Thu Jan 14 09:41:39 2021 -0500 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 diff --git a/RELNOTES-1.8.7 b/RELNOTES-1.8.7 deleted file mode 100644 index ad14d65..0000000 --- a/RELNOTES-1.8.7 +++ /dev/null @@ -1,11 +0,0 @@ - User-Visible OpenAFS Changes - -OpenAFS 1.8.7 - - All platforms - - * Fix initial Rx Connection ID (CID) generation. - Remove stale initialization and overflow detection logic that resulted - in connection failures due to all CIDs being set to 0x80000002. - (14493, 14494, 14497) - diff --git a/RELNOTES-1.8.8 b/RELNOTES-1.8.8 new file mode 100644 index 0000000..8ba1482 --- /dev/null +++ b/RELNOTES-1.8.8 @@ -0,0 +1,200 @@ + User-Visible OpenAFS Changes + + +OpenAFS 1.8.8 + + All platforms + + * Improved documentation, diagnostics and error messages (14311 14326 + 14331 14367 14399 14419 14420 14427 14434 14436 14437 14438 14439 + 14440 14502 14516 14518 14546) + + * Build fixes, mostly for recent compilers (14217 14298 14299 14668) + + * Avoid some potential performance losses in the wire protocol (14503 + 14514) + + * Avoid client connections hanging forever when the server is + restarted while they're active (14504 14505 14506 14507) + + All server platforms + + * Avoid Rx calls getting stuck on the incoming call queue for busy + servers (14394) + + * Avoid a possible salvageserver deadlock (14283) + + * Fixed salvageserver's parsing of the "-parallel all" argument + (14285) + + * Avoid potential salvager crashes (14515 14614) + + * Fix "bos salvage -forceDAFS" when the BosConfig also contains a legacy + 'fs' bnode in addition to the 'dafs' bnode (14665) + + * Avoid erratic vlserver behaviour due to overflowing the maximum + VLDB size of 2 GB. Log a message and return an error instead (14288) + + * Fixed a ptserver issue where 'pts mem -expandgroups' failed when + supergroups were enabled (14345) (RT #135147) + + * Take read-only volumes offline while being converted to read-write + ones with "vos convertROtoRW", preventing them from ending up in an + inconsistent state when accessed during the conversion (14433) + + * Avoid inconsistent volume states due to interrupted rename operations + and other potential issues (14449 14450) + + * Add new variants to asetkey's "delete" command to allow deleting + non-des keys (14293) + + * Improved ubik performance and robustness (14141 14142 14365) + + * Fixed building the vol-bless utility, which is now also built by + default but still not installed and distributed (14601) + + * Fixed parsing of "-cores none" when bosserver is started this way + (14589) + + All client platforms + + * Avoid crashes or panics when potentially recoverable errors + during cache I/O are encountered (14286) + + * Avoid flooding servers with NAT pings, which could happen under + certain circumstances (14364) + + * Avoid possible panics during client startup or shutdown (14393 14441) + + * Avoid potential buffer overflows by one character in the "bos" client + program and in libadmin client programs (14664 14666 14698) + + * Fixed a slow kernel memory leak triggered by retrieving tokens for + userspace commands as an authenticated user (14667 14663) (RT #135238) + + * Fixed several potential problems in "aklog -keytab" (14478 14479 + 14480 14481 14482) + + * Performance improvements (14391) + + * Avoid unexpected "cold" shutdowns upon umount /afs on platforms + which should perform a "warm" shutdown by default (14610) + + * Avoid memory leaks during shutdown (14615 14616) + + * Fixed building the afscp utility, which is still not built by default + though (14627) + + Linux clients + + * Support mainline kernels up to and including 5.13 (14267 14268 14269 + 14315 14563 14564 14565) (RT #135242) + + Note that as of mainline kernel 5.13, OpenAFS currently won't build + on PowerPC due to a new ABI restriction. + + * Avoid failures of cache I/O operations in the context of tasks + restricted by security mechanisms like AppArmor (14082 14099) + + * Avoid a crash while loading the kernel module when reading from + /proc/fs/openafs/CellServDB before afsd has started (14284) + + * Avoid more possible causes of getcwd() failures (14451) + + * Restore the -setpag functionality in some older utilities like klog + (14327 14328) + + macOS + + * Added support for release 11.0 "Big Sur" (14597 14598 14605 14600) + + FreeBSD + + * Support releases 11.2, 12.1, 12.2 (14520 14537 14590) + + * Add a wide range of FBSD specific fixes and improvements (14521..36) + +OpenAFS 1.8.7 + + All platforms + + * Fix initial Rx Connection ID (CID) generation. + Remove stale initialization and overflow detection logic that resulted + in connection failures due to all CIDs being set to 0x80000002. + (14493, 14494, 14497) + +OpenAFS 1.8.6 + + All platforms + + * Address warnings and errors encountered when building OpenAFS with + modern compilers like gcc9 or recent clang (13727..45 13749..50 13756 + 13846 13879) + + * Avoid some rare cases of Rx calls getting stuck in the incoming queue + (13892) + + * Display the usage of simple commands (commands without subcommands) when + run only with the -help option (13894) + + * Fix a memory leak in the cache manager and the fileserver while + processing "fs uuid" or "fs setcbaddr" (13899) + + * Fix a memory leak when reopening krb local realms configuration (13900) + + * Avoid possible crashes when freeing kerberos contexts (13902) + + All server platforms + + * Do not leave empty directories behind in the file server vice partition + when running the "vos zap -force" command (13897) + + * Fix "vos zap -force" failures when the volume being zapped does not have + an entry in the fileserver's volume group cache (e.g., during fileserver + startup) (13896) + + * Relax the length limits on some membership lists used in ptserver RPCs, + introduced in release 1.8.0 to prevent denial of service attacks, to + accommodate use cases of some larger existing sites (13844) + + * Improved diagnostics and error messages (13898 13906..8 13938) + + * Ensure that fileservers running in readonly mode actually reject all + write requests, but introduce a -admin-write switch allowing writes + by members of the system:administrators group (14018 14019) + + All client platforms + + * Require the -insecure_des switch to be passed to aklog and klog.krb5 + to make them work with single-DES encryption types (13791) + + * Avoid a panic due to a retryable error - retry in a background request + instead (13847) + + * Avoid blocking other functions on the completion of some potentially + long-running RPCs issued by the server (13893) + + * Fix a potential memory leak in "fs getserverprefs" when the pioctl fails + with E2BIG (13895) + + * Avoid the local cache incorrectly reflecting the state of a file on the + fileserver after flushing large chunks of data to the server. This + issue was present on FreeBSD clients, but probably not Linux/Solaris + ones (13951) (RT #135041) + + * After a VLDB lookup of a read-write volume already failed, don't bother + looking up corresponding read-only or backup volumes since those lookups + are bound to fail, in order to make the client more responsive and + avoid unnecessary load on the vlserver (13968) + + * Allow a "vos rename" to succeed if the new volume name is the same as + that in the current VLDB, to make it possible to complete a previously + interrupted volume rename (14055) + + * Allow processes which are sleeping due to PAG throttling to be killable + (13974). + + * Fix set PAG failures due to signals (13975). + + Linux clients + diff --git a/linux-kmp.patch b/linux-kmp.patch deleted file mode 100644 index bc6acef..0000000 --- a/linux-kmp.patch +++ /dev/null @@ -1,1573 +0,0 @@ -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 - -diff --git a/src/afs/LINUX/osi_compat.h b/src/afs/LINUX/osi_compat.h -index 4999b89b9..620b3730c 100644 ---- a/src/afs/LINUX/osi_compat.h -+++ b/src/afs/LINUX/osi_compat.h -@@ -314,9 +314,22 @@ zero_user_segment(struct page *pp, unsigned int from1, unsigned int to1) - } - #endif - --#ifndef HAVE_LINUX_KERNEL_SETSOCKOPT -+#if defined(HAVE_LINUX_IP_SOCK_SET) -+# include -+/* ip_sock_set_* introduced in linux 5.8 */ -+static inline void -+afs_linux_sock_set_mtu_discover(struct socket *sockp, int pmtu) -+{ -+ ip_sock_set_mtu_discover(sockp->sk, pmtu); -+} -+static inline void -+afs_linux_sock_set_recverr(struct socket *sockp) -+{ -+ ip_sock_set_recverr(sockp->sk); -+} -+#else -+# if !defined(HAVE_LINUX_KERNEL_SETSOCKOPT) - /* Available from 2.6.19 */ -- - static inline int - kernel_setsockopt(struct socket *sockp, int level, int name, char *val, - unsigned int len) { -@@ -329,20 +342,22 @@ kernel_setsockopt(struct socket *sockp, int level, int name, char *val, - - return ret; - } -+# endif /* !HAVE_LINUX_KERNEL_SETSOCKOPT */ - --static inline int --kernel_getsockopt(struct socket *sockp, int level, int name, char *val, -- int *len) { -- mm_segment_t old_fs = get_fs(); -- int ret; -- -- set_fs(get_ds()); -- ret = sockp->ops->getsockopt(sockp, level, name, val, len); -- set_fs(old_fs); -- -- return ret; -+static inline void -+afs_linux_sock_set_mtu_discover(struct socket *sockp, int pmtu) -+{ -+ kernel_setsockopt(sockp, SOL_IP, IP_MTU_DISCOVER, (char *)&pmtu, -+ sizeof(pmtu)); - } --#endif -+static inline void -+afs_linux_sock_set_recverr(struct socket *sockp) -+{ -+ int recverr = 1; -+ kernel_setsockopt(sockp, SOL_IP, IP_RECVERR, (char *)&recverr, -+ sizeof(recverr)); -+} -+#endif /* !HAVE_LINUX_IP_SOCK_SET */ - - #ifdef HAVE_TRY_TO_FREEZE - static inline int -diff --git a/src/cf/linux-kernel-func.m4 b/src/cf/linux-kernel-func.m4 -index 07627db52..78ff48294 100644 ---- a/src/cf/linux-kernel-func.m4 -+++ b/src/cf/linux-kernel-func.m4 -@@ -151,6 +151,12 @@ AC_CHECK_LINUX_FUNC([lru_cache_add_file], - [#include ], - [lru_cache_add_file(NULL);]) - -+dnl Linux 5.8 replaced kernel_setsockopt with helper functions -+dnl e.g. ip_sock_set_mtu_discover, ip_sock_set_recverr -+AC_CHECK_LINUX_FUNC([ip_sock_set], -+ [#include ], -+ [ip_sock_set_mtu_discover(NULL, 0);]) -+ - dnl Consequences - things which get set as a result of the - dnl above tests - AS_IF([test "x$ac_cv_linux_func_d_alloc_anon" = "xno"], -diff --git a/src/rx/LINUX/rx_knet.c b/src/rx/LINUX/rx_knet.c -index 9fbb563f3..50607c8f5 100644 ---- a/src/rx/LINUX/rx_knet.c -+++ b/src/rx/LINUX/rx_knet.c -@@ -34,7 +34,6 @@ - #include - #include - #endif -- - #include "osi_compat.h" - - /* rxk_NewSocket -@@ -76,14 +75,10 @@ rxk_NewSocketHost(afs_uint32 ahost, short aport) - return NULL; - } - -- kernel_setsockopt(sockp, SOL_IP, IP_MTU_DISCOVER, (char *)&pmtu, -- sizeof(pmtu)); -+ afs_linux_sock_set_mtu_discover(sockp, pmtu); -+ - #ifdef AFS_RXERRQ_ENV -- { -- int recverr = 1; -- kernel_setsockopt(sockp, SOL_IP, IP_RECVERR, (char *)&recverr, -- sizeof(recverr)); -- } -+ afs_linux_sock_set_recverr(sockp); - #endif - return (osi_socket *)sockp; - } -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 - -diff --git a/src/afs/LINUX/osi_vfsops.c b/src/afs/LINUX/osi_vfsops.c -index 8bbb5f225..ca1d5c83b 100644 ---- a/src/afs/LINUX/osi_vfsops.c -+++ b/src/afs/LINUX/osi_vfsops.c -@@ -121,7 +121,9 @@ afs_fill_super(struct super_block *sb, void *data, int silent) - code = super_setup_bdi(sb); - if (code) - goto out; -+# if defined(STRUCT_BACKING_DEV_INFO_HAS_NAME) - sb->s_bdi->name = "openafs"; -+# endif - sb->s_bdi->ra_pages = 32; - #else - /* used for inodes backing_dev_info field, also */ -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 - -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index 00995b27a..36a4f685e 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -71,7 +71,7 @@ extern struct vcache *afs_globalVp; - - /* Handle interfacing with Linux's pagevec/lru facilities */ - --#if defined(HAVE_LINUX_LRU_CACHE_ADD_FILE) -+#if defined(HAVE_LINUX_LRU_CACHE_ADD_FILE) || defined(HAVE_LINUX_LRU_CACHE_ADD) - - /* - * Linux's lru_cache_add_file provides a simplified LRU interface without -@@ -90,7 +90,13 @@ afs_lru_cache_init(struct afs_lru_pages *alrupages) - static inline void - afs_lru_cache_add(struct afs_lru_pages *alrupages, struct page *page) - { -+# if defined(HAVE_LINUX_LRU_CACHE_ADD) -+ lru_cache_add(page); -+# elif defined(HAVE_LINUX_LRU_CACHE_ADD_FILE) - lru_cache_add_file(page); -+# else -+# error need a kernel function to add a page to the kernel lru cache -+# endif - } - - static inline void -diff --git a/src/cf/linux-kernel-func.m4 b/src/cf/linux-kernel-func.m4 -index 78ff48294..11d071806 100644 ---- a/src/cf/linux-kernel-func.m4 -+++ b/src/cf/linux-kernel-func.m4 -@@ -147,10 +147,17 @@ AC_CHECK_LINUX_FUNC([inode_lock], - [inode_lock(NULL);]) - - dnl lru_cache_add_file added to Linux 2.6.28. -+dnl removed in Linux 5.8 - AC_CHECK_LINUX_FUNC([lru_cache_add_file], - [#include ], - [lru_cache_add_file(NULL);]) - -+dnl lru_cache_add exported in Linux 5.8 -+dnl replaces lru_cache_add_file -+AC_CHECK_LINUX_FUNC([lru_cache_add], -+ [#include ], -+ [lru_cache_add(NULL);]) -+ - dnl Linux 5.8 replaced kernel_setsockopt with helper functions - dnl e.g. ip_sock_set_mtu_discover, ip_sock_set_recverr - AC_CHECK_LINUX_FUNC([ip_sock_set], -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 - -diff --git a/src/afs/LINUX/osi_ioctl.c b/src/afs/LINUX/osi_ioctl.c -index 1646a1518..9ba076a1b 100644 ---- a/src/afs/LINUX/osi_ioctl.c -+++ b/src/afs/LINUX/osi_ioctl.c -@@ -25,10 +25,6 @@ - #include - #endif - --#if defined(AFS_SPARC64_LINUX26_ENV) && defined(NEED_IOCTL32) && !defined(HAVE_COMPAT_IOCTL) --#include --#endif -- - #include - #include - #include -@@ -37,9 +33,6 @@ - #include "osi_compat.h" - - extern struct proc_dir_entry *openafs_procfs; --#if defined(NEED_IOCTL32) && !defined(HAVE_COMPAT_IOCTL) --static int ioctl32_done; --#endif - - extern asmlinkage long - afs_syscall(long syscall, long parm1, long parm2, long parm3, long parm4); -@@ -85,12 +78,11 @@ afs_ioctl(struct inode *inode, struct file *file, unsigned int cmd, - } - } - --#if defined(HAVE_UNLOCKED_IOCTL) || defined(HAVE_COMPAT_IOCTL) - static long afs_unlocked_ioctl(struct file *file, unsigned int cmd, - unsigned long arg) { - return afs_ioctl(FILE_INODE(file), file, cmd, arg); - } --#endif -+ - #if defined(HAVE_LINUX_STRUCT_PROC_OPS) - static struct proc_ops afs_syscall_ops = { - .proc_ioctl = afs_unlocked_ioctl, -@@ -100,16 +92,11 @@ static struct proc_ops afs_syscall_ops = { - }; - #else - static struct file_operations afs_syscall_ops = { --# ifdef HAVE_UNLOCKED_IOCTL - .unlocked_ioctl = afs_unlocked_ioctl, --# else -- .ioctl = afs_ioctl, --# endif --# ifdef HAVE_COMPAT_IOCTL - .compat_ioctl = afs_unlocked_ioctl, --# endif - }; - #endif /* HAVE_LINUX_STRUCT_PROC_OPS */ -+ - void - osi_ioctl_init(void) - { -@@ -121,18 +108,10 @@ osi_ioctl_init(void) - entry->owner = THIS_MODULE; - #endif - --#if defined(NEED_IOCTL32) && !defined(HAVE_COMPAT_IOCTL) -- if (register_ioctl32_conversion(VIOC_SYSCALL32, NULL) == 0) -- ioctl32_done = 1; --#endif - } - - void - osi_ioctl_clean(void) - { - remove_proc_entry(PROC_SYSCALL_NAME, openafs_procfs); --#if defined(NEED_IOCTL32) && !defined(HAVE_COMPAT_IOCTL) -- if (ioctl32_done) -- unregister_ioctl32_conversion(VIOC_SYSCALL32); --#endif - } -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index 36a4f685e..ba4f1e6af 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -589,13 +589,11 @@ out1: - extern int afs_xioctl(struct inode *ip, struct file *fp, unsigned int com, - unsigned long arg); - --#if defined(HAVE_UNLOCKED_IOCTL) || defined(HAVE_COMPAT_IOCTL) - static long afs_unlocked_xioctl(struct file *fp, unsigned int com, - unsigned long arg) { - return afs_xioctl(FILE_INODE(fp), fp, com, arg); - - } --#endif - - - static int -@@ -891,14 +889,8 @@ struct file_operations afs_dir_fops = { - #else - .readdir = afs_linux_readdir, - #endif --#ifdef HAVE_UNLOCKED_IOCTL - .unlocked_ioctl = afs_unlocked_xioctl, --#else -- .ioctl = afs_xioctl, --#endif --#ifdef HAVE_COMPAT_IOCTL - .compat_ioctl = afs_unlocked_xioctl, --#endif - .open = afs_linux_open, - .release = afs_linux_release, - .llseek = default_llseek, -@@ -926,14 +918,8 @@ struct file_operations afs_file_fops = { - .read = afs_linux_read, - .write = afs_linux_write, - #endif --#ifdef HAVE_UNLOCKED_IOCTL - .unlocked_ioctl = afs_unlocked_xioctl, --#else -- .ioctl = afs_xioctl, --#endif --#ifdef HAVE_COMPAT_IOCTL - .compat_ioctl = afs_unlocked_xioctl, --#endif - .mmap = afs_linux_mmap, - .open = afs_linux_open, - .flush = afs_linux_flush, -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 - -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index ba4f1e6af..d2a994389 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -177,7 +177,7 @@ afs_linux_VerifyVCache(struct vcache *avc, cred_t **retcred) { - - code = afs_CreateReq(&treq, credp); - if (code == 0) { -- code = afs_VerifyVCache2(avc, treq); -+ code = afs_VerifyVCache(avc, treq); - afs_DestroyReq(treq); - } - -@@ -419,7 +419,7 @@ afs_linux_readdir(struct file *fp, void *dirbuf, filldir_t filldir) - - /* update the cache entry */ - tagain: -- code = afs_convert_code(afs_VerifyVCache2(avc, treq)); -+ code = afs_convert_code(afs_VerifyVCache(avc, treq)); - if (code) - goto out; - -diff --git a/src/afs/VNOPS/afs_vnop_attrs.c b/src/afs/VNOPS/afs_vnop_attrs.c -index a22331a5b..7166bf3c3 100644 ---- a/src/afs/VNOPS/afs_vnop_attrs.c -+++ b/src/afs/VNOPS/afs_vnop_attrs.c -@@ -248,7 +248,7 @@ afs_getattr(OSI_VC_DECL(avc), struct vattr *attrs, afs_ucred_t *acred) - - if (!(avc->f.states & CStatd)) { - if (!(code = afs_CreateReq(&treq, acred))) { -- code = afs_VerifyVCache2(avc, treq); -+ code = afs_VerifyVCache(avc, treq); - inited = 1; - } - } else -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 - -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index d2a994389..ae406df61 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -2357,6 +2357,9 @@ afs_linux_readpage_fastpath(struct file *fp, struct page *pp, int *codep) - return 1; - - out: -+ if (cacheFp != NULL) { -+ filp_close(cacheFp, NULL); -+ } - ReleaseWriteLock(&avc->lock); - ReleaseReadLock(&tdc->lock); - afs_PutDCache(tdc); -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 - -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index ae406df61..c2a4278bf 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -63,6 +63,12 @@ - #undef USE_FOP_ITERATE - #endif - -+/* Kernels from before 2.6.19 may not be able to return errors from -+ * d_revalidate. */ -+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19) -+# define ERRORS_FROM_D_REVALIDATE -+#endif -+ - int cachefs_noreadpage = 0; - - extern struct backing_dev_info *afs_backing_dev_info; -@@ -1291,6 +1297,7 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - struct afs_fakestat_state fakestate; - int force_drop = 0; - afs_uint32 parent_dv; -+ int code = 0; - - #ifdef LOOKUP_RCU - /* We don't support RCU path walking */ -@@ -1321,14 +1328,13 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - if (vcp->mvstat == AFS_MVSTAT_MTPT) { - if (vcp->mvid.target_root && (vcp->f.states & CMValid)) { - int tryEvalOnly = 0; -- int code = 0; - struct vrequest *treq = NULL; - - credp = crref(); - - code = afs_CreateReq(&treq, credp); - if (code) { -- goto bad_dentry; -+ goto error; - } - if ((strcmp(dp->d_name.name, ".directory") == 0)) { - tryEvalOnly = 1; -@@ -1338,7 +1344,10 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - else - code = afs_EvalFakeStat(&vcp, &fakestate, treq); - afs_DestroyReq(treq); -- if ((tryEvalOnly && vcp->mvstat == AFS_MVSTAT_MTPT) || code) { -+ if (code != 0) { -+ goto error; -+ } -+ if (tryEvalOnly && vcp->mvstat == AFS_MVSTAT_MTPT) { - /* a mount point, not yet replaced by its directory */ - goto bad_dentry; - } -@@ -1372,22 +1381,27 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - - if (parent_dv > dp->d_time || !(vcp->f.states & CStatd)) { - struct vattr *vattr = NULL; -- int code; -- int lookup_good; - - if (credp == NULL) { - credp = crref(); - } - code = afs_lookup(pvcp, (char *)dp->d_name.name, &tvc, credp); - code = filter_enoent(code); -+ if (code == ENOENT) { -+ /* ENOENT is not an error here. */ -+ code = 0; -+ osi_Assert(tvc == NULL); -+ } - - if (code) { -- /* We couldn't perform the lookup, so we're not okay. */ -- lookup_good = 0; -+ /* We couldn't perform the lookup, so we don't know if the -+ * dentry is valid or not. */ -+ dput(parent); -+ goto error; -+ } - -- } else if (tvc == vcp) { -+ if (tvc == vcp) { - /* We got back the same vcache, so we're good. */ -- lookup_good = 1; - - } else if (tvc == VTOAFS(dp->d_inode)) { - /* We got back the same vcache, so we're good. This is -@@ -1398,37 +1412,29 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - * versa, so the previous case will not succeed. But this is - * still 'correct', so make sure not to mark the dentry as - * invalid; it still points to the same thing! */ -- lookup_good = 1; - - } else { -- /* We got back a different file, so we're definitely not -- * okay. */ -- lookup_good = 0; -- } -- -- if (!lookup_good) { -+ /* -+ * We got back a different file, so we know this dentry is -+ * _not_ okay. Force it to be unhashed, since the given name -+ * doesn't point to this file anymore. -+ */ - dput(parent); -- /* Force unhash; the name doesn't point to this file -- * anymore. */ - force_drop = 1; -- if (code && code != ENOENT) { -- /* ...except if we couldn't perform the actual lookup, -- * we don't know if the name points to this file or not. */ -- force_drop = 0; -- } - goto bad_dentry; - } - - code = afs_CreateAttr(&vattr); - if (code) { - dput(parent); -- goto bad_dentry; -+ goto error; - } - - if (afs_getattr(vcp, vattr, credp)) { - dput(parent); - afs_DestroyAttr(vattr); -- goto bad_dentry; -+ code = EIO; -+ goto error; - } - - vattr2inode(AFSTOV(vcp), vattr); -@@ -1460,10 +1466,12 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - } - - good_dentry: -+ code = 0; - valid = 1; - goto done; - - bad_dentry: -+ code = 0; - valid = 0; - #ifndef D_INVALIDATE_IS_VOID - /* When (v3.18) d_invalidate was converted to void, it also started -@@ -1489,6 +1497,18 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - if (credp) - crfree(credp); - -+#ifdef ERRORS_FROM_D_REVALIDATE -+ if (code != 0) { -+ /* -+ * If code is nonzero, we don't know whether this dentry is valid or -+ * not; we couldn't successfully perform the relevant lookup in order -+ * to tell. So we must not return 'valid' (1) or 'not valid' (0); we -+ * need to return an error (e.g. -EIO). -+ */ -+ return -code; -+ } -+#endif -+ - #ifndef D_INVALIDATE_IS_VOID - if (!valid) { - /* -@@ -1505,6 +1525,17 @@ afs_linux_dentry_revalidate(struct dentry *dp, int flags) - #endif - return valid; - -+ error: -+ if (code <= 0) { -+ code = EIO; -+ } -+#ifdef ERRORS_FROM_D_REVALIDATE -+ valid = 0; -+ goto done; -+#else -+ /* We can't return an error, so default to saying the dentry is invalid. */ -+ goto bad_dentry; -+#endif - } - - static void -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 - -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index 593086d1e..1564f8986 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -1212,6 +1212,8 @@ filter_enoent(int code) - if (code == ENOENT && fatal_signal_pending(current)) { - return EINTR; - } -+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25) -+# error fatal_signal_pending not available, but it should be - #endif - return code; - } -diff --git a/src/cf/linux-kernel-func.m4 b/src/cf/linux-kernel-func.m4 -index 10b7c97dd..4651b5b1a 100644 ---- a/src/cf/linux-kernel-func.m4 -+++ b/src/cf/linux-kernel-func.m4 -@@ -42,8 +42,13 @@ AC_CHECK_LINUX_FUNC([d_make_root], - AC_CHECK_LINUX_FUNC([do_sync_read], - [#include ], - [do_sync_read(NULL, NULL, 0, NULL);]) -+dnl - fatal_signal_pending introduced in 2.6.25 -+dnl - moved from linux/sched.h to linux/sched/signal.h in 4.11 - AC_CHECK_LINUX_FUNC([fatal_signal_pending], -- [#include ], -+ [#include -+ #ifdef HAVE_LINUX_SCHED_SIGNAL_H -+ # include -+ #endif], - [fatal_signal_pending(NULL);]) - AC_CHECK_LINUX_FUNC([file_dentry], - [#include ], -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 - -diff --git a/src/afs/LINUX/osi_ioctl.c b/src/afs/LINUX/osi_ioctl.c -index 9ba076a1b..7d355674d 100644 ---- a/src/afs/LINUX/osi_ioctl.c -+++ b/src/afs/LINUX/osi_ioctl.c -@@ -43,21 +43,13 @@ afs_ioctl(struct inode *inode, struct file *file, unsigned int cmd, - { - - struct afsprocdata sysargs; --#ifdef NEED_IOCTL32 -- struct afsprocdata32 sysargs32; --#endif - - if (cmd != VIOC_SYSCALL && cmd != VIOC_SYSCALL32) return -EINVAL; - - #ifdef NEED_IOCTL32 --# if defined(AFS_S390X_LINUX26_ENV) -- if (test_thread_flag(TIF_31BIT)) --# elif defined(AFS_AMD64_LINUX20_ENV) -- if (test_thread_flag(TIF_IA32)) --# else -- if (test_thread_flag(TIF_32BIT)) --# endif /* AFS_S390X_LINUX26_ENV */ -- { -+ if (afs_in_compat_syscall()) { -+ struct afsprocdata32 sysargs32; -+ - if (copy_from_user(&sysargs32, (void *)arg, - sizeof(struct afsprocdata32))) - return -EFAULT; -diff --git a/src/afs/LINUX/osi_machdep.h b/src/afs/LINUX/osi_machdep.h -index 784829627..9ecdaf0bf 100644 ---- a/src/afs/LINUX/osi_machdep.h -+++ b/src/afs/LINUX/osi_machdep.h -@@ -76,6 +76,8 @@ - #include "h/cred.h" - #endif - -+#include "afs/sysincludes.h" -+ - #if !defined(HAVE_LINUX_TIME_T) - typedef time64_t time_t; - #endif -@@ -157,6 +159,44 @@ static inline long copyinstr(char *from, char *to, int count, int *length) { - } - #define copyout(F, T, C) (copy_to_user ((char*)(T), (char*)(F), (C)) > 0 ? EFAULT : 0) - -+/* -+ * Test to see for 64/32bit compatibility mode -+ * Return non-zero if in a 64bit kernel and handing a 32bit syscall -+ */ -+#if defined(AFS_LINUX_64BIT_KERNEL) && !defined(AFS_ALPHA_LINUX20_ENV) && !defined(AFS_IA64_LINUX20_ENV) -+static inline int -+afs_in_compat_syscall(void) -+{ -+# if defined(AFS_SPARC64_LINUX26_ENV) -+ return test_thread_flag(TIF_32BIT); -+# elif defined(AFS_SPARC64_LINUX24_ENV) -+ return (current->thread.flags & SPARC_FLAG_32BIT) != 0; -+# elif defined(AFS_SPARC64_LINUX20_ENV) -+ return (current->tss.flags & SPARC_FLAG_32BIT) != 0; -+# elif defined(AFS_AMD64_LINUX26_ENV) -+ return test_thread_flag(TIF_IA32); -+# elif defined(AFS_AMD64_LINUX20_ENV) -+ return (current->thread.flags & THREAD_IA32) != 0; -+# elif defined(AFS_PPC64_LINUX26_ENV) -+# if defined(STRUCT_TASK_STRUCT_HAS_THREAD_INFO) -+ return (current->thread_info->flags & _TIF_32BIT) != 0; -+# else -+ return (task_thread_info(current)->flags & _TIF_32BIT) != 0; -+# endif -+# elif defined(AFS_PPC64_LINUX20_ENV) -+ return (current->thread.flags & PPC_FLAG_32BIT) != 0; -+# elif defined(AFS_S390X_LINUX26_ENV) -+ return test_thread_flag(TIF_31BIT); -+# elif defined(AFS_S390X_LINUX20_ENV) -+ return (current->thread.flags & S390_FLAG_31BIT) != 0; -+# elif defined(AFS_ARM64_LINUX26_ENV) -+ return is_compat_task(); -+# else -+# error afs_in_compat_syscall not done for this linux -+# endif -+} -+#endif /* AFS_LINUX_64BIT_KERNEL */ -+ - /* kernel print statements */ - #define printf(args...) printk(args) - #define uprintf(args...) printk(args) -diff --git a/src/afs/afs_syscall.c b/src/afs/afs_syscall.c -index ce6afdf9a..9414f38b8 100644 ---- a/src/afs/afs_syscall.c -+++ b/src/afs/afs_syscall.c -@@ -114,40 +114,9 @@ copyin_afs_ioctl(caddr_t cmarg, struct afs_ioctl *dst) - #endif /* defined(AFS_SGI_ENV) && (_MIPS_SZLONG==64) */ - - #if defined(AFS_LINUX_64BIT_KERNEL) && !defined(AFS_ALPHA_LINUX20_ENV) && !defined(AFS_IA64_LINUX20_ENV) -- struct afs_ioctl32 dst32; -- --#ifdef AFS_SPARC64_LINUX26_ENV -- if (test_thread_flag(TIF_32BIT)) --#elif defined(AFS_SPARC64_LINUX24_ENV) -- if (current->thread.flags & SPARC_FLAG_32BIT) --#elif defined(AFS_SPARC64_LINUX20_ENV) -- if (current->tss.flags & SPARC_FLAG_32BIT) -- --#elif defined(AFS_AMD64_LINUX26_ENV) -- if (test_thread_flag(TIF_IA32)) --#elif defined(AFS_AMD64_LINUX20_ENV) -- if (current->thread.flags & THREAD_IA32) -- --#elif defined(AFS_PPC64_LINUX26_ENV) --#if defined(STRUCT_TASK_STRUCT_HAS_THREAD_INFO) -- if (current->thread_info->flags & _TIF_32BIT) --#else -- if (task_thread_info(current)->flags & _TIF_32BIT) --#endif --#elif defined(AFS_PPC64_LINUX20_ENV) -- if (current->thread.flags & PPC_FLAG_32BIT) -- --#elif defined(AFS_S390X_LINUX26_ENV) -- if (test_thread_flag(TIF_31BIT)) --#elif defined(AFS_S390X_LINUX20_ENV) -- if (current->thread.flags & S390_FLAG_31BIT) --#elif defined(AFS_ARM64_LINUX26_ENV) -- if (is_compat_task()) -+ if (afs_in_compat_syscall()) { -+ struct afs_ioctl32 dst32; - --#else --#error pioctl32 not done for this linux --#endif -- { - AFS_COPYIN(cmarg, (caddr_t) & dst32, sizeof dst32, code); - if (!code) - afs_ioctl32_to_afs_ioctl(&dst32, dst); -@@ -391,40 +360,9 @@ copyin_iparam(caddr_t cmarg, struct iparam *dst) - #endif /* AFS_SUN5_64BIT_ENV */ - - #if defined(AFS_LINUX_64BIT_KERNEL) && !defined(AFS_ALPHA_LINUX20_ENV) && !defined(AFS_IA64_LINUX20_ENV) -- struct iparam32 dst32; -- --#ifdef AFS_SPARC64_LINUX26_ENV -- if (test_thread_flag(TIF_32BIT)) --#elif defined(AFS_SPARC64_LINUX24_ENV) -- if (current->thread.flags & SPARC_FLAG_32BIT) --#elif defined(AFS_SPARC64_LINUX20_ENV) -- if (current->tss.flags & SPARC_FLAG_32BIT) -- --#elif defined(AFS_AMD64_LINUX26_ENV) -- if (test_thread_flag(TIF_IA32)) --#elif defined(AFS_AMD64_LINUX20_ENV) -- if (current->thread.flags & THREAD_IA32) -- --#elif defined(AFS_PPC64_LINUX26_ENV) --#if defined(STRUCT_TASK_STRUCT_HAS_THREAD_INFO) -- if (current->thread_info->flags & _TIF_32BIT) --#else -- if (task_thread_info(current)->flags & _TIF_32BIT) --#endif --#elif defined(AFS_PPC64_LINUX20_ENV) -- if (current->thread.flags & PPC_FLAG_32BIT) -- --#elif defined(AFS_S390X_LINUX26_ENV) -- if (test_thread_flag(TIF_31BIT)) --#elif defined(AFS_S390X_LINUX20_ENV) -- if (current->thread.flags & S390_FLAG_31BIT) --#elif defined(AFS_ARM64_LINUX26_ENV) -- if (is_compat_task()) -+ if (afs_in_compat_syscall()) { -+ struct iparam32 dst32; - --#else --#error iparam32 not done for this linux platform --#endif -- { - AFS_COPYIN(cmarg, (caddr_t) & dst32, sizeof dst32, code); - if (!code) - iparam32_to_iparam(&dst32, dst); -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 - -diff --git a/src/afs/LINUX/osi_machdep.h b/src/afs/LINUX/osi_machdep.h -index 9ecdaf0bf..066c1885f 100644 ---- a/src/afs/LINUX/osi_machdep.h -+++ b/src/afs/LINUX/osi_machdep.h -@@ -167,7 +167,9 @@ static inline long copyinstr(char *from, char *to, int count, int *length) { - static inline int - afs_in_compat_syscall(void) - { --# if defined(AFS_SPARC64_LINUX26_ENV) -+# if defined(HAVE_LINUX_IN_COMPAT_SYSCALL) -+ return in_compat_syscall(); -+# elif defined(AFS_SPARC64_LINUX26_ENV) - return test_thread_flag(TIF_32BIT); - # elif defined(AFS_SPARC64_LINUX24_ENV) - return (current->thread.flags & SPARC_FLAG_32BIT) != 0; -diff --git a/src/cf/linux-kernel-func.m4 b/src/cf/linux-kernel-func.m4 -index 4651b5b1a..0ca3e4463 100644 ---- a/src/cf/linux-kernel-func.m4 -+++ b/src/cf/linux-kernel-func.m4 -@@ -160,6 +160,12 @@ AC_CHECK_LINUX_FUNC([lru_cache_add_file], - [#include ], - [lru_cache_add_file(NULL);]) - -+dnl Linux 4.6 introduced in_compat_syscall as replacement for is_compat_task -+dnl for certain platforms. -+AC_CHECK_LINUX_FUNC([in_compat_syscall], -+ [#include ], -+ [in_compat_syscall();]) -+ - dnl lru_cache_add exported in Linux 5.8 - dnl replaces lru_cache_add_file - AC_CHECK_LINUX_FUNC([lru_cache_add], -From cdec210405afb47ee338bfde9280710b64d7abc6 Mon Sep 17 00:00:00 2001 -From: Andrew Deason -Date: Tue, 23 Jul 2019 13:50:31 -0500 -Subject: [PATCH] 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 ---- - -diff --git a/src/afs/LINUX/osi_compat.h b/src/afs/LINUX/osi_compat.h -index 620b373..a1e7f21 100644 ---- a/src/afs/LINUX/osi_compat.h -+++ b/src/afs/LINUX/osi_compat.h -@@ -737,4 +737,15 @@ - #endif - } - -+static inline char* -+afs_d_path(struct dentry *dp, struct vfsmount *mnt, char *buf, int buflen) -+{ -+#ifdef D_PATH_TAKES_STRUCT_PATH -+ afs_linux_path_t p = { .mnt = mnt, .dentry = dp }; -+ return d_path(&p, buf, buflen); -+#else -+ return d_path(dp, mnt, buf, buflen); -+#endif -+} -+ - #endif /* AFS_LINUX_OSI_COMPAT_H */ -diff --git a/src/afs/LINUX/osi_misc.c b/src/afs/LINUX/osi_misc.c -index 0e9336d..aa5d5fc 100644 ---- a/src/afs/LINUX/osi_misc.c -+++ b/src/afs/LINUX/osi_misc.c -@@ -138,13 +138,7 @@ - return -PTR_ERR(name); - code = osi_lookupname_internal(name, followlink, &mnt, &dp); - if (!code) { --#if defined(D_PATH_TAKES_STRUCT_PATH) -- afs_linux_path_t p = { .mnt = mnt, .dentry = dp }; -- path = d_path(&p, buf, buflen); --#else -- path = d_path(dp, mnt, buf, buflen); --#endif -- -+ path = afs_d_path(dp, mnt, buf, buflen); - if (IS_ERR(path)) { - code = -PTR_ERR(path); - } else { -From 5a5d358b02b88d6d2c7a27a75149e35b1de7db38 Mon Sep 17 00:00:00 2001 -From: Cheyenne Wills -Date: Mon, 08 Mar 2021 09:22:04 -0700 -Subject: [PATCH] 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 ---- - -diff --git a/src/afs/LINUX/osi_compat.h b/src/afs/LINUX/osi_compat.h -index a1e7f21..3ac4d79 100644 ---- a/src/afs/LINUX/osi_compat.h -+++ b/src/afs/LINUX/osi_compat.h -@@ -748,4 +748,14 @@ - #endif - } - -+static inline int -+afs_setattr_prepare(struct dentry *dp, struct iattr *newattrs) -+{ -+#if defined(HAVE_LINUX_SETATTR_PREPARE) -+ return setattr_prepare(dp, newattrs); -+#else -+ return inode_change_ok(dp->d_inode, newattrs); -+#endif -+} -+ - #endif /* AFS_LINUX_OSI_COMPAT_H */ -diff --git a/src/afs/LINUX/osi_file.c b/src/afs/LINUX/osi_file.c -index 0afb875..03777f5 100644 ---- a/src/afs/LINUX/osi_file.c -+++ b/src/afs/LINUX/osi_file.c -@@ -230,11 +230,7 @@ - AFS_CURRENT_TIME(&newattrs.ia_ctime); - - /* avoid notify_change() since it wants to update dentry->d_parent */ --#ifdef HAVE_LINUX_SETATTR_PREPARE -- code = setattr_prepare(file_dentry(afile->filp), &newattrs); --#else -- code = inode_change_ok(inode, &newattrs); --#endif -+ code = afs_setattr_prepare(file_dentry(afile->filp), &newattrs); - if (!code) - code = afs_inode_setattr(afile, &newattrs); - if (!code) -From c747b15dd2877e6d17e3e6b940ae78c1e1ccd3ea Mon Sep 17 00:00:00 2001 -From: Cheyenne Wills -Date: Fri, 05 Mar 2021 16:31:03 -0700 -Subject: [PATCH] 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 ---- - -diff --git a/src/afs/LINUX/osi_compat.h b/src/afs/LINUX/osi_compat.h -index 3ac4d79..726b655 100644 ---- a/src/afs/LINUX/osi_compat.h -+++ b/src/afs/LINUX/osi_compat.h -@@ -524,7 +524,9 @@ - - int code = 0; - struct inode *inode = OSIFILE_INODE(afile); --#if !defined(HAVE_LINUX_INODE_SETATTR) -+#if defined(IOP_TAKES_USER_NAMESPACE) -+ code = inode->i_op->setattr(afs_ns, afile->filp->f_dentry, newattrs); -+#elif !defined(HAVE_LINUX_INODE_SETATTR) - code = inode->i_op->setattr(afile->filp->f_dentry, newattrs); - #elif defined(INODE_SETATTR_NOT_VOID) - if (inode->i_op && inode->i_op->setattr) -@@ -751,7 +753,9 @@ - static inline int - afs_setattr_prepare(struct dentry *dp, struct iattr *newattrs) - { --#if defined(HAVE_LINUX_SETATTR_PREPARE) -+#if defined(IOP_TAKES_USER_NAMESPACE) -+ return setattr_prepare(afs_ns, dp, newattrs); -+#elif defined(HAVE_LINUX_SETATTR_PREPARE) - return setattr_prepare(dp, newattrs); - #else - return inode_change_ok(dp->d_inode, newattrs); -diff --git a/src/afs/LINUX/osi_vnodeops.c b/src/afs/LINUX/osi_vnodeops.c -index 1564f89..f4bedae 100644 ---- a/src/afs/LINUX/osi_vnodeops.c -+++ b/src/afs/LINUX/osi_vnodeops.c -@@ -1124,8 +1124,13 @@ - * Linux version of setattr call. What to change is in the iattr struct. - * We need to set bits in both the Linux inode as well as the vcache. - */ -+#if defined(IOP_TAKES_USER_NAMESPACE) -+static int -+afs_notify_change(struct user_namespace *mnt_userns, struct dentry *dp, struct iattr *iattrp) -+#else - static int - afs_notify_change(struct dentry *dp, struct iattr *iattrp) -+#endif - { - struct vattr *vattr = NULL; - cred_t *credp = crref(); -@@ -1153,7 +1158,18 @@ - return afs_convert_code(code); - } - --#if defined(IOP_GETATTR_TAKES_PATH_STRUCT) -+#if defined(IOP_TAKES_USER_NAMESPACE) -+static int -+afs_linux_getattr(struct user_namespace *mnt_userns, const struct path *path, struct kstat *stat, -+ u32 request_mask, unsigned int sync_mode) -+{ -+ int err = afs_linux_revalidate(path->dentry); -+ if (!err) { -+ generic_fillattr(afs_ns, path->dentry->d_inode, stat); -+ } -+ return err; -+} -+#elif defined(IOP_GETATTR_TAKES_PATH_STRUCT) - static int - afs_linux_getattr(const struct path *path, struct kstat *stat, u32 request_mask, unsigned int sync_mode) - { -@@ -1622,17 +1638,25 @@ - * - * name is in kernel space at this point. - */ -+ -+#if defined(IOP_TAKES_USER_NAMESPACE) - static int --#if defined(IOP_CREATE_TAKES_BOOL) -+afs_linux_create(struct user_namespace *mnt_userns, struct inode *dip, -+ struct dentry *dp, umode_t mode, bool excl) -+#elif defined(IOP_CREATE_TAKES_BOOL) -+static int - afs_linux_create(struct inode *dip, struct dentry *dp, umode_t mode, - bool excl) - #elif defined(IOP_CREATE_TAKES_UMODE_T) -+static int - afs_linux_create(struct inode *dip, struct dentry *dp, umode_t mode, - struct nameidata *nd) - #elif defined(IOP_CREATE_TAKES_NAMEIDATA) -+static int - afs_linux_create(struct inode *dip, struct dentry *dp, int mode, - struct nameidata *nd) - #else -+static int - afs_linux_create(struct inode *dip, struct dentry *dp, int mode) - #endif - { -@@ -1907,8 +1931,14 @@ - } - - -+#if defined(IOP_TAKES_USER_NAMESPACE) -+static int -+afs_linux_symlink(struct user_namespace *mnt_userns, struct inode *dip, -+ struct dentry *dp, const char *target) -+#else - static int - afs_linux_symlink(struct inode *dip, struct dentry *dp, const char *target) -+#endif - { - int code; - cred_t *credp = crref(); -@@ -1936,10 +1966,15 @@ - return afs_convert_code(code); - } - -+#if defined(IOP_TAKES_USER_NAMESPACE) - static int --#if defined(IOP_MKDIR_TAKES_UMODE_T) -+afs_linux_mkdir(struct user_namespace *mnt_userns, struct inode *dip, -+ struct dentry *dp, umode_t mode) -+#elif defined(IOP_MKDIR_TAKES_UMODE_T) -+static int - afs_linux_mkdir(struct inode *dip, struct dentry *dp, umode_t mode) - #else -+static int - afs_linux_mkdir(struct inode *dip, struct dentry *dp, int mode) - #endif - { -@@ -2011,13 +2046,22 @@ - } - - -+#if defined(IOP_TAKES_USER_NAMESPACE) -+static int -+afs_linux_rename(struct user_namespace *mnt_userns, -+ struct inode *oldip, struct dentry *olddp, -+ struct inode *newip, struct dentry *newdp, -+ unsigned int flags) -+#elif defined(HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS) - static int - afs_linux_rename(struct inode *oldip, struct dentry *olddp, -- struct inode *newip, struct dentry *newdp --#ifdef HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS -- , unsigned int flags -+ struct inode *newip, struct dentry *newdp, -+ unsigned int flags) -+#else -+static int -+afs_linux_rename(struct inode *oldip, struct dentry *olddp, -+ struct inode *newip, struct dentry *newdp) - #endif -- ) - { - int code; - cred_t *credp = crref(); -@@ -2025,7 +2069,8 @@ - const char *newname = newdp->d_name.name; - struct dentry *rehash = NULL; - --#ifdef HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS -+#if defined(HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS) || \ -+ defined(IOP_TAKES_USER_NAMESPACE) - if (flags) - return -EINVAL; /* no support for new flags yet */ - #endif -@@ -3050,12 +3095,18 @@ - /* afs_linux_permission - * Check access rights - returns error if can't check or permission denied. - */ -+ -+#if defined(IOP_TAKES_USER_NAMESPACE) - static int --#if defined(IOP_PERMISSION_TAKES_FLAGS) -+afs_linux_permission(struct user_namespace *mnt_userns, struct inode *ip, int mode) -+#elif defined(IOP_PERMISSION_TAKES_FLAGS) -+static int - afs_linux_permission(struct inode *ip, int mode, unsigned int flags) - #elif defined(IOP_PERMISSION_TAKES_NAMEIDATA) -+static int - afs_linux_permission(struct inode *ip, int mode, struct nameidata *nd) - #else -+static int - afs_linux_permission(struct inode *ip, int mode) - #endif - { -diff --git a/src/cf/linux-kernel-sig.m4 b/src/cf/linux-kernel-sig.m4 -index 3d3aff9..e0cc9a2 100644 ---- a/src/cf/linux-kernel-sig.m4 -+++ b/src/cf/linux-kernel-sig.m4 -@@ -14,4 +14,18 @@ - [struct inode *oinode, struct dentry *odentry, - struct inode *ninode, struct dentry *ndentry, - unsigned int flags]) --]) -+dnl Linux 5.12 added the user_namespace parameter to the several -+dnl inode operations functions. -+dnl Perform a generic test using the inode_op create to test for this change. -+AC_CHECK_LINUX_OPERATION([inode_operations], [create], [user_namespace], -+ [#include ], -+ [int], -+ [struct user_namespace *mnt_userns, -+ struct inode *inode, struct dentry *dentry, -+ umode_t umode, bool flag]) -+dnl if HAVE_LINUX_INODE_OPERATIONS_CREATE_USER_NAMESPACE, create a more generic -+dnl define. -+AS_IF([test AS_VAR_GET([ac_cv_linux_operation_inode_operations_create_user_namespace]) = yes], -+ [AC_DEFINE([IOP_TAKES_USER_NAMESPACE], 1, -+ [define if inodeops require struct user_namespace])]) -+]) -\ No newline at end of file diff --git a/openafs-1.8.7-doc.tar.bz2 b/openafs-1.8.7-doc.tar.bz2 deleted file mode 100644 index 782ecc7..0000000 --- a/openafs-1.8.7-doc.tar.bz2 +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:d61384efdce1aacabdd1890062ada741c0e0aeb4cc973811a493dcda6f4a317f -size 3808045 diff --git a/openafs-1.8.7-doc.tar.bz2.md5 b/openafs-1.8.7-doc.tar.bz2.md5 deleted file mode 100644 index a1b06cb..0000000 --- a/openafs-1.8.7-doc.tar.bz2.md5 +++ /dev/null @@ -1 +0,0 @@ -6fd3097cc812549a7ae97a703b90a8ac ../1.8.7/openafs-1.8.7-doc.tar.bz2 diff --git a/openafs-1.8.7-doc.tar.bz2.sha256 b/openafs-1.8.7-doc.tar.bz2.sha256 deleted file mode 100644 index 24dafdb..0000000 --- a/openafs-1.8.7-doc.tar.bz2.sha256 +++ /dev/null @@ -1 +0,0 @@ -d61384efdce1aacabdd1890062ada741c0e0aeb4cc973811a493dcda6f4a317f openafs-1.8.7-doc.tar.bz2 diff --git a/openafs-1.8.7-src.tar.bz2 b/openafs-1.8.7-src.tar.bz2 deleted file mode 100644 index 1b3afa2..0000000 --- a/openafs-1.8.7-src.tar.bz2 +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:53543a561fce67714fec9f2a6bf408c5cc1d061c7dc9d1459458275e8ccbfa79 -size 15059909 diff --git a/openafs-1.8.7-src.tar.bz2.md5 b/openafs-1.8.7-src.tar.bz2.md5 deleted file mode 100644 index d784585..0000000 --- a/openafs-1.8.7-src.tar.bz2.md5 +++ /dev/null @@ -1 +0,0 @@ -e316f61d8c5b85fb98c69f584f08b64d ../1.8.7/openafs-1.8.7-src.tar.bz2 diff --git a/openafs-1.8.7-src.tar.bz2.sha256 b/openafs-1.8.7-src.tar.bz2.sha256 deleted file mode 100644 index 2b8622c..0000000 --- a/openafs-1.8.7-src.tar.bz2.sha256 +++ /dev/null @@ -1 +0,0 @@ -53543a561fce67714fec9f2a6bf408c5cc1d061c7dc9d1459458275e8ccbfa79 openafs-1.8.7-src.tar.bz2 diff --git a/openafs-1.8.8-doc.tar.bz2 b/openafs-1.8.8-doc.tar.bz2 new file mode 100644 index 0000000..2cc0b4c --- /dev/null +++ b/openafs-1.8.8-doc.tar.bz2 @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:ddcc4e0c7d4abce4f1ac607e69c12e7711825f58813e365c4df8e97eb68e9be5 +size 3773056 diff --git a/openafs-1.8.8-doc.tar.bz2.md5 b/openafs-1.8.8-doc.tar.bz2.md5 new file mode 100644 index 0000000..a516a0d --- /dev/null +++ b/openafs-1.8.8-doc.tar.bz2.md5 @@ -0,0 +1 @@ +3affed58b57e2d9cb502e9fbcd9352d0 openafs-1.8.8-doc.tar.bz2 diff --git a/openafs-1.8.8-doc.tar.bz2.sha256 b/openafs-1.8.8-doc.tar.bz2.sha256 new file mode 100644 index 0000000..6e2102b --- /dev/null +++ b/openafs-1.8.8-doc.tar.bz2.sha256 @@ -0,0 +1 @@ +ddcc4e0c7d4abce4f1ac607e69c12e7711825f58813e365c4df8e97eb68e9be5 openafs-1.8.8-doc.tar.bz2 diff --git a/openafs-1.8.8-src.tar.bz2 b/openafs-1.8.8-src.tar.bz2 new file mode 100644 index 0000000..6994c24 --- /dev/null +++ b/openafs-1.8.8-src.tar.bz2 @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:daa8ef86a7727facfcde3bc97a6ad143129c1c25ee35f3347080ec7e9d284da0 +size 14863373 diff --git a/openafs-1.8.8-src.tar.bz2.md5 b/openafs-1.8.8-src.tar.bz2.md5 new file mode 100644 index 0000000..8f7061b --- /dev/null +++ b/openafs-1.8.8-src.tar.bz2.md5 @@ -0,0 +1 @@ +b4a622dfb4fa8913aedd72dbe69ebda5 openafs-1.8.8-src.tar.bz2 diff --git a/openafs-1.8.8-src.tar.bz2.sha256 b/openafs-1.8.8-src.tar.bz2.sha256 new file mode 100644 index 0000000..abe99b4 --- /dev/null +++ b/openafs-1.8.8-src.tar.bz2.sha256 @@ -0,0 +1 @@ +daa8ef86a7727facfcde3bc97a6ad143129c1c25ee35f3347080ec7e9d284da0 openafs-1.8.8-src.tar.bz2 diff --git a/openafs.changes b/openafs.changes index f71ba10..952e9d9 100644 --- a/openafs.changes +++ b/openafs.changes @@ -1,3 +1,9 @@ +------------------------------------------------------------------- +Tue Aug 3 22:32:14 UTC 2021 - Christof Hanke + +- update to openafs version 1.8.8 +- remove linux-kmp.patch. Not required at the minute. + ------------------------------------------------------------------- Thu Apr 29 07:01:26 UTC 2021 - Christof Hanke diff --git a/openafs.spec b/openafs.spec index 6cb453d..7cb474f 100644 --- a/openafs.spec +++ b/openafs.spec @@ -57,11 +57,11 @@ # used for %setup only # leave upstream tar-balls untouched for integrity checks. -%define upstream_version 1.8.7 +%define upstream_version 1.8.8 Name: openafs -Version: 1.8.7 +Version: 1.8.8 Release: 0 Summary: OpenAFS Distributed File System License: IPL-1.0 @@ -105,8 +105,6 @@ Source99: openafs.changes Patch3: dir_layout.patch # PATCH-FIX-UPSTREAM make configure detect ncurses 6 correctly Patch4: openafs-1.8.x.ncurses6.patch -# PATCH-FIX-UPSTREAM make KMP bild on Factory -Patch5: linux-kmp.patch # # GENERAL BuildRequires and Requires @@ -122,6 +120,7 @@ BuildRequires: firewall-macros BuildRequires: flex BuildRequires: fuse-devel BuildRequires: git +BuildRequires: glibc-devel-static BuildRequires: krb5-devel BuildRequires: libtirpc-devel BuildRequires: libtool @@ -323,7 +322,6 @@ done %setup -q -n openafs-%{upstream_version} -T -b 0 -b 1 %patch3 -p1 %patch4 -p1 -%patch5 -p1 ./regen.sh