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