commit 6fd90b8544e8d25206eede0ad3cdbb272d30d1ff Author: Benjamin Kaduk Date: Wed Aug 20 15:54:30 2025 -0700 Make OpenAFS 1.8.14pre1 Update version strings for the first 1.8.14 prerelease. Change-Id: Ifcfb5b8ac3c69035d2d3db37db5bbb9e13aa769f Reviewed-on: https://gerrit.openafs.org/16514 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 9550449a4e19a3584990e2bb1aee299cead0d05b Author: Cheyenne Wills Date: Thu May 15 11:29:19 2025 -0600 Update NEWS for OpenAFS 1.8.14pre1 Change-Id: I9aef918229d455f919e8f8a7df6daec0d86a2c6b Reviewed-on: https://gerrit.openafs.org/16298 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk commit b97de39abc3718e8dded53ca4f5787f1df3a2d42 Author: Cheyenne Wills Date: Thu Aug 28 09:58:11 2025 -0600 Linux: Use a stable dentry name in d_revalidate Accessing a stable dentry name (dentry.d_name) directly requires taking the d_lock, which can only be held for a short periods of time and cannot be easily used in d_revalidate The Linux 4.13 commit: dentry name snapshots (49d31c2f389ac) provides a utility function, take_dentry_name_snapshot(), that creates a safe copy of the dentry name. Update the d_revalidate function to obtain a stable dentry name instead of making multiple accesses to the dentry name directly in an unsafe manner. Create wrapper functions get_stable_dentry_name() and release_stable_dentry_name() for take_dentry_name_snapshot() and release_dentry_name_snapshot() to help deal with backward compatibility with Linux versions prior to the 49d31c2f389ac commit. For Linux versions where take_dentry_name_snapshot is available, use the take_dentry_sname_snapshot but also return a pointer to the name that was obtained (name_snapshot.name). For Linux versions prior that do not have the take_dentry_name_snapshot the wrapper function simply returns a pointer to the dentry's d_name.name, so the existing behavior of accessing the d_name remains the same. Add configure checks to determine if take_dentry_name_snapshot exists, and if so check the datatype used within the name_snapshot structure to see if it is a qstr or not. (Some distributions backported the 49d31c2f389ac commit for older Linux kernels, but the name_snapshot structure uses a char * instead of a qstr). Add a compile time check to ensure that Linux provides take_dentry_name_snapshot() after 4.13 so errors during 'configure' don't cause us to silently use the unsafe code path by mistake. Note: This commit doesn't address the issues of using an unstable d_name for Linux versions that do not provide the take_dentry_name_snapshot(). For these versions of Linux, there are problems within the Linux code base itself surrounding the use of the dentry's name. Reviewed-on: https://gerrit.openafs.org/16528 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 84534b5cf468f93ff1e83c8148af90b011124815) Change-Id: I5ea5fadd6c4d9319d902ddf34e23182b1d41e585 Reviewed-on: https://gerrit.openafs.org/16543 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 2f4302f8a0298687bbf557078d061b532a1cfa0a Author: Cheyenne Wills Date: Tue Aug 26 14:32:26 2025 -0600 Linux: Restore using d_name.name in d_revalidate The commit: Linux-6.14: Handle dops.d_revalidate with parent (0306f3fdac736) updated afs_linux_dentry_revalidate to use the 'name' parameter that was introduced in Linux 6.14. The change however is incorrectly using the 'name' parameter (the name that the dentry is expected to have) by not using the qstr length of 'name'. The original code had used dentry parameter's 'd_name.name' field as a NUL terminated string. Both the 'name' and 'd_name.name' are NUL terminated qstr (according to the porting documentation and existing Linux code usage). However 'name' can at times be a pointer to a longer path string where 'name' points to the leading part of that path, and the qstr length determines the length of the leading part. To properly use the 'name' parameter, the qstr length must be used instead of relying on the entire length of the NUL terminated string. Update afs_linux_dentry_revalidate to use the parent's dentry d_name.name field (restoring the way the dentry's name was obtained to what it was prior to the 0306f3fdac736 commit). Note: historically, openafs has been using the dentry d_name.name as a NUL terminated string from at least the initial git commit. And within Linux, the dentry d_name.name has also been treated as a NUL terminated string (current as of 6.16 and going back to at least 2.6.18) It should be noted that the dentry d_name is unstable when d_revalidate is called. A future commit will update the code to use a stable dentry d_name. This commit addresses a problem with excessive DNS queries that was reported to the openafs-info mailing list. Initial analysis and identification of the mistake where done by and . Ref: https://lists.openafs.org/pipermail/openafs-info/2025-August/043532.html Reviewed-on: https://gerrit.openafs.org/16527 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit bcb468db3b0a6b9597aa017b37c237ec78808870) Change-Id: I9c100baf5cc847c306718f1b996cbbe57699235c Reviewed-on: https://gerrit.openafs.org/16542 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit f0f09aaa9180589a72b1dcf92396f393d0902f65 Author: Mark Vitale Date: Thu Aug 28 16:59:29 2025 -0400 CellServDB update 16 Aug 2025 Update all three copies in the tree, and the rpm specfile. Note: The CellServDB file internal comments mention '15 Aug 2025'. But the notification email was sent 16 August, and the CellServDB URL also specifies CellServDB-2025-08-16. Reviewed-on: https://gerrit.openafs.org/16529 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie (cherry picked from commit 75a3a91f5086c011e91bf638e2cc8c03ee373266) Change-Id: Ibc6dab9f4a99d693ea03891ed7222fed9a07a85a Reviewed-on: https://gerrit.openafs.org/16537 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk commit fdfbadd0daef0d05b578f150e84368f03a2e0e81 Author: Andrew Deason Date: Thu Aug 21 10:55:10 2025 -0500 DARWIN: Handle ',' and '/' openssl x509 delims Our logic for extracting MACOS_TEAM_ID from our application signing cert assumes that the output from 'openssl x509 -noout -subject' looks like this: $ security find-certificate -c xxxx -p | openssl x509 -noout -subject subject=UID=SKMME9E2Y8, CN=Developer ID Application: Org (SKMME9E2Y8), OU=SKMME9E2Y8, O=org, C=US That is, the components are delimited by commas. But current macOS uses an 'openssl' from LibreSSL, and the output looks like this: $ security find-certificate -c xxxx -p | openssl x509 -noout -subject subject= /UID=SKMME9E2Y8/CN=Developer ID Application: Org (SKMME9E2Y8)/OU=SKMME9E2Y8/O=Org/C=US That is, the components are delimited by slashes. So currently, this build logic extracts the MACOS_TEAM_ID as something like "SKMME9E2Y8/O=Org/C=US", which is incorrect. Nothing notices the error, and the build proceeds, eventually building binaries with the garbage team id, and so our XPC security checks may always fail for the menu helper and backgrounder. To fix this, try to accommodate both output styles, delimited by either commas or slashes. Add a check to see if the extracted MACOS_TEAM_ID contains extra components, and fail if so, since that suggests we didn't extract it properly. Reviewed-on: https://gerrit.openafs.org/16517 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie (cherry picked from commit 1877621fbcaab3c441c89beff005316602b9ff6d) Change-Id: I31c210b7196f11886bcbc3d2fc3b96962111b2ab Reviewed-on: https://gerrit.openafs.org/16520 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk commit b70b8e650b5c793730466a2296ee4da2f98ecf58 Author: Cheyenne Wills Date: Tue Aug 19 12:07:56 2025 -0600 Linux: only allow one-page folios for writepages Add a check to ensure that large folio support hasn't been inadvertently set on for the address space that is passed to writepages. This should only happen if OpenAFS explicitly enables large folio support. The current OpenAFS support for folios is folio-aware, but does not take advantage of large folios. In order to support large folios (a folio with multiple contiguous pages) a filesystem must opt-in by explicitly setting the min_order on a inode's address space during inode's creation/initialization (e.g. calling mapping_set_large_folios, mapping_set_folio_order_range, etc.). Add an osi_Assert at the beginning of afs_linux_writefolio_cb that checks to see if the folio is a large folio. Reviewed-on: https://gerrit.openafs.org/16513 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit 8784992541997e2399515dc6270c59bfe7c72710) Change-Id: I72b3610bab3ecbd970f8836990e669e5ece3057f Reviewed-on: https://gerrit.openafs.org/16519 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk commit e22cc4ffebbc6dd367673eebb8e0c1b63b4b6027 Author: Mark Vitale Date: Fri Mar 14 12:01:11 2025 -0400 DARWIN: Correct size of arm64 LWP jmp_buf_type to 64-bits Since the introduction of arm64 support, the LWP jmp_buf_type has been 32 bits. This causes LWP programs to fail whenever an LWP stack happens to be allocated above the 4G line: stackcheck = 50462976: stack = 50462976 topstack = 0x50013ff0: stackptr = 0x150008000: stacksize = 0xc000 Fri Mar 14 10:22:04 2025 LWP: stack overflow in process IO MANAGER! from Overflow_Complain() Abort trap: 6 This is due to 32-bit truncation of the LWP context topstack value, as seen in the output above: topstack is reported as 0x50013ff0, but it should be 0x150013ff0. Define the size of jmp_buf_type to be uint64 for AFS_ARM64_DARWIN_ENV. Note: This problem is most frequently observed in cmdebug and bos. Reviewed-on: https://gerrit.openafs.org/16343 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit e0721171d52a85c6835c81d2d83feb8ef8f7a8b4) Change-Id: I927d8c4eeaced4993bf0a936f56477ba5ea94776 Reviewed-on: https://gerrit.openafs.org/16518 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk commit 5e5a92d03d14100eb626ee128d17d31b7f490dca Author: Andrew Deason Date: Mon Feb 3 19:56:27 2025 -0600 DARWIN: Ensure -arch arm64e for MODLD on arm64 Currently, we translate '-arch arm64' into '-arch arm64e' in ARCHFLAGS when linking our kernel module in MODLD. But if we don't have ARCHFLAGS set at all, we'll use the default arch, which is 'arm64' on arm64 (not arm64e). So, if we build without ARCHFLAGS set, the resulting kernel module won't load, because it's the wrong arch. To fix this, if ARCHFLAGS is empty, set it to '-arch arm64e' explicitly for arm64. Reviewed-on: https://gerrit.openafs.org/16211 Tested-by: BuildBot Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Tested-by: Marcio Brito Barbosa Reviewed-by: Andrew Deason (cherry picked from commit f5a16cfb7b19efb2858d1fbd82fbaa2573f28371) Change-Id: I8703b27abd0ed8da5ae51c55ed6f97ba66125a84 Reviewed-on: https://gerrit.openafs.org/16512 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit ebab601bcad47543317209c726af1569fc654408 Author: Mark Vitale Date: Tue Jul 1 15:16:46 2025 -0400 DARWIN: Remove logging AFS mount status in checkAfsStatus() Since commit 4731c8060921 (macos: AFSBackgrounder: improve detection of afs mount status), checkAfsStatus() logs the AFS mount status when afs is not mounted, but this is unnecessary and clutters the log. Remove logging the AFS mount status in checkAfsStatus(). Reviewed-on: https://gerrit.openafs.org/16413 Reviewed-by: Mark Vitale Reviewed-by: Gaurav Saxena Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason (cherry picked from commit c86634dba3b30c870641f577bb84b0517e4045bf) Change-Id: I6111930b2f3ea8c09cf456424c433ba5794d855f Reviewed-on: https://gerrit.openafs.org/16505 Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit a31b416054f7e5de2188ecfb1e59fe7223921197 Author: Cheyenne Wills Date: Thu Jul 31 11:27:53 2025 -0600 linux: convert aops->writepage to writepages As part of the transition from pages to folios, the Linux 6.16 commit: 'fs: Remove aops->writepage' (6b0dfabb35550) removes the writepage member from the address space operations and now requires the writepages member. An earlier Linux commit converted the underlying support of writepages to use folios. The Linux 6.3 commit: 'fs: convert writepage_t callback to pass a folio' (d585bdbeb79aa) requires the callback function passed to write_cache_pages() to expect a folio instead of a page. Since the aops->writepages member predates Linux 2.6.18, testing for its presence is not an accurate check. Instead, we check to see if the write_cache_pages() function takes a callback that uses folios (the d585bdbeb79aa commit). To implement this, afs_linux_write_pages() is added for afs_file_aops.writepages. This function calls write_cache_pages(), which uses the new afs_linux_writefolio_cb() callback to process the folios. The callback's implementation is based on the logic from afs_linux_writepage() but is updated to operate directly on folios. This ensures that multi-page folios are handled correctly, rather than only processing the head page of a folio. Note, this change is retroactive back to linux 6.3. Note, According to the Linux documentation for write_cache_pages, the return value from the writepages should either be 0, or a negative error code. However the existing writepage code can return a positive value (the residual for a partial write). For this commit, the existing behavior of returning a residual is preserved. Reviewed-on: https://gerrit.openafs.org/16437 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit b2c039541d66e0760e7afe8b60539a00778fbfe2) Change-Id: I98d9e4f49fb881a3c076f2caad54649750aca7a6 Reviewed-on: https://gerrit.openafs.org/16502 Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 3e57d358defc12eb573331b2ca9940abedf93f4f Author: Cheyenne Wills Date: Thu Jul 31 09:03:10 2025 -0600 Linux: Rename page->index to page->__folio_index The Linux 6.16 commit: 'mm: rename page->index to page->__folio_index' (acc53a0b4c156) simply renamed the field. Add a autoconf test for page->__folio_index. Create a getter wrapper function, afs_page_index(), that returns page->__folio_index/page->index. Update code that references the page->index with afs_page_index(). Note: Older code that is not conditionally not built for Linux 6.16 (e.g. afs_linux_bypass_readpages and afs_linux_readpages) was not updated to use the wrapper. Reviewed-on: https://gerrit.openafs.org/16439 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 24fdeefe16688d6a5cb7499a22df49d2c5ff9011) Change-Id: Ide2f3a6513a006887db2cc6d7fdef2df33dec347 Reviewed-on: https://gerrit.openafs.org/16501 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit c226a7073270f6f8669581dd31ce787905cc0ded Author: Cheyenne Wills Date: Thu Jul 31 10:46:14 2025 -0600 Linux: Use __readahead_folio The linux 6.16 commit: 'filemap: remove readahead_page()' (c09b997342bcd) removed the readahead_page() function. As a replacement, the function __readahead_folio() is functionally equivalent, except it returns a folio instead of a page. The Linux 5.17 commit: 'mm/filemap: Add readahead_folio()' (9bf70167e3c61) added __readahead_folio() and updated readahead_page() to be just a wrapper for __readahead_folio(). The function readahead_folio() is also just a wrapper around __readahead_folio(), however readahead_folio() is not a direct replacement for readahead_page() as it performs a folio_put before returning the folio. Using __readahead_folio() allows the same logic to be used for pages or folios. Add an autoconf test for __readahead_folio. Create a compatibility wrapper, afs_readahead_folio, for __readahead_folio() / readahead_page(). Add compatibility wrappers: afs_FolioLocked for folio_test_locked/PageLocked afs_unlock_folio for folio_unlock/unlock_page. These compatibility wrappers are for when code is working with folios but are referencing the head page of a folio instead of referencing the folio directly. The Linux functions: folio_test_locked, page_folio, folio_unlock, folio_page were introduced in 5.16. Note: With this change, on Linux 5.17 and later the build will use __readahead_folio instead of readahead_page. However the actual behavior will be the same since readahead_page was nothing more than a wrapper for __readahead_folio. Add curly braces to near by if statements. Reviewed-on: https://gerrit.openafs.org/16438 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 414dfa79a820ef1248a08ba9f9ebbccb44074774) Change-Id: I22126d996246e77cdd8649797cf37dc827edeb81 Reviewed-on: https://gerrit.openafs.org/16500 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 691e90fa1c58d9afb2e26fe6b9022329364ac048 Author: Cheyenne Wills Date: Thu Jul 31 10:20:13 2025 -0600 linux: refactor afs_linux_writepage In preparation for a future commit, refactor afs_linux_writepage() by moving the code that handles locking/obtaining the credential structure, and unlocking the vcache/releasing the credential structure into their own functions, afs_linux_begin_writeback() and afs_linux_end_writeback(). As a precaution, set the pointer to the creds to NULL after freeing it. There are no functional changes other than setting *acredp = NULL after the free. Reviewed-on: https://gerrit.openafs.org/16436 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit eb0bd53b8d03d764861a45cf91faeecda415f5d7) Change-Id: I7b78fd3d37c3fb53ca03f27c7dbc360f69c24a20 Reviewed-on: https://gerrit.openafs.org/16499 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit a580c6388ae08b8af0fa03d866f7db5e9c87a209 Author: Cheyenne Wills Date: Mon Jul 7 16:57:23 2025 -0600 linux: change lookup_one_len to lookup_noperm The linux 6.16 commit: 'VFS: rename lookup_one_len family to lookup_noperm and remove permission check' (fa6fe07d15363) Renamed the lookup_one_len() function to lookup_noperm(). Create a wrapper, afs_lookup_noperm(), to call lookup_noperm() if available, otherwise use lookup_one_len(). Add an autoconf test to determine the presence of lookup_noperm(). The only location that uses afs_lookup_noperm is afs_linux_sillyrename. Within this context, the code does not require the permission check that was part of lookup_one_len(). Reviewed-on: https://gerrit.openafs.org/16435 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit d3c424dcaba6ed8415a7617f0ae3622fe84e988a) Change-Id: Ibe202694162f79defdf546eb4907504856263a4f Reviewed-on: https://gerrit.openafs.org/16498 Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie commit b13960792ddf931f553a1d203014b88c5ba122a8 Author: Andrew Deason Date: Fri Dec 30 19:04:52 2022 -0600 rx: Use add_and_fetch for rx_atomic_add_and_read Our implementation for rx_atomic_add_and_read that uses the __sync builtins currently uses __sync_fetch_and_add. But __sync_fetch_and_add returns the original value, where rx_atomic_add_and_read is supposed to return the new (added) value. Fix it to use __sync_add_and_fetch, which rx_atomic_inc_and_read already uses. This function has been broken in this way since it was introduced, in commit 2758aa7171 (rx: Add the add_and_read function to our atomics), but has never been used. Reviewed-on: https://gerrit.openafs.org/15278 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit d051e9c62f7af40e7d673cec01070336c033b48e) Change-Id: I9971019e7d0744f51e05515455c11449c86883f7 Reviewed-on: https://gerrit.openafs.org/16124 Reviewed-by: Ben Huntsman Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 38cd96ca14b0253fb4181972cbc8b9348fb93ccc Author: Andrew Deason Date: Thu Nov 14 01:45:57 2024 -0600 volser: Add simple shutdown signal handler Currently, the volserver process doesn't register any signal handlers for a shutdown sequence. When the fileserver process group is shutdown, the bosserver sends a SIGTERM to the volserver process, and the volserver process immediately dies. If any volumes are attached by the volserver at the time (e.g., for dumping or restoring a volume), the volume is not cleanly detached, and usually must be salvaged later on before it can be used. This can be confusing to administrators, since a volume may need salvage even though we never logged a reason why the volume got in an unclean/broken state. To improve this situation, add a signal handler to the volserver so we can go through a shutdown process. In the future, we can add a more complex shutdown process that may interrupt running volume transactions, or wait for transactions to go away, or something else. But for now, just as a first step, add a very simple shutdown process that just logs what transactions are being interrupted, so we at least give a clue as to why some volumes were not cleanly detached. With this commit, the volserver now logs some messages if transactions are running when it's shutdown. For example, a VolserLog may look like this: Mon Jan 13 10:11:32 2025 Volserver shutting down on signal 15 Mon Jan 13 10:11:32 2025 Interrupting transaction 2 for volume 536871057 partition /vicepa; volume may need salvage Mon Jan 13 10:11:32 2025 Interrupting transaction 1 for volume 536871052 partition /vicepa; volume may need salvage Mon Jan 13 10:11:32 2025 Volserver shutdown complete With this commit, the volserver process also exits with code 0 on a normal shutdown, instead of being terminated by the SIGTERM signal. The BosLog entry for shutting down a volserver process used to look like this: Mon Jan 13 10:11:32 2025 dafs:vol exited on signal 15 and with this commit, now looks like this: Mon Jan 13 10:11:32 2025 dafs:vol exited with code 0 This commit just adds the signal handler for the pthreaded volserver; don't bother adding a code path for the obsolete LWP volserver. Reviewed-on: https://gerrit.openafs.org/16083 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie (cherry picked from commit e127edeff69c5b8cc3865658b93b548b6b1d8569) Change-Id: Iedb1048f89573ec526012e1f2eb46647d38e03ea Reviewed-on: https://gerrit.openafs.org/16123 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit d6a035c6977d84683f7504197e55dc624bd823e3 Author: Andrew Deason Date: Thu May 11 16:57:32 2017 -0500 afsd: Correctly detect invalid cache dirs afsd has quite a bit of logic for searching through an existing OpenAFS cache dir, and removing extra cache files. Part of this logic currently looks similar to this: if ((vFileNum = GetDDirNumber(currp->d_name, maxDir)) >= 0) { /* we found a valid D1234 dir */ } else if ((vFileNum = GetDDirNumber(currp->d_name, 1 << 30)) >= 0) { /* the D1234 dir we found isn't valid, but only because its * number was too big */ } That is, we check if we found a valid D1234 dir, and whether or not the number for the the dir was too high. We go into different code paths for these, because for fully-valid dirs, we process them like normal. For too-big dirs, we don't want to keep the dir, but we still look inside it to potentially find valid cache files. The problem is, GetDDirNumber doesn't actually use its second argument; it is passed to doGetXFileNumber, where the 'maxNum' argument is never used. Instead, we always check the interpreted number against 'cacheFiles'; that's valid for V1234 files, but not for D-dirs. So, if doSweepAFSCache encounters a D-dir that is only invalid because the number for it is too large, it will process it as if it were a normal valid dir. That means we access cache_dir_list[vFileNum] for that dir, but the 'cache_dir_list' array is only 'maxDir' members long, so writing to that part of the array overwrites some other part of memory. As a result, if afsd is started with a cache that has D-dirs that are much larger than the max dirs needed for the current cache, it can easily abort or segfault as a result of memory corruption. This can happen if a client's cache size is greatly reduced (or some other cache parameters are changed), and the client is restarted with the same cache dir. Reviewed-on: https://gerrit.openafs.org/12612 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 9c1804495d404b4d5b325a7b87789dd54c7fd446) Change-Id: I26c2148d090eacba5086fa7c1ea792e4faf6cbb5 Reviewed-on: https://gerrit.openafs.org/16103 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 7d014c0b9c96e68e3e3cea3505701f84de175784 Author: Marcio Barbosa Date: Tue Jan 24 14:39:20 2023 +0000 fs: Avoid unnecessary lstat() for -literal Currently, GetLastComponent() always stats (lstat) the file received as an argument. However, the status information about this file is only used when 'literal' is false. That said, skip lstat() when 'literal' is true. While here, zero out 'statbuff' at the beginning of GetLastComponent() just to make sure it won't be used uninitialized in the future. Reviewed-on: https://gerrit.openafs.org/14840 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot (cherry picked from commit a0852d93e5b6643a3dcfc535e5e89fed1ad89568) Change-Id: I8ecde79d55be6869fd242170ec331710bb2756ad Reviewed-on: https://gerrit.openafs.org/16102 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 22eceec767012a0b91ab8e2ea831c8c09ae647f9 Author: Mark Vitale Date: Wed Jun 18 10:30:53 2025 -0400 macos: Add support for macOS 26 (Tahoe) This commit introduces the new set of changes/ files required to successfully build and package the OpenAFS source code on MacOS 26 "Tahoe". Reviewed-on: https://gerrit.openafs.org/16396 Reviewed-by: Ganesh G. Chaudhari Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit 6a6f9851f335702b6a1477850afc38a829aa174b) Change-Id: Ibc7a6e6e62ee0fb6bc0a634c2d42ee890145fd4d Reviewed-on: https://gerrit.openafs.org/16433 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 59c1b416655d3d8c986e44968f8a073627ef6ebb Author: Mark Vitale Date: Thu Nov 21 21:35:04 2024 -0500 macos: Set 'ret' in AFSBackgrounder's renewTicket On macOS 14 (Sonoma): If the AFSBackgrounder is running and enabled for automatic renewal of Kerberos tickets, AND if there is no current Kerberos ticket, then the renewal task will 1) fail to prompt for a Kerberos principal and password and 2) throw an exception and crash. Because the launchd task will automatically restart AFSBackgrounder, it will crash repeatedly until either a ticket is manually obtained (via kinit) or the AFSBackgrounder is disabled (by unchecking the Backgrounder checkbox in the OpenAFS preference pane), or the prefpane 'Enable auto-renew' box is unchecked. The root cause for this crash is undefined behavior in renewTicket(): since commit 62cccc4547bd (macos: avoid KLRenewInitialTickets crash in Lion), stack variable 'ret' is never assigned a value before we test it for 0. In previous versions of macOS (10.7 (Lion) through 13 (Ventura)), this code has worked as expected, prompting the user for a Kerberos principal and password. However, with the version of Xcode (Apple clang version 15.0.0 (clang-1500.1.0.2.5)) introduced by macOS 14 (Sonoma), the compiler elides all code after the errant 'if (ret == 0)', including the Kerberos prompt logic (krb5_cc_get_principal). Mitigate the undefined behavior by ensuring 'ret' has a defined value before it is tested. Set it to the error code of krb5_cc_default(), so we won't do anything if krb5_cc_default() fails. Reviewed-on: https://gerrit.openafs.org/15971 Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit 9585f92d785779ae1d0e798f81b896743c1236bd) Change-Id: I9b1844ad87d427e8c6b29da36bc31b2d2fc13e50 Reviewed-on: https://gerrit.openafs.org/16260 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 63c3006bf72dc602e48d111df4b53e0b618c0176 Author: Mark Vitale Date: Mon Jan 13 17:59:29 2025 -0500 macos: Support building solely with Xcode headers Since commit 677b03881481 (macos: tell the compiler the system include path), and macOS 10.15 (Catalina), OpenAFS has required two sets of system headers to build: Xcode.app for the xcodeproj components Command Line Tools for afs.kext In order to make installing the Command Line Tools optional, support building afs.kext with Xcode headers if the Command Line Tools are not present. Reviewed-on: https://gerrit.openafs.org/16136 Tested-by: BuildBot Reviewed-by: Ben Huntsman Reviewed-by: Cheyenne Wills Reviewed-by: Marcio Brito Barbosa Reviewed-by: Andrew Deason (cherry picked from commit cc85ba4f375d482719f0e8dcf216b2f45be7fd3f) Change-Id: If688173b6a59a560bda801155d9c3bbec8a7733b Reviewed-on: https://gerrit.openafs.org/16190 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 6183778941259a8f806105436be8aff7c3134ca1 Author: GANESH CHAUDHARI Date: Tue Jan 28 15:27:34 2025 +0100 macos: Add support for MacOS 15.X (Sequoia) This commit introduces the new set of changes/ files required to successfully build and package the OpenAFS source code on MacOS 15.X "Sequoia". [mbarbosa: added missing components to sysname.m4] Reviewed-on: https://gerrit.openafs.org/15865 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Tested-by: Andrew Deason Reviewed-by: Andrew Deason (cherry picked from commit f9e7b18e14f1ec783d5f4b05dd63ed27659d2f34) Change-Id: I047dc326777bfac777f995304c873e08aa3ccfaf Reviewed-on: https://gerrit.openafs.org/16189 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit eb66d957d84386dceb17217d95842e301d2a259a Author: Mark Vitale Date: Fri Dec 13 16:22:26 2024 -0500 macos: Autodetect kernel headers path for afs.kext Commit 72b2670a9e2e (macos: add support for MacOS 10.14) added *_darwin_180 to the existing Darwin stanza in src/cf/osconf.m4. This specified (as for previous releases): KROOT= KINCLUDES='-I$(KROOT)/System/Library/Frameworks/Kernel.framework/Headers' However, at some point around Mojave 10.14.*, kernel headers were no longer suplied at that path by the operating system installation. Instead, developers were expected to install the Command Line Tools for Xcode (in this case, Xcode 10) to install the kernel headers at: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ System/Library/Frameworks/Kernel.framework/Headers/ This causes OpenAFS builds on Mojave 10.14 to fail with: ... fatal error: 'sys/types.h' file not found #include          ^~~~~~~~~~~~~ 1 error generated. Later, OpenAFS added support for this new path with commit 677b03881481 (macos: tell the compiler the system include path), but implemented it only for macOS 10.15 Catalina (*_darwin_190): KROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk' KINCLUDES='-I$(KROOT)/System/Library/Frameworks/Kernel.framework/Headers' To fix this, test for what path exists instead of hard-coding these paths for specific versions. If none of them exist, disable building the kernel module, or throw an error if it was specifically enabled (similar to Linux's header-detection logic). That way, if there are no headers available, we throw an error much earlier during configure, instead of later during the build. Add this logic in a new autoconf macro, OPENAFS_MACOS_KINCLUDES. To make the logic slightly simpler, change KINCLUDES to be expanded in 'configure' itself instead of during 'make'. NOTE: Although kernel headers are also available by installing Xcode, the OpenAFS build system currently only uses Xcode kernel headers for the Xcode project components (OpenAFS prefpane, afscell, and the aklog plugin). The OpenAFS build system currently uses Command Line Tools kernel headers to build the macOS cache manager kernel extension (kext). Thanks to Ben Huntsman for reporting the issue. Reviewed-on: https://gerrit.openafs.org/15990 Tested-by: BuildBot Reviewed-by: Ben Huntsman Tested-by: Ben Huntsman Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Andrew Deason (cherry picked from commit bb656d901334e110ec4cfc9cfb9f932273d738ea) Change-Id: If955a1317a996b07690e87dcc373435b58adefa5 Reviewed-on: https://gerrit.openafs.org/16188 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 65ec7801f28d56b30a01559b9cfe99effd398d71 Author: Mark Vitale Date: Fri May 5 17:46:12 2023 -0400 macos: Stop passing -sdk to xcodebuild The following OpenAFS macOS platform-specific components are built with 'xcodebuild --sdk ${OSXSDK} --project ...': src/platform/DARWIN/ AFSPreference/OpenAFS.xcodeproj AklogAuthPlugin/AklogAuthPlugin.xcodeproj afscell/afscell.xcodeproj The value of OSXSDK is hardcoded at configure time (in src/cf/sysname.m4) for each major macOS version and platform. However, in recent years, this hardcoded approach has become unsuitable because SDK versions are more likely to change their minor number when Xcode is updated for a minor version macOS update. For example, Xcode versions intended for macos 14 (Sonoma, AFS_DARWIN230_ENV) have increased the SDK version several times: macosx14.0 macosx14.2 macosx14.4 macosx14.5 A similar situation has been observed for most recent versions of macOS, at least back to 10.14 Mojave. If the hardcoded OSXSDK version is not correct, xcodebuild will fail with (for example, on 14 Sonoma): xcodebuild: error: SDK "macosx14.0" cannot be located. make[4]: *** [OpenAFS.prefPane] Error 64 To fix this, just don't pass -sdk at all, and xcodebuild will use whatever sdk is installed (or, if there are multiple sdks installed, the sdk that was specified as the default with xcode-select). Remove the OSXSDK variable, since that's all it's used for. At least for now, keep the existing method of hard-coding the sdk for macOS 10.13 (AFS_DARWIN170_ENV) and earlier, to preserve existing behavior. Use the new variable XCODEBUILD_FLAGS to specify the sdk on these versions. [adeason@sinenomine.net: Remove OSXSDK, introduce XCODEBUILD_FLAGS.] Reviewed-on: https://gerrit.openafs.org/16150 Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Marcio Brito Barbosa Reviewed-by: Ben Huntsman Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 989206eab791ad1356f112cfe774f74cac5d2621) Change-Id: If58e699c2617fd828ae84a97176264549122e6f8 Reviewed-on: https://gerrit.openafs.org/16187 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit d4c8ea9057df13a725c0639f4a783d56e14d31fe Author: Mark Vitale Date: Tue Jan 28 19:53:26 2025 -0500 macos: Remove SDKROOT from AklogAuthPlugin project An attempt to build AklogAuthPlugin with the default SDK fails: xcodebuild --project AklogAuthPlugin.xcodeproj error: unable to find sdk 'macosx10.6' (in target 'AklogAuthPlugin' from project 'AklogAuthPlugin') warning: There are no architectures to compile for because the VALID_ARCHS build setting is an empty list. (in target 'AklogAuthPlugin' from project 'AklogAuthPlugin') ** BUILD FAILED ** Remove the SDKROOT=macosx10.6 specification from the project file. Reviewed-on: https://gerrit.openafs.org/16151 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Andrew Deason (cherry picked from commit 2e149f1c9dbac198e646d63cec54dd2ca83c4e8d) Change-Id: I173056eee67c8e00c4b87420ebf2daea76ba6b42 Reviewed-on: https://gerrit.openafs.org/16186 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit f09826d1651f54529dc04cccb8815f7ea41cd194 Author: Mark Vitale Date: Wed Jan 22 15:30:37 2025 -0500 DARWIN: Allow use of CAST_USER_ADDR_T again CAST_USER_ADDR_T is a Darwin-supplied typedef to assist in address handling between userspace and kernelspace. Commit 81099c479e14 (macos 10.6 64 bit support) disabled AFS_COPYIN's use of CAST_USER_ADDR_T in AFS_DARWIN100_ENV (10.6 Snow Leopard) and higher to prevent issues caused by that release's support for mixed 32-bit or 64-bit userspace and kernelspace. Although this could generate type-mismatch warnings for AFS_COPYIN, they were ignored. However, in recent versions of Xcode (around the release of macOS 14), this warning is now reported as an error: src/afs/afs_syscall.c:373:5: error: incompatible pointer to integer conversion passing 'caddr_t' (aka 'char *') to parameter of type 'user_addr_t' (aka 'unsigned long long') [-Wint-conversion] AFS_COPYIN(cmarg, (caddr_t) dst, sizeof *dst, code); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To eliminate this error, reinstate use of CAST_USER_ADDR_T for modern macOS releases (AFS_DARWIN190_ENV 10.15 Catalina and up) which support only 64-bit userspace and kernelspace. Thanks to Ganesh Chaudhari for reporting the issue and providing a preliminary fix. Reviewed-on: https://gerrit.openafs.org/16142 Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason (cherry picked from commit bac7955a2e892dce1e22629b5858641e7a32bf25) Change-Id: If412eed17f0ac688dba8be569ebc389ee55cda00 Reviewed-on: https://gerrit.openafs.org/16185 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 58ae3117f0f691ffe621c1f219813193975a6742 Author: GANESH CHAUDHARI Date: Wed Jan 15 15:54:03 2025 -0500 DARWIN: Cast arguments to afs_syscall_pioctl() In recent versions of Xcode (around the release of macOS 14), mismatched argument types are now flagged as errors instead of warnings: src/afs/afs_syscall.c:659:22: error: incompatible integer to pointer conversion passing 'afs_int32' (aka 'int') to parameter of type 'char *' [-Wint-conversion] afs_syscall_pioctl(uap->parm1, uap->parm2, uap->parm3, ^~~~~~~~~~ src/afs/afs_syscall.c:659:46: error: incompatible integer to pointer conversion passing 'afs_int32' (aka 'int') to parameter of type 'caddr_t' (aka 'char *') [-Wint-conversion] afs_syscall_pioctl(uap->parm1, uap->parm2, uap->parm3, ^~~~~~~~~~ Add approriate casts to parameters 1 and 3. [mvitale: commit message details] Reviewed-on: https://gerrit.openafs.org/16141 Reviewed-by: Marcio Brito Barbosa Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit 0eb223a36de2f80e11d81fafba10ded6912d3327) Change-Id: Ic77003be33fb73ea49d844b95ebd5318eb3e2908 Reviewed-on: https://gerrit.openafs.org/16184 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 26346652864be952f6b7da7e322302be9f9fe604 Author: GANESH CHAUDHARI Date: Wed Jan 15 17:02:24 2025 -0500 DARWIN: Correct function signature of afs_mount Since commit bb33cbb6eb15 (macos-rollup-20051013) the function signature for afs_mount has been incorrect, resulting in a warning. In recent versions of Xcode (around the release of macOS 14), this is now flagged as an error: /src/afs/DARWIN/osi_vfsops.c:607:4: error: incompatible function pointer types initializing 'int (*)(struct mount *, vnode_t, user_addr_t, vfs_context_t)' (aka 'int (*)(struct mount *, struct vnode*, unsigned long long, struct vfs_context *)') with an expression of type 'int (struct mount *, vnode_t *, user_addr_t, vfs_context_t)' (aka 'int (struct mount *, struct vnode **, unsigned long long, struct vfs_context *)') [-Wincompatible-function-pointer-types] afs_mount, ^~~~~~~~~ To eliminate the build error, correct the function signature by declaring 'devvp' as a vnode_t, not a vnode_t*. (The devvp argument is not used in afs_mount(), so changing the type has no impact on the rest of the function.) [mvitale: commit message details] Reviewed-on: https://gerrit.openafs.org/16140 Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit 41bf672ebc79093d278c75bb8b41659820b2f616) Change-Id: Ie03e9bb133f5aab8d96703583328562765df36be Reviewed-on: https://gerrit.openafs.org/16183 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 0479d5e88e859aed5c55d080e88f4b99c110c822 Author: GANESH CHAUDHARI Date: Wed Jan 15 16:50:44 2025 -0500 DARWIN: Specify 'int' return type for PFI In recent versions of Xcode (around the release of macOS 14), clang yields this error (previously a warning): src/afs/DARWIN/osi_vfsops.c:534:11: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] typedef (*PFI) (); Explicitly specify 'int' for PFI. [mvitale: commit message details; use 'int' rather than 'void' to match corresponding XNU typedef] Reviewed-on: https://gerrit.openafs.org/16139 Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit 3beeb7a6806066e8c07ebf9f9f1fbe407161fb51) Change-Id: Ic83f516e42f200202b4a14ac6105905787eaf634 Reviewed-on: https://gerrit.openafs.org/16182 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 9fb0ae28652f0b093150702c30bc58b87f6bd750 Author: GANESH CHAUDHARI Date: Wed Jan 15 16:31:35 2025 -0500 DARWIN: Skip NULL func ptrs in osi_vnodeops.c In recent versions of Xcode (around the release of macOS 14), clang now reports these former warnings as errors: src/afs/DARWIN/osi_vnodeops.c:163:12: error: incompatible function pointer types initializing 'int (*)(void*)' with an expression of type 'void (*)()' [-Wincompatible-function-pointer-types] {NULL, (void (*)())NULL} ^~~~~~~~~~~~~~~~ src/afs/DARWIN/osi_vnodeops.c:206:12: error: incompatible function pointer types initializing 'int (*)(void*)' with an expression of type 'void (*)()' [-Wincompatible-function-pointer-types] {NULL, (void (*)())NULL} ^~~~~~~~~~~~~~~~ To avoid these errors, simply do not specify the function pointer, and let the rest of the struct value get filled in with zeroes. Also specify a return type for afs_vop_pathconf(), to avoid this error (which clang formerly flagged as a warning): src/afs/DARWIN/osi_vnodeops.c:1841:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] afs_vop_pathconf(ap) ^ [mvitale, adeason: commit message details] Reviewed-on: https://gerrit.openafs.org/16138 Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit 3f64facc10e34145f316decf19e24665682f8db9) Change-Id: Id0694a0559bf9208e2bf29b5f2aaeb03ff5d0097 Reviewed-on: https://gerrit.openafs.org/16181 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 8d29c0fe7864d68fbf92423be02f95d8a171fb59 Author: GANESH CHAUDHARI Date: Wed Jan 15 16:17:18 2025 -0500 DARWIN: Define return type for getinode() In recent versions of Xcode (around the release of macOS 14), clang now flags the lack of a return type for these functions as errors instead of warnings: src/afs/DARWIN/osi_inode.c:30:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] getinode(fs, dev, inode, vpp, perror) ^ src/afs/DARWIN/osi_inode.c:60:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] igetinode(vfsp, dev, inode, vpp, va, perror) ^ Eliminate the errors by explicitly declaring each function as return type 'int'. [mvitale: commit message details] Reviewed-on: https://gerrit.openafs.org/16137 Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit 6e0b549fd54ab3815d65425330b9bb66fbed3626) Change-Id: I18d6054a51f31f53b998b254d50d469b463efc1c Reviewed-on: https://gerrit.openafs.org/16180 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit e4b9b8defd04bc6e804f97ebb14edac734c3942e Author: Marcio Barbosa Date: Wed Jan 22 12:28:29 2025 +0000 DARWIN: Set parent of volume root vnodes Vnodes that lack a parent can lead to inaccurate ENOENT errors on macOS. To prevent this issue from occurring, ensure that the parent of volume root vnodes is always set when evaluating them. Thanks to gangovind@in.ibm.com, who originally brought attention to some of the side effects of this problem. This commit is the product of collaborative efforts by mbarbosa@sinenomine.net, adeason@sinenomine.net, and kaduk@mit.edu. Reviewed-on: https://gerrit.openafs.org/16032 Reviewed-by: Marcio Brito Barbosa Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit fc3255eff69fda9a782961e636064e0699f7d966) Change-Id: Ib68358647ec10017b2f0ac7956b8fd649592ed1d Reviewed-on: https://gerrit.openafs.org/16179 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 72dd3dc79f77c8d4dfceaaddbc9b2993ca297249 Author: Andrew Deason Date: Mon May 25 16:48:37 2020 -0500 afs: Remove 'retry' arg from afs_FindVCache Since OpenAFS 1.0, afs_FindVCache has had an optional 'retry' output arg. The relevant functionality appears to have been specific to Irix versions before 5.3, but even OpenAFS 1.0 only had param.h files and general build logic for Irix 6.2 and later. With commit 13e44b2b (afs: Refactor osi_vnhold/AFS_FAST_HOLD), the unused 'retry' argument has now been removed from the lower-level osi_vnhold function, so now remove it from afs_FindVCache and related comments, and remove the associated logic to handle a non-zero 'retry'. Reviewed-on: https://gerrit.openafs.org/14231 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit 1c3d360de6045eb38e0348e2bc5e7b40a3d5b1de) Change-Id: Ibfcbba21ade3718a09181aebeffe785c3ebda5e3 Reviewed-on: https://gerrit.openafs.org/16251 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 73040e891713bce762d93514e01b2c698eae45dc Author: Andrew Deason Date: Wed Jul 10 12:42:44 2019 -0500 afs: Remove useless afs_GetVCache arguments The 'avc' argument in afs_GetVCache has never been used, all the way back to OpenAFS 1.0. The 'cached' argument was set correctly, but none of its callers ever looked at the result of 'cached'. Remove these useless arguments. afs_LookupVCache and afs_GetRootVCache also had the same 'cached' argument, which was also never used by callers. Remove it for those, as well. Reviewed-on: https://gerrit.openafs.org/13681 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 3b0a9ff6af68c88d656aefe2242f12a7a9e04969) Change-Id: I1a5dab9e3f1e5316438f614d0a89be6f18936ba2 Reviewed-on: https://gerrit.openafs.org/16250 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit b469c8917515656b01962a849d574dffcfa0601a Author: Andrew Deason Date: Thu Jul 3 15:55:06 2025 -0500 DARWIN: Use 'cp -n' for privhelper 'backup' task Commit 75da4edd3c (DARWIN: Convert prefpane backup ops to privhelper) converted the backup-related prefpane operations to use our privhelper binary. But this also changed our behavior to always overwrite an existing .afscommander_bk backup file, where previously we left any existing .afscommander_bk file alone. To preserve the original behavior, pass '-n' to our 'cp' command, so we don't clobber an existing file. Reviewed-on: https://gerrit.openafs.org/16414 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Ganesh G. Chaudhari Reviewed-by: Benjamin Kaduk (cherry picked from commit 4ff4f85d0921a1c9dba31a31e34e68a7b59bd7fa) Change-Id: I0ec60871fd16463b4d64a09b6c24d67e908e2960 Reviewed-on: https://gerrit.openafs.org/16444 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 78f5daf8bd79603c53630ba6eb712ab87ebc5dc5 Author: Andrew Deason Date: Fri Jun 27 13:33:18 2025 -0500 LINUX: Remove test for DCACHE_NFSFS_RENAMED The symbol DCACHE_NFSFS_RENAMED has existed in Linux for a long time, well before the 2.6 version series. This is before our minimum supported Linux kernel version of 2.6.18, so we don't need to check for it anymore. Remove the configure test, and remove all references to HAVE_DCACHE_NFSFS_RENAMED (assuming it's always true). Keep the afs_linux_clear_nfsfs_renamed() et al abstractions, since they may help keep the code more readable, but fix their formatting while we're here. Reviewed-on: https://gerrit.openafs.org/16409 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit f0f3fe56769b219f4741457948394b7f1b0b5b7a) Change-Id: I95b1fa2fff35bac5dfe1b0d3fced6744ca87e9e7 Reviewed-on: https://gerrit.openafs.org/16432 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 39ce8f11df2d650bb4d86c76c127c292880a5c76 Author: Andrew Deason Date: Mon Jun 2 12:18:19 2025 -0500 LINUX: Use folio_page() to convert folio to page A few pieces of code are currently converting a folio into a page via &folio->page. But the macro folio_page() can do this for us; use that instead, so we don't need to know the details of how folios/pages are stored together. The macro folio_page() was introduced in Linux commit 7b230db3b8d3 (mm: Introduce struct folio), and so should always be available when folios themselves are. Reviewed-on: https://gerrit.openafs.org/16389 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit f168b1432175ef1d624cd80736864828c5efbe18) Change-Id: I0c7acd39e493963ebcb28c83fbda8452296edbd2 Reviewed-on: https://gerrit.openafs.org/16431 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 0c44e9f27fd0e058b59a9b63d755036829590e81 Author: Cheyenne Wills Date: Tue May 27 13:46:54 2025 -0600 Linux: Use __filemap_get_folio() The Linux 6.15 commit: mm: Remove grab_cache_page_write_begin() (e33ce6bd4ea2) removed grab_cache_page_write_begin() which had been a wrapper for __filemap_get_folio(). The functions __filemap_get_folio() and filemap_get_folio() were introduced in the Linux 5.16 commit: mm/filemap: Add filemap_get_folio (3f0c6a07fee6) Add a new configure test for __filemap_get_folio(). The function afs_linux_write_begin() can only use __filemap_get_folio after the Linux 6.12 commit: fs: Convert aops->write_begin to take a folio (1da86618bdce3) (HAVE_LINUX_WRITE_BEGIN_END_FOLIO) Replace the call to grab_cache_page_write_begin() with __filemap_get_folio() and use folio_unlock()/folio_put() to release the folio. Note: The function grab_cache_page_write_begin() was introduced in Linux 2.6.29 where it renamed __grab_cache_page() and added additional parameters. It was added in the Linux 2.6.29 commit: fs: symlink write_begin allocation context fix (54566b2c1594) To handle kernels older than 2.6.29, OpenAFS has had its own version of grab_cache_page_write_begin() that simply front-ended __grab_cache_page(). Add an additional preprocessor check to not build with the openafs version of grab_cache_page_write_begin if __filemap_get_folio() is available. NOTE: To summarize the timeline of when Linux features where added or changed: Linux 2.6.9 added the grab_cache_page_write_begin Linux 5.16 added the __filemap_get_folio as a replacement for grab_cache_page_write_begin for use with folios Linux 6.12 converted aops->write_begin to use a folio Linux 6.15 removed grab_cache_page_write_begin Reviewed-on: https://gerrit.openafs.org/16374 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit f1b8ca0d664f018a6393e54133413ec4fe9f4e28) Change-Id: I992de9b4ac77ab502ba6da2ee902b2540bbad0bb Reviewed-on: https://gerrit.openafs.org/16430 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit d946ce6f218a2013bc002fb44ad23b89f2d21212 Author: Cheyenne Wills Date: Thu Jun 26 10:07:20 2025 -0600 Linux: Refactor afs_linux_write_end()/begin() Refactor afs_linux_write_end() and afs_linux_write_begin() to separate the folio and non-folio related code. This allows reducing some of the preprocessor statements that are within the body of the functions. The non-folio related code should be stable, while the folio related code will see changes in the near future. There are no intended functional changes in this commit. The new folio variant of afs_linux_write_begin() now avoids setting the *foliop output argument on error to be safe, but this should not cause any visible change in behavior. Reviewed-on: https://gerrit.openafs.org/16387 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 53eef69e274aa25b1768442f334a88676abf0011) Change-Id: I051499b61e035185883eb97fe1a5a6363e50a6b0 Reviewed-on: https://gerrit.openafs.org/16429 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 16070e998960f7fe0c15dfa13b88c7b1fa36dce2 Author: Cheyenne Wills Date: Sun Jun 1 07:22:08 2025 -0600 Linux: Use folio_wait_locked() The Linux 6.15 commit: mm: Remove wait_on_page_locked() (d96e2802a802) removed the compatibility wrapper wait_on_page_locked(). The replacement is folio_wait_locked(). The Linux 5.16 commits: mm/filemap: Add folio_wait_locked() (6baa8d602e84d) mm: Add folio_put() (b620f63358cd3) added folio_wait_locked, updated wait_on_page_locked to be just a wrapper for folio_wait_locked(), and added folio_put(). Introduce wrapper functions afs_page_wait_locked() and afs_put_page(). If folio_wait_locked() is available, these 2 wrappers will take a page and and use the associated folio interface, otherwise use the older page related interfaces. Since they were added in the same Linux version, assume that folio_put() is available if folio_wait_locked() is available, to avoid an extra configure test. Reviewed-on: https://gerrit.openafs.org/16375 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit aadc02227fdd3728404c8763ae4842dee88a6668) Change-Id: I2c1e494b885614dd8ca5177fe4b61f8a725cb1ba Reviewed-on: https://gerrit.openafs.org/16428 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 62e2df3182bea9ea7d5e86d4d3a0dfc955bc3753 Author: Cheyenne Wills Date: Thu Jun 26 10:12:57 2025 -0600 cf: check for dentry flag macros/enums Linux 6.15 commit: dcache: convert dentry flag macros to enum (b2b4483b5d05) converted the dentry flag macros to an enum. Because these flags are now enums, a preprocessor #ifdef can no longer be used to test to see if the symbol is present, so a different form of test is needed. Introduce a new autoconf test, AC_CHECK_LINUX_SYMBOL that takes a symbol and an include and tries to assign the symbol to an integer variable. Add a new autoconf file, 'linux-kernel-symbol.m4' to hold the individual tests. Use the new AC_CHECK_LINUX_SYMBOL to test for the DCACHE_NEED_AUTOMOUNT and DCACHE_NFSFS_RENAMED flags. Reviewed-on: https://gerrit.openafs.org/16377 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit bb4e15e58af92371c08b5cc41a1682cd8c96fd2f) Change-Id: If45498d60c695d6d8bf860338b9c9442ddc08bc4 Reviewed-on: https://gerrit.openafs.org/16427 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit eeb4f7012ce8b22ff24d073e52e837ef36507afb Author: Cheyenne Wills Date: Thu Jun 26 10:08:49 2025 -0600 linux: Make iops mkdir return a struct dentry * The Linux 6.15 commit: 'Change inode_operations.mkdir to return struct dentry *' (88d5baf69082) changed the signature for the return value for mkdir member of the inope_operations structure. The new return value for mkdir needs to be as follows: NULL if the directory was created and no other dentry was used ERR_PTR() if an error occured non-NULL pointer to a different dentry was used. OpenAFS does not use a different dentry, so returning NULL or ERR_PTR is sufficient. Introduce a new autoconf check to determine if the inode_ops.mkdir needs to return a pointer to a dentry. Update afs_linux_mkdir to use ERR_PTR() on the return value. Reviewed-on: https://gerrit.openafs.org/16373 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 0c0280ed1324252c487409f0db9a8e215575fef4) Change-Id: I96af366fc70076980ba0ba10e4b30f1db0f65e78 Reviewed-on: https://gerrit.openafs.org/16419 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit e76b520f1316e7059a7855078f117ce194734317 Author: Cheyenne Wills Date: Sun Jun 1 06:57:55 2025 -0600 Linux: Add required MODULE_DESCRIPTION The Linux 6.15 commit: "modpost: require a MODULE_DESCRIPTION()" (6c6c1fc09de3) changed the Linux build process to require the MODULE_DESCRIPTION. Add a MODULE_DESCRIPTION() to the kernel modules, including the code template used in autoconf tests. Reviewed-on: https://gerrit.openafs.org/16372 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit f2705de3ded4e194bd447d88013076e707ff33d1) Change-Id: I7fefbb6c1960948dee6424f11789af19b07d3e84 Reviewed-on: https://gerrit.openafs.org/16418 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit b00bf7c50baf5e301f7f58b56e06dc28ea52e69d Author: Götz Waschk Date: Thu Jun 5 10:00:00 2025 +0200 Update kmodtool to accommodate two-digit EL major releases With the advent of EL10, we need to update our tooling to not accept EL6-9 only. Reviewed-on: https://gerrit.openafs.org/16392 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit b065ba37a7c92d0faea1ceb3ea7df8ad45015570) Change-Id: I753a664c9685cb58a86e9c8c3055b0e3d0ca8e93 Reviewed-on: https://gerrit.openafs.org/16422 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: Benjamin Kaduk Reviewed-by: Benjamin Kaduk commit b2a37b479501859d564f9f7a618afe59e983783a Author: Cheyenne Wills Date: Tue Jul 1 14:33:14 2025 -0600 Redhat: Disable using lto when building rpms Several Linux distros (fedora 33, RHEL9, etc.) are injecting the lto option into the compiler flags when building rpms. This option results in several warnings associated with code analysis that are now being reported at link time instead of compile time. An initial review of the warnings show that at least some are false positives. Some warnings have already been addressed by ignoring them during the compile phase (e.g. format-truncation in v5der.c) but are now showing up again in the link phase. Other warnings are due incorrect analysis (e.g. reports of trying to free non-heap objects within afs_xdr_string). Disable the use of lto when building rpms until further analysis can be done to 1) determine how to suppress these warnings and 2) test to ensure that lto does not introduce any runtime bugs. To disable the option, add '%global _lto_cflags %nil' to the openafs.spec file per: https://fedoraproject.org/wiki/LTOByDefault Note: that SuSE has been disabling the lto option within their openafs rpm spec file. Reviewed-on: https://gerrit.openafs.org/16406 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie (cherry picked from commit e9065b19f387648baa893898785075036bff9b5b) Change-Id: Ia3c9f79876020a4623043e9ac59df562d691817c Reviewed-on: https://gerrit.openafs.org/16426 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit d36881fc666031a1bfc9beb627e3dbfd598cb2ae Author: Cheyenne Wills Date: Tue May 27 10:35:49 2025 -0600 Linux: dkms set dkms.conf CLEAN parameter to true The dkms 3.1.8 commits: (754f26f93a50) "dkms: omit deprecation warning for CLEAN=true" (cdad56500434) "dkms: deprecate CLEAN" (f93a40aec3b9) "dkms: stop running the CLEAN command" made the CLEAN parameter obsolete and cause dkms to issue a deprecation message (without failing the build) if the value of CLEAN is not the literal string `true`. Since dkms v0.2.18, dkms performs builds in a temporary build directory that created and populated prior to the build step. The dkms.conf generated by openafs.spec currently includes the statement: CLEAN="if [ -e src/libafs/Makefile ]; then make -C src/libafs clean; else true; fi" With commit 754f26f93a50, dkms (version 3.1.8 and newer) emits a deprecation message because the value for this CLEAN setting is not `true`. .... Building module(s)... Signing module /var/lib/dkms/openafs/1.9.2-1.224.g7f45a8.el9/build/openafs.ko Deprecated feature: CLEAN (/var/lib/dkms/openafs/1.9.2-1.224.g7f45a8.el9/source/dkms.conf) Installing /lib/modules/5.14.0-70.26.1.el9_0.x86_64/extra/openafs.ko.xz Researching the history of dkms, the original commit (tag v0.22.04) would perform the build [for the openafs kernel module] within the openafs source tree, which would require performing some sort of clean, with the next commit (tag v0.23.18), dkms was changed to first copy the source for the openafs into a fresh temporary build area then do the build withing that directory, so performing a clean before the build is unnecessary. Update the RedHat/openafs.spec.in file to create dkms.conf with: CLEAN=true NOTE: Prior to 3.1.8, the value for CLEAN= is a command that is executed before the build step, so setting the value to true simply executes the 'true' command. Reviewed-on: https://gerrit.openafs.org/16386 Reviewed-by: Michael Laß Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot (cherry picked from commit 8849df9f895feac6231d05a07f9c9e8a53f5b0a6) Change-Id: I9d6d4e9ba4fcd26540005deeb34218be01352e5d Reviewed-on: https://gerrit.openafs.org/16423 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 1e1f172222dd64e30c696168cf021b156cc3c155 Author: Cheyenne Wills Date: Fri May 23 14:59:05 2025 -0600 Linux: Use `yes` for dkms's NO_WEAK_MODULES parm The dkms 3.1.9 commit: (65ad4814d67f) "Update man pages" added a check for the NO_WEAK_MODULES parameter, enforcing its value to be either `yes` or `no` (case insensitive). Any other value causes dkms to fail with an error (from an alma9 system with dkms 3.2.1 installed): dkms.conf: Error! Unsupported NO_WEAK_MODULES value 'true' Error! Bad conf file. File: /var/lib/dkms/openafs/1.8.13.2-1.el9/source/dkms.conf does not represent a valid dkms.conf file. warning: %posttrans(kernel-core-5.14.0-570.12.1.el9_6.x86_64) scriptlet failed, exit status 8 Error in POSTTRANS scriptlet in rpm package kernel-core To fix, update the dkms.conf file generated by the openafs.spec file to use `yes` instead of `"true"` for the NO_WEAK_MODULES parameter. Reviewed-on: https://gerrit.openafs.org/16385 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit f35d900c0a7c1e7acb3aab87c533eef83322eb72) Change-Id: I178a31940cf6f8875db57774430e37ad50d6f412 Reviewed-on: https://gerrit.openafs.org/16420 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 8f494cabb7b68521d71ea8955f161e36e4429f5e Author: Michael Meffie Date: Fri Mar 20 18:17:56 2020 -0400 redhat: add make to the build requirements `make` is not necessarily installed, even if when all the other build requirements are installed. Add `make` to the list build requirements to complete the build requirements. With this change it is possible to build the packages after running the `yum-builddep` to install all of the needed build requirements. Reviewed-on: https://gerrit.openafs.org/14119 Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit be50d9a517bda9f421414341bca34c0100d61ba0) Change-Id: I5f83a1b7d0b7e2ed2727f1d0f9c4f37adbc0bb8f Reviewed-on: https://gerrit.openafs.org/16417 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit d65bec9cbe1093f0749a0af2c84e848f5dee769e Author: Michael Meffie Date: Fri Mar 20 17:53:22 2020 -0400 redhat: fix rpmbuild warnings Fix warnings issued by recent versions of rpmbuild: warning: Macro expanded in comment on line 110: %{afsvers}/... warning: extra tokens at the end of %endif directive in line 1469: %endif # build_userspace warning: line 331: It's not recommended to have unversioned Obsoletes: Obsoletes: openafs-client-compat The first two warnings are just issues with comments, which apparently are not completely ignored by rpmbuild. The third issue is a warning about an unversioned "Obsoletes" directive. Remove the old Obsoletes for openafs-client-compat, which was obsoleted no later than the 1.4.x series (more than 10 years ago). While here clean up the spec by removing the old cvs $Revsion$ keyword from the comments at the top of the file, and removing an old commented out setup directive. Reviewed-on: https://gerrit.openafs.org/14118 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 30a47c3282cb405459a6fced1fe5b4c77f4afd64) Change-Id: Ia331c087bc2ff83086f5da845d02a852f955ae65 Reviewed-on: https://gerrit.openafs.org/16416 Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 76944d626a2f7a53a53d3b8aa9d1ee938b9463b6 Author: Michael Meffie Date: Wed Apr 9 08:58:28 2025 -0400 ktime: Add day validation to ktime_DisplayString() The ktime_DisplayString() function will crash when the given 'day' has a value outside the valid range of 0 to 6. Add an check to ensure the given 'day' is in range, and if not, return EINVAL instead of crashing. Add unit tests to check out of range day input values. The ktime_DisplayString() function is generally unsafe and should be avoided in new code, since it does not check the input buffer length. Use of this function in within OpenAFS is currently limited to the 'bos getrestart' command in the bos client. Reviewed-on: https://gerrit.openafs.org/16362 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 39f7a56e334ff8c2ae2116aa71b9f17dde18cc94) [1.8: This does not contain the changes to tests/util/ktime-t.c from master, since 1.8 does not contain relevant prereq changes to the unit tests.] Change-Id: I41c46405701babd4e0a6189d864f13b642541aeb Reviewed-on: https://gerrit.openafs.org/16442 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 2cd4ad30c90062dcac7471718b8a1bd6629a3de8 Author: Mark Vitale Date: Wed Jul 17 22:07:45 2019 -0400 rx: add missing CLEAR_CALL_QUEUE_LOCK to LWP rx_GetCall In all other places where we remove an rx_call from a queue, we also CLEAR_CALL_QUEUE_LOCK. This isn't necessary in the LWP (non-RX_ENABLE_LOCKS) version of rx_GetCall because rx_call does not have member call_queue_lock for LWP. However, for the sake of consistency for future maintainers, add a CLEAR_CALL_QUEUE_LOCK here as well; it is a no-op for LWP. No functional change is incurred by this commit. Reviewed-on: https://gerrit.openafs.org/13695 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit dc99144da54d12e8a168c3dfb0255e2a40ba321f) Change-Id: I868de3f99939bde8216c4e64c93cce96b4fa5356 Reviewed-on: https://gerrit.openafs.org/16122 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit c5708080a6a1f21bbcfe954277215e38d0598dd3 Author: Mark Vitale Date: Thu Mar 14 23:15:29 2019 -0400 rx: clear call_queue_lock after removing call from queue The call_queue_lock is set to either rx_serverPool_lock or rx_freeCallQueue_lock, depending on whether an rx_call resides in the rx_incomingCallQueue or the rx_freeCallQueue, respectively. This value is used by rxi_ResetCall to lock the appropriate queue before removing a call. Therefore, the call_queue_lock should be cleared after a call is removed from a queue. This issue has no known external symptoms; however, repairing this is helpful to developers examining core files. Repair two instances where the call_queue_lock is not cleared. Reviewed-on: https://gerrit.openafs.org/13641 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit e87c40f4546ee9c31b2eaad2a24be9fb9a0b25b1) Change-Id: I10a56e2e50779f101a8191835f8a809c17f5ceaf Reviewed-on: https://gerrit.openafs.org/16096 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit ba0a5099a5521d176562d13ad580747ba8fb5f40 Author: Michael Meffie Date: Fri Jan 10 10:54:20 2020 -0500 tests: skip vos tests when a vlserver is already running The vos tests start a temporary vlserver process, which is problematic when the local system already has an installed vlserver. Attempt to temporarily bind a socket to the vlserver port, and if unable to bind with an EADDRINUSE error, assume the vlserver is already running and skip these tests. Reviewed-on: https://gerrit.openafs.org/14021 Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit bf1b3e2fc12a7502cfd74eb109eeb7131f7230d3) Change-Id: I6e69ead0680aac0cf1a9bc2cb0687fc0b425ecf0 Reviewed-on: https://gerrit.openafs.org/16093 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 0ed2d4a1266c90b9c672666b0ac5f029df5a20ff Author: Andrew Deason Date: Fri Sep 29 17:22:42 2023 -0500 doc: Update example output for 'fs getfid' The output for 'fs getfid' was changed in commit d390df097c (fs getfid output changed for consistency with Windows implementation), but the manpage still had the old output in its examples. Update the manpage to reflect the current behavior of 'fs getfid'. Reviewed-on: https://gerrit.openafs.org/15587 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit 4dfae3fe35037bee671934ba34269364920841b3) Change-Id: I787b4a639e8881f059cb4f547025b664842aa67e Reviewed-on: https://gerrit.openafs.org/16082 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk commit 82063bde8f61fc0a997fe88ec64bbfc26fbdb97c Author: Andrew Deason Date: Fri Aug 2 21:55:55 2024 -0500 packaging: Check for nonzero $? for command failure In a few perl scripts (that happen to be for macOS), we check whether '$? >> 8' is zero to see whether a command failed. But the value of '$? >> 8' is just the exit code of the process. If it instead, for example, was killed by a signal, there is no exit code, and '$? >> 8' may not be accurate (the terminating signal is in '$? & 127'). We should check if $? is nonzero at all to see if an error happened. To avoid any possible issues, update all of our checks for command failure to check if $? is nonzero, instead of '$? >> 8'. In notarize.pl, print out the whole status in addition to the exit code, just to be clear in case the command somehow terminates from a signal. Reviewed-on: https://gerrit.openafs.org/15980 Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Marcio Brito Barbosa Tested-by: Andrew Deason Reviewed-by: Andrew Deason (cherry picked from commit 9ef6aac17a7fca5bd1ca6b77459f3d7b48bbf018) Change-Id: I481131f2ab0ff0cfc82e6452facfd8b508a4e56c Reviewed-on: https://gerrit.openafs.org/16078 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 1ed9d09b0caa9701eb4c3b0eda45ce449b1cdea5 Author: Marcio Barbosa Date: Mon Dec 16 06:42:04 2024 -0800 DARWIN: Add --with-macos-* packaging options To create the OpenAFS client for macOS, the current process involves building the code, signing the binaries, creating the package, and notarizing it. Each step is typically performed separately and requires distinct parameters and credentials, making this process cumbersome and difficult to follow. To simplify this process, introduce the following '--with' options: --with-macos-app-key --with-macos-inst-key --with-macos-keychain-profile These options allow users to specify the credentials needed for signing and notarizing the package upfront. With these enhancements, users will be able to perform the entire workflow - building, signing, creating, and notarizing the package - with a single 'make packages' command, significantly simplifying this process. Reviewed-on: https://gerrit.openafs.org/15977 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: Andrew Deason (cherry picked from commit e316a38ba960dce3a5b6b022a5bf5dee4081c95f) Change-Id: Ie4c54672d6033a3c976a00a3004845b1f61e3e1b Reviewed-on: https://gerrit.openafs.org/16077 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit f82998dbad1f1b5aa55449127e15d32306665328 Author: Marcio Barbosa Date: Thu Dec 12 14:51:11 2024 -0800 DARWIN: Use notarytool for notarization At WWDC 2021, Apple introduced notarytool, a new utility for interacting with the Apple notary service. Concurrently, Apple deprecated altool for notarization purposes, with plans to discontinue its functionality on November 1, 2023. Currently, notarize.pl relies on the deprecated altool, which is no longer supported. This commit updates this script to use notarytool, ensuring it remains fully functional for notarizing the OpenAFS package. Note that the arguments for notarize.pl have changed. Users can no longer provide a plain password or keychain reference using the @keychain prefix. Instead, a keychain profile for the credentials must be created first, with the profile name provided as an argument. This change is mandated by the new notarytool workflow. Additionally, update pkgbuild.sh.in, as this script calls notarize.pl if the --apple-id option is provided. Since notarize.pl now requires a keychain profile name instead of an Apple ID and password, remove the --apple-id option from pkgbuild.sh.in and introduce a new option, --keychain-profile, which specifies the name of the keychain profile to be used by notarize.pl. Reviewed-on: https://gerrit.openafs.org/15976 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 519a170da3aa0a4a5511e87b0cc232c763a92ff1) Change-Id: I44f26a3a22ae443618f31db9c6387ba86b0d62e9 Reviewed-on: https://gerrit.openafs.org/16076 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk commit f7392a3579b9c452ceb9b95c7c96603e01146f4e Author: Michael Meffie Date: Wed Dec 18 21:20:43 2024 -0500 DARWIN: Ignore more build artifacts Several build artifacts are missing from the gitignore rules when building on macOS. For example: $ git status --porcelain ?? src/libafs/afs.x86_darwin_210.plist ?? src/platform/DARWIN/PrivilegedHelper/org.openafs.privhelper Update the gitignore rules to ignore generated darwin plist files and the prefpane "privileged helper" binary. Reviewed-on: https://gerrit.openafs.org/16002 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Mark Vitale (cherry picked from commit c4939de47dc2c84d4acaf5a5deec46298f3dabe9) Change-Id: I9eb4e8a4d0a075c841f98b9b3caee6e3abd95260 Reviewed-on: https://gerrit.openafs.org/16075 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 6317152ffdd3901e0101eaab811bb2da799aa0c9 Author: Marcio Barbosa Date: Sat Nov 23 05:30:37 2024 -0800 DARWIN: Convert prefpane write ops to privhelper Convert the prefpane logic for writing to config files to use privhelper, so it can work with macOS 10.8+. With this commit, the "CellServDB Editor" and "Parameter" tabs in the prefpane should now work. Specifically, define the privhelper task "write". Define a new variant to TaskUtil's executePrivTask() called executePrivTaskWrite() to use the new task type, and convert the prefpane code to use it. Most files are straightforward, but converting writeAfsdOption() is a little awkward due to the repeated checking of useAfsdConfVersion. Just remove the writeAfsdOption() method and make the caller choose between writeNewAfsdOption() and writeOldAfsdOption(). The new "write" task takes a new argument (data) to indicate what data to write to the config file in question. Like the "backup" task, it also takes a "filename" argument that is checked against our list of config files. Reviewed-on: https://gerrit.openafs.org/15960 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 14777a2db4ec171df0709185aebe89e10e06336f) Change-Id: I166f82676e054b32dc5b0906de4a4c557677f1f2 Reviewed-on: https://gerrit.openafs.org/16074 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 3753ee04d6e382575eebb439f9ca6fa7621ef43d Author: Marcio Barbosa Date: Sat Nov 23 03:44:04 2024 -0800 DARWIN: Convert prefpane backup ops to privhelper Convert the prefpane logic to backup various config files to privhelper, so it can work with macOS 10.8+. Specifically, define the new privhelper task "backup". Define a new variant to TaskUtil's executePrivTask() called executePrivTaskBackup() to use the new task type, and convert the prefpane code to use it. Remove the backupFile() method, since it's now unused. The new "backup" task has an argument (filename), so we don't need to define separate tasks for each file we want to backup. But check the given filename against a short list of files we know we deal with, just to make sure we don't accidentally mess with some other system file, since we're running as root. Reviewed-on: https://gerrit.openafs.org/15959 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 75da4edd3cc6adb810e31a9cb1558f75f418bd08) Change-Id: Ibdabe3d2002388961724d75aa6164157d653413c Reviewed-on: https://gerrit.openafs.org/16073 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 3c93a59ab9540d2d0fb207ffb238b6830aad9f78 Author: Mark Vitale Date: Tue Mar 30 18:51:39 2021 -0400 macos: AFSBackgrounder: improve detection of afs mount status The OpenAFS preferences for MacOS provide two ways to start or stop the cache manager: - Preference pane button: [Startup] or [Shutdown] - AFS Menu item: 'Startup AFS' or 'Shutdown AFS' Only one choice (startup or shutdown) is displayed in each UI element, based on the current state of the cache manager according to checkAfsStatus(). Unfortunately, checkAfsStatus() determines cache manager state by issuing a 'df' command and searching the output for AFS_FS_MOUNT "AFS". This heuristic is fragile and easily fooled by any "AFS" string in the output. For example, the OpenAFS installer .dmg mounts itself as "OpenAFS". The presence of "AFS" causes checkAfsStatus to believe that AFS is mounted. Therefore the OpenAFS GUI will display only the "Shutdown" choice, regardless of the true state of AFS. If AFS is already shutdown, it is impossible to start the cache manager via the GUI until the installer image is ejected. Modify checkAfsStatus to use a more robust method of determining the state of AFS: Iterate over the mounted devices to search for a mounted AFS filesystem. Reviewed-on: https://gerrit.openafs.org/14587 Reviewed-by: Cheyenne Wills Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 4731c80609217e2594e8503a0b80f2e53ec27a6d) Change-Id: I36683cc9763e77aa4960f9eb3e4ee297d8217efa Reviewed-on: https://gerrit.openafs.org/16072 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit cb46c15c392cb1ac0c9b838534dd7d73d58377a7 Author: Marcio Barbosa Date: Sat Jun 11 16:58:20 2022 -0700 DARWIN: Convert prefpane start/stop to privhelper Convert the logic to "start/stop OpenAFS" in the prefpane to use privhelper, so it can work with macOS 10.8+. Specifically, define these new privhelper tasks: - afsd_start - afsd_stop And convert our start/stop-related code in the prefpane to use them. Reviewed-on: https://gerrit.openafs.org/15958 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 56915e96d89e87e24feda33b22c7c807c72931b0) Change-Id: Iaf0210e645865ec611e891e7952a67ecb0f13e51 Reviewed-on: https://gerrit.openafs.org/16071 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 756c0c891914b1acbf6658680ad56a5a8195f403 Author: Marcio Barbosa Date: Sat Nov 23 03:31:54 2024 -0800 DARWIN: Convert prefpane startup ops to privhelper Convert the logic for the "start at login" option in the prefpane to use privhelper, so it can work with macOS 10.8+. Specifically, define these new privhelper tasks: - startup_enable - startup_disable - startup_check And convert our startup-related logic in the prefpane to use them. Get rid of our now-unused method executeTaskWithAuth() and related methods. Reviewed-on: https://gerrit.openafs.org/15957 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 89eafda9608a18883e788a62051db4293a39346d) Change-Id: I5f92242369db4192f7aee8fcdaea8d0369f9f55c Reviewed-on: https://gerrit.openafs.org/16070 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit cb12f107f92e681d25f53c716fcb148c50762aff Author: Marcio Barbosa Date: Sat Nov 23 06:46:52 2024 -0800 DARWIN: Add 'privhelper' tool for PrefPane The prefpane for macOS runs as the logged-in user, but needs root access for some operations: starting/stopping the client, editing various configuration files like CellServDB, etc. We currently use functions like AuthorizationExecuteWithPrivileges() to run commands with root privileges directly, but this approach no longer works as of macOS 10.8 (Mountain Lion); the relevant functions have been removed. Instead, a new approach exists as of macOS 10.6 (Snow Leopard). The prefpane application itself cannot gain root privileges, but we can provide another daemon process that runs as root, and the PrefPane sends requests to that process to perform the privileged operations we need. In this commit, create a separate helper program called PrivilegedHelper (privhelper for short) that serves this purpose. Define the executePrivTask() method in TaskUtil to handle communicating with privhelper over XPC. This commit does not define any of the tasks that privhelper will actually perform; this just implements privhelper itself. Later commits will add and use various privileged tasks in privhelper. In order for privhelper to be able to run as root, both privhelper and the prefpane itself must be code signed and the relevant apple team id must be specified in their Info.plist when they are built, as well as inside privhelper.c. Currently, we have no way of specifying code signatures info during the build, since all code signing is done when generating packages (via pkgbuild.sh) after binaries are built. For now, just put a commented-out section in src/platform/DARWIN/AFSPreference/Info.plist and src/platform/DARWIN/PrivilegedHelper/privhelper-info.plist and a placeholder in src/platform/DARWIN/PrivilegedHelper/privhelper.c to show how to add this information. The package builder must add their own team id to these before privhelper can work properly. The privhelper tool checks that the calling user has authorization to run commands as root (via AuthorizationCopyRights()), and that the calling process is either our AFSBackgrounder menu bar or the prefpane. We use xpc_connection_set_peer_code_signing_requirement() for this where available, but fallback to using SecCodeCheckValidity() with SecCodeCreateWithXPCMessage() or xpc_dictionary_get_audit_token()/SecCodeCopyGuestWithAttributes() if needed. Reviewed-on: https://gerrit.openafs.org/15956 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 120871f03f38538cbaf3b25d6b2bca08d0f4652d) Change-Id: I9e107cf22c1ad10af1386ec8c706bde2b4eeb08e Reviewed-on: https://gerrit.openafs.org/16069 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Marcio Brito Barbosa Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 3c0a326a4044740da5cd726a4c9c16187ad62b1d Author: Andrew Deason Date: Mon Aug 20 14:53:35 2018 -0500 Log binding ip address and port during startup Many daemons currently have the ability to bind to a specific ip address using the -rxbind parameter. The behavior can be a little unintuitive, however, since we only bind to the ip address we find via NetInfo/NetRestrict processing, and only if we end up with a single ip address. Since that processing involves examining the set of ip addresses available, this can have confusing results if, for instance, a daemon starts up while an administrator is changing the local ip configuration. If a daemon binds to a different ip address than the administrator expects, this can be very confusing, especially since for most daemons we don't log our bound ip anywhere. To help alleviate this, change the startup code for all of our daemons to log what ip we are trying to bind to (or "0.0.0.0" if none), along with our local port. Reviewed-on: https://gerrit.openafs.org/13272 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 02dede5d40a55421ab4f093c1c90b8f785a40ec1) Change-Id: I2d54e17ae7c69bd4c842422f53434519d1f332e5 Reviewed-on: https://gerrit.openafs.org/16095 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 4f1e057ea304036cc2d301bb3b8853bd759b6226 Author: Andrew Deason Date: Tue Aug 7 11:17:43 2018 -0500 Call rx_InitHost once during daemon startup Currently, a few daemons calls rx_InitHost in different places, and under different conditions. For example, vlserver calls rx_InitHost only when we -rxbind to a specific ip address, and then also makes an additional rx_Init call. Other daemons always call rx_InitHost, or just call rx_InitHost sometimes and don't make an extra rx_Init call. To try to make the various daemons behave a little more consistently, change the startup code to always call rx_InitHost, and to only call it once. Note that rx_InitHost is the same as calling rx_Init with INADDR_ANY as the ip address, and calling rx_Init* after a previous rx_Init* call is effectively a no-op. Reviewed-on: https://gerrit.openafs.org/13271 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 78ed034603781a979687a45c08eb8b13e515e8bf) Change-Id: I8dc6a2d7e6561b96b8389bb8f131a4a17995bf94 Reviewed-on: https://gerrit.openafs.org/16094 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit ef3da57b8c3bfdf4bf3dc0dcd9458ace0ddc2709 Author: Cheyenne Wills Date: Fri Apr 25 11:43:01 2025 -0600 ubik: Use typedef for ubik_call function parameter One of ubik_Call()/ubik_CallIter()/ubik_Call_SingleServer() parameters is a function pointer (aproc). A function signature for this parameter is not specified which leads to a strict-prototype warning which has been addressed by suppressing the check by adding the -Wno-strict-prototypes compiler flag for the files that need it. A new C standard (C23) is coming out and newer versions of C compilers (e.g. gcc 15) are using the new standard (or an extension of that standard) as their default. The C23 standard has removed the ability to declare functions with unspecified parameters; now any function that is declared as: int foo(); is treated as: int foo(void); Building with gcc-15 results in the following types of compile time errors (even when -Wno-strict-prototypes is used): ubikclient.c: In function ‘CallIter’: ubikclient.c:391:10: error: too many arguments to function ‘aproc’; expected 0, have 17 391 | (*aproc) (tc, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, | ~^~~~~~~ ~~ ubikclient.c: In function ‘ubik_Call’: ubikclient.c:577:18: error: too many arguments to function ‘aproc’; expected 0, have 17 577 | (*aproc) (tc, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, | ~^~~~~~~ ~~ To avoid this error, we must declare the parameters for the 'aproc' function pointer. Define a typedef, ubik_call_func, that can be used to define the data type for the function parameter and can also be used as a cast on the function parameter when calling ubik_Call() ubik_CallIter() or ubik_Call_SingleServer(). Update the function prototypes and definitions for ubik_Call() ubik_CallIter() and ubik_Call_SingleServer(), and add casts where needed. Define "UBIK_LEGACY_CALLITER" in ubik_db_if.c, so it can also use the ubik_call_func typedef for its ubik_Call_SingleServer variant. Remove the -Wno-strict-prototypes for the files that were updated. The CFLAGS_NOSTRICT_PROTOTYPES autoconf var is now unused, so remove it. Some minor whitespace/indentation cleanup. Note: This problem occurred on Fedora 42 which comes with gcc 15. Reviewed-on: https://gerrit.openafs.org/16370 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills Reviewed-by: Andrew Deason (cherry picked from commit eddd5a060e9ed5acf10ee23359d54e22d4681592) Conflicts: doc/process/compiler-warnings.md - updated CODING instead src/cf/osconf.m4 - Due to differences with master Change-Id: I75c40c3cc443a3b7c9039a248abed1a864746aae Reviewed-on: https://gerrit.openafs.org/16380 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit a5c933d058c15da2daa4943213f305659244f6e7 Author: Andrew Deason Date: Fri Dec 9 15:36:51 2022 -0600 Inhibit -Wstrict-prototypes warnings via CFLAGS Currently, we inhibit various -Wstrict-prototypes warnings via "#pragma GCC diagnostic warning". Some older compilers (like gcc 4.1 on RHEL5) don't understand the pragma, but still need the warning inhibited in order to build with --enable-checking. So just inhibit this warning via command-line CFLAGS instead of using #pragma directives. Reviewed-on: https://gerrit.openafs.org/15219 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie (cherry picked from commit 2a9550a830f2371db6c160eece532f4e87ea6cc0) Change-Id: I562b6467d02e06a3ee197a3d47d0c223a21d99bd Reviewed-on: https://gerrit.openafs.org/16395 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason commit 1aa5e50da42d14bae8093ada7a0ddc57599b376b Author: Cheyenne Wills Date: Thu Apr 24 13:21:12 2025 -0600 lwp: Replace the typedefed bool datatype with int A new C standard (C23) is coming out and newer versions of C compilers (e.g. gcc 15) are using the new standard (or an extension of that standard) as their default. The C23 standard has added a native C data type `bool`. This causes a build error when code tries to use a typedef to define a `bool` data type: iomgr.c:50:23: error: ‘bool’ cannot be defined via ‘typedef’ 50 | typedef unsigned char bool; | ^~~~ iomgr.c:50:23: note: ‘bool’ is a keyword with ‘-std=c23’ onwards iomgr.c:50:1: warning: useless type name in empty declaration 50 | typedef unsigned char bool; There are just a few locations where `bool` is used as a data type. Replace the use of the `bool` data type with an `int`. Note: This problem occurred on Fedora 42 which comes with gcc 15. Reviewed-on: https://gerrit.openafs.org/16369 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit bf64c84058493ee6fe2b1b2fb27b73787aaed318) Change-Id: Ib959f8c72189df0a797b905388bdd33627ca1ca1 Reviewed-on: https://gerrit.openafs.org/16379 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason commit 2de59286f74d84d9c7030cdacbd0995dc6894584 Author: Cheyenne Wills Date: Thu Apr 17 17:07:16 2025 -0600 afs: Set 0555 perms on /afs dynroot directory When -dynroot is given to afsd, our synthetic /afs directory is created with permission mode bits of 0755, and cannot be changed by chmod() or anything else. On Red Hat Enterprise Linux 9, the 'filesystem' RPM (at least for version 3.16-5) includes an entry for the /afs directory, to make sure the empty mountpoint exists, which specifies perm mode bits of 0555: %attr(0555, root,root) /afs If that 'filesystem' RPM is installed/updated while /afs is mounted, the process will fail, since it tries to set the permissions of /afs to 0555: Upgrading : filesystem-3.16-5.el9.x86_64 1/2 Error unpacking rpm package filesystem-3.16-5.el9.x86_64 Verifying : filesystem-3.16-5.el9.x86_64 1/2 Verifying : filesystem-3.16-2.el9.x86_64 2/2 Installed products updated. Failed: filesystem-3.16-2.el9.x86_64 filesystem-3.16-5.el9.x86_64 Error: Transaction failed There is no need for the mode bits to specifically be 0755, so to avoid this issue, just change the permissions for -dynroot /afs to be 0555 instead. This causes RPM to see that the permissions on the dir are already what it expects, so it doesn't try to change the permissions. Add some text to the -dynroot option in the afsd(8) manpage, documenting what the mode bits are for the directory. This commit does not add any way to change what the mode bits are for /afs when -dynroot is enabled, since there aren't any reasons to need to set them besides the situation with the 'filesystem' RPM. If this becomes an issue, future commits can add a way to change the mode bits. Additional background for the issue with the 'filesystem' RPM is described in the Red Hat ticket: https://issues.redhat.com/browse/RHEL-83649 [adeason@sinenomine.net: commit message phrasing, afsd manpage update.] Reviewed-on: https://gerrit.openafs.org/16368 Tested-by: BuildBot Reviewed-by: Michael Meffie Tested-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 28bb52f5f3f9fbd3ad3c6a128b82b96a050d7c55) Change-Id: Ie00fc21adc3779448da83665cb3743cdeab99159 Reviewed-on: https://gerrit.openafs.org/16378 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason commit 75ac27459b8d4eb0d8992c03d5697344c77fbd97 Author: Andrew Deason Date: Fri Sep 29 16:57:22 2023 -0500 fs: Report errors more consistently from GetCell() Errors from GetCell() are reported a bit oddly in its three callers: - In WhichCellCmd() (and GetFidCmd() before change Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we print an odd "no such cell" error for ENOENT, and a more normal message for all other errors. - In BadName() (and GetFidCmd() after change Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we don't print an error at all, sometimes making it not obvious that an error has occurred. (BadName() is called from 'fs cleanacl'.) The ENOENT message can be confusing to users, since ENOENT is the error code we get if the given path doesn't exist. This is easy to see with 'fs whichcell': $ fs whichcell notexist fs: no such cell as 'notexist' The VIOC_FILE_CELL_NAME pioctl also never returns ENOENT itself, so this only happens if the given file doesn't exist. This behavior goes back to OpenAFS 1.0. To improve this, change GetCell() to report errors itself. So now errors are reported from it consistently, and are printed for all callers. For example: $ fs whichcell notexist fs: Failed to get cell for 'notexist' fs: File 'notexist' doesn't exist The message is a little redundant, but this lets us use the existing error reporting from Die() while still providing context for what is failing, since it may not be obvious for 'fs cleanacl' or 'fs getfid'. Reviewed-on: https://gerrit.openafs.org/15586 Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit 4baeaf1d9fd630653e047f043feb3a2eb6d7d3c2) Change-Id: Ia1f222e0d897bd3543b0fe41124dac91154637b2 Reviewed-on: https://gerrit.openafs.org/16081 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 0e531f08bf55eddfafd6a45f783e25d54cd1ab67 Author: Andrew Deason Date: Fri Sep 29 16:46:14 2023 -0500 fs: Still print fid for 'getfid' if GetCell fails Currently, 'fs getfid' fails if we cannot get the cell for the given file via GetCell(). This GetCell call was added in commit d390df097c (fs getfid output changed for consistency with Windows implementation) to be more similar to the WINNT 'fs getfid', but the WINNT 'fs getfid' still prints the fid if getting the cell fails (and has since it was introduced in commit 5520747790 (windows-fs-getfid-20090511)). GetCell() shouldn't normally fail if getting the fid succeeded, but in case it does, don't prevent us from printing the fid. Change 'fs getfid' to just say the cell is "unknown-cell" and keep going. Reviewed-on: https://gerrit.openafs.org/15585 Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit 93036c852d957ae3587e691920a61e1c026cea1d) Change-Id: Ic81715a3a1ab9160b5b96f19b78211cac00bc748 Reviewed-on: https://gerrit.openafs.org/16080 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 406cfb4e0945099caa38867c183cc4356bf28b30 Author: Andrew Deason Date: Fri Sep 29 16:16:49 2023 -0500 fs: Get parent dir cell for 'fs getfid -literal' After we get the fid for the requested path, 'fs getfid' then gets the cell for the path: GetCell(ti->data, cell); But ti->data is the full path requested, whether -literal was given or not. If the given path ends with a broken symlink/mountpoint or nonexistent fid, we've already gotten the fid (if -literal was given) but we'll still exit with an (often confusing) error: $ fs getfid symlink.broken -literal fs: no such cell as 'symlink.broken' In addition, if we use 'fs getfid -literal' to get the fid of a cross-cell mountpoint object, we'll get the wrong cell. We'll report the cell of the mountpoint's target, instead of the cell of the reported fid: $ fs getfid /afs/example.com -literal File /afs/example.com (1.16777244.1) located in cell example.com To fix these, pass 'parent_dir' to GetCell() when -literal is given. To do this, we need to not free parent_dir until later, so reorganize the 'parent_dir' and 'last_component' vars to be freed at the end of the loop, and change the 'continue' code paths to goto the end of the loop instead. With this, the cell is now reported properly for these cases: $ fs getfid symlink.broken -literal File symlink.broken (536871063.22.865) located in cell example.com $ fs getfid /afs/example.com -literal File /afs/example.com (1.16777244.1) located in cell dynroot Reviewed-on: https://gerrit.openafs.org/15584 Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: BuildBot (cherry picked from commit cad39264b6651b6f2824c46ea73d77764235f3d9) Change-Id: Ib1f1d3a821ec6b14b91d5ac7d777fbc3c9e6cc68 Reviewed-on: https://gerrit.openafs.org/16079 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit f3ef73920004c97723e0596bc1c03312d99c50cb Author: Andrew Deason Date: Thu Apr 4 13:20:05 2024 -0500 RedHat: Retry umount /afs on systemd shutdown When systemd tries to stop openafs-client.service during system shutdown, our 'umount /afs' will fail if someone else is accessing /afs. The openafs-client.service unit is then marked as deactivated (and failed), and the shutdown sequence proceeds. After all services have been stopped, systemd-shutdown tries to kill all remaining processes with SIGTERM and then SIGKILL, waiting DefaultTimeoutStopSec seconds (default: 90) for them to die. If there are unkillable processes running (for example, afsd), this results in at least a 3-minute delay. It's hard to make sure there are no processes accessing /afs during the shutdown sequence, since that could include processes outside of defined systemd units. So some processes may be shutting down in parallel with openafs-client.service, and so it's a race whether there are /afs-using processes when we try to umount /afs. To avoid the most common cases of this, retry our umount during openafs-client's ExecStop for $UMOUNT_TIMEOUT seconds (default: 30), to give other /afs-using processes a chance to go away. Only do this if the system is shutting down (according to 'systemctl is-system-running'), so users don't see a long delay running 'systemctl stop openafs-client' during normal system operation. Written in collaboration with cwills@sinenomine.net. Reviewed-on: https://gerrit.openafs.org/15633 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills (cherry picked from commit bd2a7530ad3649141a6fffd028aa3e95a6ea2f75) Change-Id: Ida56b8a7512f0fd01470321e973bb67b1a092e44 Reviewed-on: https://gerrit.openafs.org/16107 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 67c4148d0ad237434e03b8830707764889a20771 Author: Andrew Deason Date: Mon Feb 12 15:41:36 2024 -0600 RedHat: Make client unit start/stop more robust Our openafs-client.service systemd unit currently has some unfortunate behaviors: - If someone runs 'systemctl stop openafs-client' and someone is using /afs, our umount will fail, and systemd will consider the openafs-client unit failed and deactivated. Trying to stop the unit again won't do anything, and trying to start the unit will fail because of our 'fs sysname' check. The client can then only be stopped by manually running umount/rmmod. - If our kernel module is already initialized (because afsd failed during startup, or someone 'umount'd /afs without unloading the kernel module), running 'systemctl start openafs-client' will try to start afsd with an already-initialized kernel module, which will either fail or cause errors/panics. To improve this situation, change our startup sequence to unload the kernel module if it's already loaded (and then load it again right afterwards). This should guarantee that we won't use an already-initialized kernel module when we run afsd. This also means we will fail during startup if the kernel module cannot be unloaded for any reason (for example, if the client is already running but the 'fs sysname' check somehow didn't detect this). Also change our 'fs sysname' check to return success if the client is already running, instead of failure. This means that after a failed 'stop', the user can run 'start' and then 'stop' again to try and stop the client. Just running 'stop' again still won't do anything, which is not ideal, but that's just how systemd works. Move our 'afsd -shutdown' and 'rmmod' steps into ExecStopPost, so they may get run in some additional corner cases for a partially-initialized service. Add --verbose to a few commands, to make it a little clearer what's happening in what order in systemd logs. If we cannot unload the openafs kernel module when stopping (because, for example, we couldn't 'umount /afs' because it was in use), log some information about how the user can actually get the client stopped. Reviewed-on: https://gerrit.openafs.org/15647 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit f951a9bf9b26e22475715b3ba82b00a30d379272) Change-Id: I55197bfb8a67b5458ea88468c9a8f25903e388b6 Reviewed-on: https://gerrit.openafs.org/16106 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 012ccd7f6d10eab3747ca0a61ee556ba54b0d781 Author: Cheyenne Wills Date: Tue Jan 30 09:05:14 2024 -0700 RedHat: Introduce client systemd helper script Move the logic in our Exec* commands in our openafs-client.service unit file into a helper script: openafs-client-systemd-helper.sh. This makes it easier to control our increasingly-complex startup/shutdown checks (and makes them easier to read), and reduces the clutter in our openafs-client.service unit file. This commit does not intentionally change any of our startup/shutdown behavior yet; this just moves the existing logic into a script. Update openafs.spec.in to install the helper script. Reviewed-on: https://gerrit.openafs.org/15634 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 0abbab24d27ecdd2bebecfb6ff8e471eda5b6cc2) Change-Id: Ic12498338ea668ead0700ab00e8065a3c00434b2 Reviewed-on: https://gerrit.openafs.org/16105 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 533f4241cc1617e8081236609399e2e41a8048a6 Author: Cheyenne Wills Date: Mon Jan 22 15:06:56 2024 -0700 RedHat: Use KillMode=process for systemd client Our openafs-client.service systemd unit file contains a deprecated option, KillMode=none. Using this option results in the following message with systemd version 246 or later: /lib/systemd/system/openafs-client.service:22: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. Without this option, if someone runs 'systemctl stop openafs-client' and the client fails to shutdown (e.g., because files are accessing /afs), systemd will try to kill all of our afsd processes. Our afsd processes usually either cannot be killed, or will cause unstable behavior if they are killed (because e.g. AFSDB requests cannot be fulfilled). If systemd cannot kill all of our afsd processes, it will wait for a timeout before reporting an error. By default, it waits 90 seconds before sending SIGTERMs, and another 90 seconds before sending SIGKILLs. This means that by default, if someone is using /afs, 'systemctl stop openafs-client' will hang for 3 minutes (!), even though we know immediately that we cannot stop the client. One way to avoid this is using KillMode=none, which skips killing our processes and waiting for any timeouts. To avoid using a deprecated option, switch to using KillMode=process. With KillMode=process, after a failed 'stop', systemd will only try to kill the 'main' pid run by ExecStart. The 'main' pid is detected by systemd either automatically by some heuristic (with GuessMainPID=yes), or by a pid file (when PIDFile= is set). If we disable GuessMainPID and don't set PIDFile, systemd will not try to terminate any of our processes on shutdown. systemd will still try to kill our other remaining processes using SIGKILL, but we can disable that with SendSIGKILL=no. To be safe, also specify KillSignal=SIGCONT to make sure systemd doesn't actually forcibly kill any of our afsd processes. None of this matters during a successful client shutdown, since then all of our afsd processes go away after a successful unmount, and there's nothing to cleanup. Our behavior during a failed 'stop' is still not ideal. After a failed 'stop', systemd will flag the service as "failed (Result: exit-code)". This is similar to a service that is stopped successfully (deactivated), and running 'systemctl stop' on it again does nothing. Running 'systemctl start openafs-client' will try to start the service again, but this will fail because of the ExecStartPre check that runs 'fs sysname', and the service will still be considered failed/deactivated. The only way to fix the situation is for an administrator to run the shutdown sequence manually, unmounting /afs and removing the kernel module themselves, and then starting the client again. That behavior is unfortunate, but seems difficult or impossible to avoid with a single systemd service. Reviewed-on: https://gerrit.openafs.org/15613 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit df3b8129ce9ce3c211e3cfa2033ac72e008f3895) Change-Id: Ifbdcad1e39ce77a63121972d4561424e243ab4d1 Reviewed-on: https://gerrit.openafs.org/16104 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 9ee4b7e44a1c544105b60f5812dd2de6aa89d50d Author: Cheyenne Wills Date: Tue Feb 25 20:09:12 2025 -0700 afs: Init structures via designated initializers When the Linux kernel is configured with CONFIG_RANDSTRUCT=y, the following error occurs when building the openafs kernel module: src/libafs/MODLOAD-6.12.0-SP/rand-timer-kernel.c:46:5: error: positional initialization of field in ‘struct’ declared with ‘designated_init’ attribute [-Werror=designated-init] 46 | timer_seed, | ^~~~~~~~~~ When the Linux kernel is configured with CONFIG_RANDSTRUCT=y, the Linux build uses a Linux kernel-specific GCC plugin (scripts/gcc-plugins/randomize_layout_plugin.c) that analyzes structures and will add the designated_init attribute to any structure that is determined to be a "pure operations struct" (i.e. contains only function pointers or nested pure ops structs/unions). This is done so the plugin can then randomize the layout. This causes some of our structures to be flagged with the designated_init attribute, which triggers -Werror=designated-init when we don't use designated initializers. Within the Linux specific directory, src/afs/LINUX, the code already uses designated initializers, however some of the shared code within src/afs or that is included in the build for the kernel module still use positional initialization when initializing pure operations structures. Update the shared code that is used when building the Linux kernel module to use designated initializers via the AFS_STRUCT_INIT macro. Use a consistent alignment, and add trailing comma on the last element, change 0 to NULL where applicable. There are no functional changes within this commit. Note: For consistency, all the initializers for rx_securityOps are being updated even though not all of the files are part of the Linux kernel module (e.g. rxkad_server.c). Note: This error was discovered by an automated process that is used by the Gentoo organization to test building packages with a hardened Linux kernel. Reviewed-on: https://gerrit.openafs.org/16290 Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit e94c183faef42e5ffe85c157ede008f2817bdefd) [cwills@sinenomine.net changes to rxgk not applicable to 1.8.x] Change-Id: I56ebb7d34718eef6c5bfbba98e3fb4e350a5129f Reviewed-on: https://gerrit.openafs.org/16383 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 4d224c7df7b5e0bf0e17400ad6ef6a05695a60dd Author: Cheyenne Wills Date: Wed Feb 26 08:03:18 2025 -0700 Convert HAVE_STRUCT_LABEL_SUPPORT to AFS_STRUCT_INIT The OpenAFS coding style allows the use of designated initializers for structs, however not all supported platforms have compilers that support it. The preprocessor define HAVE_STRUCT_LABEL_SUPPORT has been available for use so structure initialization can be set up to support compilers that do have designated initializers support. The typical use is: struct foo x = { #ifndef HAVE_STRUCT_LABEL_SUPPORT val1, val2, ... #else .mem1 = val1, .mem2 = val2, ... #endif }; This results in extra lines of code where errors can easily be introduced. Create a macro, AFS_STRUCT_INIT, that uses designated initializers when available, so the above example would be: struct foo x = { AFS_STRUCT_INIT(.mem1, val1), AFS_STRUCT_INIT(.mem2, val2), ... }; Convert the initialization of structures that are using the HAVE_STRUCT_LABEL_SUPPORT define to use AFS_STRUCT_INIT. Note, there is still a requirement that the order of initializers match the order of the elements within the structure, but it should be easier to verify that the initializers are in the proper order. Use a consistent alignment, and add trailing comma on the last element. There are no functional changes made by this commit. Reviewed-on: https://gerrit.openafs.org/16289 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit 7c28b99490b75475ed9130526c536ae0e354e064) Change-Id: I8faa4b497f2962bdd0a4ecb559e8b9288fd5c796 Reviewed-on: https://gerrit.openafs.org/16382 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 5f85032cdb7f0148dc6165773acb6d6ffe4b6914 Author: Cheyenne Wills Date: Fri Feb 7 11:10:27 2025 -0700 Linux-6.14: Handle dops.d_revalidate with parent The Linux 6.14 commit: '5be1fa8abd7b0 Pass parent directory inode and expected name to ->d_revalidate()' added 2 parameters to the dentry_operations.d_revalidate method. These new parameters are being provided as a convenience so a filesystem's d_revalidate function can avoid some boilerplate code for obtaining the dentry's ->d_parent and ->d_name. The caller ensures that these two values are stable. Add a new autoconf test to determine if dentry_operations.d_revalidate has the new parameters. Update afs_linux_dentry_revalidate() to accept the new parameters. Reviewed-on: https://gerrit.openafs.org/16253 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit 0306f3fdac736e15620f5802bdce510d25bb2450) Change-Id: I640c338de22201da88327a7bc0d6bdb2bccd23bc Reviewed-on: https://gerrit.openafs.org/16277 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 02603ec7bb2b6dadd9fc6f30f1d180732673f3d9 Author: Cheyenne Wills Date: Fri Feb 14 15:18:52 2025 -0700 LINUX: Refactor afs_linux_dentry_revalidate() The signature for Linux's dentry_operations.d_revalidate method has undergone several changes, leading to increased use of #if directives in afs_linux_dentry_revalidate(). To make the code more maintainable for future changes involving the parent inode and the dentry's name, split out most of our logic in afs_linux_dentry_revalidate() into a new function, dentry_revalidate_common(). Keep the logic for getting the parent and checking for LOOKUP_RCU in the caller, afs_linux_dentry_revalidate(). Written in collaboration with adeason@sinenomine.net. Reviewed-on: https://gerrit.openafs.org/16258 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills Reviewed-by: Andrew Deason (cherry picked from commit 4702930f8dd87a6cad1d59ef8c127003fded1f31) Change-Id: Iae781913ec933e79ca47cdf043e729e50c1b2a6d Reviewed-on: https://gerrit.openafs.org/16276 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit e4ca30af436776c48005c71997930cdf7bf61abd Author: Andrew Deason Date: Tue Oct 25 13:25:37 2022 -0500 FBSD: Fallback to $CC for assembler FreeBSD 13 no longer ships with a standalone assembler (e.g. /usr/bin/as). But clang can be used as an assembler, so just set AS to $CC if we don't find an assembler. Reviewed-on: https://gerrit.openafs.org/15161 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 1435b686a953c3f22d180ad239ec85dda3658273) Change-Id: Id8840263dd553f12cc1ee4787e74fa7056a0a5e9 Reviewed-on: https://gerrit.openafs.org/16166 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit ff293c06967445ed57f1e35922f6c1c31169e600 Author: Cheyenne Wills Date: Wed Jan 15 13:40:23 2025 -0700 cf: Invoke AC_PROG_RANLIB with AC_REQUIRE With libtool 2.5.3, the libtool commit: "libtoolize: Fix conflicting warnings about AC_PROG_RANLIB" (3e6c628) added an AC_REQUIRE([AC_PROG_RANLIB]), which resulted in the following messages when running ./regen.sh Running autoconf configure.ac:16: warning: AC_REQUIRE: 'AC_PROG_RANLIB' was expanded before it was required configure.ac:16: https://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required src/cf/libtool.m4:1577: _LT_CMD_OLD_ARCHIVE is expanded from... src/cf/libtool.m4:153: _LT_SETUP is expanded from... src/cf/libtool.m4:62: LT_INIT is expanded from... src/cf/afs-libtool.m4:18: AFS_LT_INIT is expanded from... src/cf/osconf.m4:2: OPENAFS_OSCONF is expanded from... acinclude.m4:7: OPENAFS_CONFIGURE_COMMON is expanded from... configure.ac:16: the top level Running autoconf for configure-libafs configure-libafs.ac:12: warning: AC_REQUIRE: 'AC_PROG_RANLIB' was expanded before it was required configure-libafs.ac:12: https://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required src/cf/libtool.m4:1577: _LT_CMD_OLD_ARCHIVE is expanded from... src/cf/libtool.m4:153: _LT_SETUP is expanded from... src/cf/libtool.m4:62: LT_INIT is expanded from... src/cf/afs-libtool.m4:18: AFS_LT_INIT is expanded from... src/cf/osconf.m4:2: OPENAFS_OSCONF is expanded from... acinclude.m4:7: OPENAFS_CONFIGURE_COMMON is expanded from... configure-libafs.ac:12: the top level According to the autoconf documentation for AC_REQUIRE, if we expand a macro using AC_REQUIRE, we're always supposed to expand the macro using AC_REQUIRE, and never expand it normally. With libtool 2.5.3, LT_INIT expands AC_PROG_RANLIB via AC_REQUIRE, and so we must also use AC_REQUIRE for our AC_PROG_RANLIB calls. So, change all of our AC_PROG_RANLIB calls to use AC_REQUIRE. We currently call AC_PROG_RANLIB in both OPENAFS_CONFIGURE_COMMON and OPENAFS_OSCONF (called from OPENAFS_CONFIGURE_COMMON). We don't interact with RANLIB outside of OPENAFS_OSCONF, so just get rid of the duplicate AC_PROG_RANLIB call in OPENAFS_CONFIGURE_COMMON instead of converting it to AC_REQUIRE. Reviewed-on: https://gerrit.openafs.org/16090 Reviewed-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: Mark Vitale (cherry picked from commit b8ab76cca297d7ccbf15defd3f6a391c8a786db0) Change-Id: I038dfb62c92930c21edb08402aacd88c7fec20b2 Reviewed-on: https://gerrit.openafs.org/16131 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 3698acbf03ea096001921f44ec6bb6185bc3daef Author: Cheyenne Wills Date: Mon Feb 22 11:08:39 2021 -0700 autoconf: use AC_CHECK_TOOL for as and ld Some platforms use the GNU target triplet as a prefix to the toolchain utilities (e.g. x86_64-pc-linux-gnu-as) to allow the use of alternative toolchains, cross-compiling, etc. The Gentoo Linux distribution has a mode of building packages (-native-symlinks) where the toolchain utilities only exist as their prefixed names (e.g. 'as' does not exist, but 'x86_64_pc-linux-gnu-as' does). This results in configure failing to locate the tools when using AC_CHECK_PROGS. (Gentoo uses the --host and --build configure parameters to specify the prefix names for the tools). Replace AC_CHECK_PROGS with AC_CHECK_TOOL for the toolchain related commands 'as' and 'ld'. AC_CHECK_TOOL works like AC_CHECK_PROGS but it will also look for the program with a prefix (specified by using configure's --host parameter). Note: libtool.m4 runs AC_CHECK_TOOL for ar. Reviewed-on: https://gerrit.openafs.org/14544 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 268025f841f1a2bd16b802459a8b590939331bcd) Change-Id: I158ccd7f473b2257c35812de35749c09f97a490b Reviewed-on: https://gerrit.openafs.org/16130 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit efc5dc5a407955844e513c3f8ad7711ddfc92077 Author: Cheyenne Wills Date: Tue Jun 1 12:17:01 2021 -0600 cf: Fix typo in test for enable-shared/with-swig The commit cf: Disable swig if shared libraries are disabled (0e84b7405) contains a typo in a test: "x$enable_shared" != "yes". This causes configure to exit due to incorrectly testing --enable-shared. Update swig.m4 to correct the typo. Reviewed-on: https://gerrit.openafs.org/14628 Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit a73d337a55d4800b67b0ce3c60cb1d5f5fbc7519) Change-Id: I4467f8923df376400ac228c31e75f20f356cb81a Reviewed-on: https://gerrit.openafs.org/16101 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit 0eed823e2f942eb9d8426c434763b827cc7be6be Author: Cheyenne Wills Date: Mon Apr 26 16:17:39 2021 -0600 cf: Disable swig if shared libraries are disabled When building with the option --disable-shared and swig is also enabled (either explicitly, or autodetected) a build failure occurs when trying to link libuafs/PERLUAFS/ukernel.so Update the configure test for swig to disable the swig autodetection when --disable-shared was specified, as well as emitting a notice message stating that the swig autodetection has been disabled. If --with-swig=yes was specified along with --disable-shared, generate a configure error stating --with-swig is incompatible with --disable-shared. Reviewed-on: https://gerrit.openafs.org/14606 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0e84b740c75dc7befaa976cf09703b3439296131) Change-Id: I0a8ef6396827c6f53320f89d2b523903e39e0636 Reviewed-on: https://gerrit.openafs.org/16100 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk commit 8de21fd7614f43ba0a45d1ff25b2411102db2ac8 Author: Cheyenne Wills Date: Wed Apr 7 10:51:58 2021 -0600 cf: Run AFS_LT_INIT after setting CC Since libtool support was introduced for 1.8.x in commit 69f26ece (Add libtool support), we've run LT_INIT or AFS_LT_INIT early on in configure.ac. If CC isn't set, AFS_LT_INIT defaults to using gcc when it's available. On Solaris, we set CC and CFLAGS ourselves later (in osconf.m4) to use the Solaris Studio compiler, but this doesn't change the compiler that AFS_LT_INIT already chose. As a result, on Solaris if no value for CC is given during configure and gcc is available, some libtool commands will try to use gcc with CFLAGS intended for the Solaris Studio compiler, which will fail. /bin/sh ../../libtool --quiet --mode=link --tag=CC ... -mt ... gcc: error: unrecognized command line option '-mt'; did you mean '-t'? To fix this, move AFS_LT_INIT into osconf.m4 after our platform-specific macros have had a chance to set CC. Also move our checks for AR, AS, etc. to after AFS_LT_INIT, since AFS_LT_INIT sets those. Note. Without GCC installed on a Solaris system, libtool will find the Solaris Studio compiler (assuming that PATH is set up correctly) and the build will proceed successfully. Just installing the GCC package is sufficient to break the build. This commit fixes a regression from 1.6.x where having the GCC package installed on the system would not break the build. Reviewed-on: https://gerrit.openafs.org/14585 Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 0a58d21881d7e91deccb416e8d2c272e14b412dd) Change-Id: I6a961a3a5586c6c68ddfc90a758af16b3b45adb8 Reviewed-on: https://gerrit.openafs.org/16097 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit ef0b3fc53c69b54f1c941c942b0d8079f6bf8952 Author: Michael Meffie Date: Fri Sep 15 14:51:55 2023 -0400 fsint: Move RXAFS_StoreACL function declaration Commit 8f1eba056fd (CVE-2018-7168 RXAFS_StoreACL deprecate 134 introduce 164) added RXAFS opcode 164 as RXAFS_StoreACL. This change sensibly added the new opcode 164 between opcodes 163 (RXAFS_DFSSymlink) and 220 (RXAFS_FsCmd) in the afsint.xg file. Unfortunately, the rx rpc call statistics reported over the wire by RXSTATS_RetrieveProcessRPCStats() are given by function index (not opcode). The function index is determined by the function position in the xg file when rxgen generates the RPC stubs. This means following RXAFS RPCs stats are off-by-one in the returned stats block: RXAFS_FsCmd RXAFS_InlineBulkStatus RXAFS_GiveUpAllCallBacks RXAFS_GetCapabilities RXAFS_CallBackRxConnAddr RXAFS_GetStatistics64 Since the RPC call statistics are reported by function index and not opcode, rxstat clients (e.g., rxstat_get_process) report incorrect stats when there is a mismatch between the rxstat client and the fileserver. Move the declaration of RXAFS_StoreACL (164) to be after the last function in afsint.xg file, so the function indices generated by rxgen are not changed for existing functions and the next available function index is assigned to the new RXAFS_StoreACL (164) RPC. Note: The RXSTATS_RetrieveProcessRPCStats() RPC has a parameter to indicate the stat client version, which could be used in the future to support an improved interface, since relying on the function indices is not very robust. Reviewed-on: https://gerrit.openafs.org/15572 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit 23333c98badd32d5276c571f3106f2de46711b1a) Change-Id: I80b399052a2634c834aff009820c221c480f6f5b Reviewed-on: https://gerrit.openafs.org/16230 Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot commit d6179c2ef0126b9f56061bc9fd5a052c11c5b1d9 Author: Jeffrey Altman Date: Fri Feb 23 20:10:27 2018 -0500 CVE-2018-7168 RXAFS_StoreACL deprecate 134 introduce 164 There exist in the wild AFS3 clients that improperly construct access control lists which are then stored to directories via RXAFS_StoreACL (opcode 134). These clients add negative access control entries (if any) to the normal rights list. As there is no method by which a fileserver can determine that the ACL is improperly constructed, the only method to defend the storage of broken ACLs is to identify clients that are known to properly construct ACLs by introducing a new RXAFS_StoreACL opcode (164). This change: * Renames RXAFS opcode 134 to RXAFS_OldStoreACL * Introduces RXAFS opcode 164 as RXAFS_StoreACL * Implements SRXAFS_OldStoreACL and SRXAFS_StoreACL in the fileserver via a common_StoreACL() function that accepts the executed opcode as input. * To avoid breaking changes in stable release branches, SRXAFS_OldStoreACL will still be allowed by default, with an option to cause it to be failed by default with error EPERM/UAEPERM. A follow-up commit will cause SRXAFS_OldStoreACL to fail by default on the master branch. * When opcode 134 is called, the a FileLog entry will be generated at log level 0 instead of 1 and the entry will contain the string "CVE-2018-7168". * Modifies the format of the ACL logged to the FileLog and the audit stream. Previously the AFSOpaque format was used directly. The problem with this format is that it uses newlines as the ACE separator. Since the FileLog and file audit log is intended to be one line per log entry, the newlines break the file formats. This change replaces the newlines with spaces for display purposes unless the process is unable to allocate the additional memory. * Introduces a new fileserver command line switch -cve-2018-7168-enforce which when specified causes SRXAFS_OldStoreACL RPCs to be failed. [kaduk@mit.edu: switch en/disable-by-default behavior and fix argument parsing] FIXES: 134485 Reviewed-on: https://gerrit.openafs.org/12942 Reviewed-by: Jeffrey Altman Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 8f1eba056fd2d2792a7d2b61d5dbcdd799bc173d) Conflicts: src/viced/afsfileprocs.c [cwills@sinenomine.net] - On master, this commit was applied before the 2024 SA related commits. On 1.8.x, the 2024 SA commits are applied before this commit. -- Ensured that the changes made with the 2024 SA commits were not regressed. OPENAFS-SA-2024-002 Change-Id: I19106cd8815c08d60528f7f41978f3c691e9efd2 Reviewed-on: https://gerrit.openafs.org/16228 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 489d54469e343d020e08137b871ad7dca3754ce0 Author: Mark Vitale Date: Fri Jun 19 18:10:30 2020 -0400 viced: Set HashTable size at startup Currently, our HashTable for FileEntry structs is a fixed size (FEHASH_SIZE, 512). If we have a large number of callbacks, this can lead to very long hash chains, which can cause the fileserver to consume high amounts of CPU when finding, deleting, or especially adding new callbacks. This is especially bad since callbacks are managed under the global H_LOCK. To improve this, use our configured callback limit (-cb) to build an appropriately-sized HashTable at initialization, instead of using a hard-coded size. We compute this by dividing the -cb value by the desired hash chain length (FE_CHAIN_TARGET, 16), then rounding up to the nearest power of 2 at least as big as the old FEHASH_SIZE, 512. For DAFS, a copy of our HashTable is included in the fsstate.dat file on disk, so changing our hashtable size potentially changes the data in fsstate.dat. However, we currently do not read in the hashtable data from fsstate.dat, since it's not very useful; we only write it out in case other utilities or older fileservers need it. Older fileservers, however, will not read an fsstate.dat with a hashtable that does not have exactly FEHASH_SIZE. So if we have a differently-sized hash table, we're breaking compatibility with those fileservers anyway, so don't write out our hashtable data at all. This commit also changes the format of the callback.dump file, since it did not allow for a variable-length hashtable. We create a new MAGICV3 magic to define the new format, and add some logic to the 'cbd' utility to understand it. We still write out our hashtable to this file since it's for debugging, and the hashtable data may be useful in that context. Move FEHash to callback.c, since it now relies on the callback.c-only FEhashsize, and move FEHASH_SIZE_OLD along with it. [adeason@sinenomine.net: Don't write out non-old-sized hashtable. Move FEHash &co to callback.c. Various other minor edits.] Reviewed-on: https://gerrit.openafs.org/14731 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 2b9ba03ef77b23343b7be3b78435cad70c101637) Change-Id: I4a6a52cd8f90cd868662eccc37c2e41335841baa Reviewed-on: https://gerrit.openafs.org/16023 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit cb3f7bf81bdaa888b38d406ae0dcb364dd65a2b3 Author: Mark Vitale Date: Wed Apr 7 22:50:13 2021 -0400 DARWIN: Use -Werror=objc-method-access for objc The default Xcode compiler options are insufficient to fail the build if a method is not found. For example, a typo in the name of method 'componentsJoinedByString' results in the following build warning: /TaskUtil.m:70:62: warning: instance method '-componentsJoinedBySting:' not found (return type defaults to 'id') [-Wobjc-method-access] NSLog(@"Task failed: %@ %@ status:%d.", taskName, [args componentsJoinedBySting:@", "], status); Because this is only flagged as a warning, the build completes successfully. When this code runs, the AFSBackgrounder merely logs a runtime exception every time it passes through the erroneous code. This is a silent failure, unless you happen to know how to check for AFSBackgrounder log messages: $ log show --predicate 'process=="AFSBackgrounder"' Add compiler flag '-Werror=objc-method-access' to all of our xcode-built project files to treat this case as an error instead of a warning, so the build will fail. [adeason@sinenomine.net: Update all xcode project files.] Reviewed-on: https://gerrit.openafs.org/14586 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason (cherry picked from commit 13ef51154413fde3662d90d125eed1c50bb7af40) Change-Id: I70618e15201a3b55e3f220f70285af264e3a0fbc Reviewed-on: https://gerrit.openafs.org/16068 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 6f8c5093a4f82b627277f1291071667bef53f0d3 Author: Marcio Barbosa Date: Thu Nov 21 06:05:12 2024 -0800 DARWIN: Use NSUInteger for indexGreaterThanIndex return value The indexGreaterThanIndex function returns the closest index from the index set that is greater than a specified index. This function is typically used in a loop to iterate through a list of items until it returns NSNotFound, indicating the end of the list. In AFSCommanderPref.m, the following pattern is being used: int index = 0; do { ... } while((index = [... indexGreaterThanIndex:index]) != NSNotFound); The issue arises because indexGreaterThanIndex returns an NSUInteger, while the loop uses an int for index. If NSNotFound is cast to an int, it becomes -1, causing the loop to never terminate and leading to a crash. To fix this problem, change the type of index from int to NSUInteger to ensure proper comparison and termination of the loop when NSNotFound is returned. Reviewed-on: https://gerrit.openafs.org/15961 Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit d76df7cb24a7d5c12dcbe2a60cf34d1a6f158c76) Change-Id: I270bdf5fefbb32062e56e2e6f3908669738ef819 Reviewed-on: https://gerrit.openafs.org/16067 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit df76aa14e71d26d5d2e43e41d9de56a7fa5cfcf7 Author: Marcio Barbosa Date: Mon Jul 22 02:25:02 2024 -0700 DARWIN: Set workIPArray to nil in commitModify Address potential memory issues by setting workIPArray to nil after releasing it in commitModify. This prevents dangling pointers and ensures consistency with rollbackModify, which already includes this safeguard. Without this change, PrefPane can crash upon closing the window used for setting IP addresses of cells in the CellServDB. Reviewed-on: https://gerrit.openafs.org/15962 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale (cherry picked from commit e45d0bd1e1ff500ace7b50ad7ea83d8ddf8b7e1c) Change-Id: I68082b1679a50a87a161dd03cf56ef88197fe0e6 Reviewed-on: https://gerrit.openafs.org/16066 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit fe009bb0537c80074b4a56ce871e9043216baf32 Author: Mark Vitale Date: Mon Aug 10 13:28:19 2020 -0400 viced: Ignore on-disk fsstate HashTable data Currently, if the fileserver tries to restore fsstate.dat and the included FE hashtable does not match our in-memory size (FEHASH_SIZE), we'll discard the entire state file. This is unnecessary, since we could just add the FEs to our hashtable ourselves; the on-disk hashtable data is not required. Furthermore, loading the hashtable from disk isn't even terribly efficient when the hashtable sizes do match, since any indices need to be converted from the on-disk values to in-memory values (fe_OldToNew). So if we're processing the FE hashtable indices anyway, we might as well just add them to the hashtable like normal, and ignore the values on disk. So, ignore loading the "fehash" data from the fsstate file, and just add file entries to our hashtable as we read them in. This ends up being slightly faster, simpler, and more flexible, since we don't need to worry about reflecting any changes to our hashtable in the fsstate.dat file. At least for now, we still write our hashtable data to fsstate.dat, in case other utilities (or older fileservers) need it. [adeason@sinenomine.net: Converted to always ignore on-disk hashtable data.] Reviewed-on: https://gerrit.openafs.org/14738 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie (cherry picked from commit f3629f87daa0c9067fbeb66d48ba1deb6fafac06) Change-Id: Icea91fe2ea266ae9fb53beb12dd7b664a4b30cb9 Reviewed-on: https://gerrit.openafs.org/16022 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 77b66bca167d1d2492bbf5f0bd6a901a347a72dd Author: Andrew Deason Date: Sun Aug 1 16:29:36 2021 -0500 viced: Log some basic fs_stateRestore stats Log how long it took to restore our fsstate.dat data, and how many FEs/CBs we loaded. This may be of interest to anyone looking at the impact of different relevant options (such as -fs-state-verify), and how much callback state is being restored. Note that we're not adding any new messages, just adding some additional info to an existing message. Reviewed-on: https://gerrit.openafs.org/14737 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit ef7aeddec1cd6ba060a076f2c81569a1726769cc) Change-Id: Icecb66b80164e6c60ef2daedaf14545efafd65dc Reviewed-on: https://gerrit.openafs.org/16021 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit cf029a06fd5f8e05f38b8b16c3989cfbfc4795d5 Author: Mark Vitale Date: Fri Jul 17 23:41:14 2020 -0400 viced: Log more state restore errors Some code paths in our state-restoring logic don't log the specific reason why restoring state failed. These cases shouldn't happen often, but try to at least log something for them, to try to make sure we always give a reason. [adeason@sinenomine.net: Added more messages.] Reviewed-on: https://gerrit.openafs.org/14728 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: Andrew Deason (cherry picked from commit 28bc6daa260e4ef27bead542aa32ebc2e72215f4) Change-Id: I1d8051d6ca9c67d2866b8e01500bd24465fc6248 Reviewed-on: https://gerrit.openafs.org/16020 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit d7eea35237b54907e63c021362a8bd74f9edb000 Author: Mark Vitale Date: Fri Jul 17 18:17:52 2020 -0400 viced: Raise fsstate loop detection limits When verifying the sanity of host and callback state at startup and shutdown, dafileserver attempts to detect loops in various structures by imposing arbitrary hard-coded limits (e.g. FS_STATE_HCB_MAX_LIST_LEN, 100000 callbacks per host). However, it is possible for AFS clients with heavy RW workloads to legitimately exceed some of these limits, if the dafileserver itself is configured with -cb higher than 100000, for instance. When this occurs, the dafileserver will falsely invalidate the fsstate.dat file at shutdown: "cb_stateVerifyFCBList: error: list length exceeds 100000 (h->index=1); assuming there's a loop" The dafileserver will then refuse to load the invalid fsstate.dat file at startup, defeating the callback preservation feature just when it is most sorely needed - when there are hundreds of thousands of callbacks. These arbitrary limits are unnecessary, since we already know the number of structures we're processing for all of these cases (CBs, FEs, and hosts). So just get rid of the hard-coded limits, and use the actual limit for the relevant structure instead: For CBs and FEs, we can never have more than 'cbstuff.nblks' entries whether we're loading or saving state, so just use that limit for simplicity. For hosts, the number of entries is either in the dump file (when restoring state), or just in our 'hostCount' global (when saving state). To make sure a corrupted state file doesn't cause the host limit to be unreasonably high, impose a new, higher, arbitrary limit on the number of hosts (FS_STATE_H_MAX_LIST_LEN, set to 100M). [adeason@sinenomine.net: Raise limits for _all_ structures.] Reviewed-on: https://gerrit.openafs.org/14727 Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason (cherry picked from commit c5e3b430d8d2f2c3c408df76fffe9ed7c648dbc1) Change-Id: I5fa86b82f829d48f508c07b2b13245bd1993c5d5 Reviewed-on: https://gerrit.openafs.org/16019 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit e30903a9d66f37fdf00603586529ce077f69da85 Author: Mark Vitale Date: Fri Jul 17 17:27:51 2020 -0400 viced: Set FS_STATE_DUMP_MODE earlier When the fileserver saves its callback state to disk on shutdown, fs_stateCreateDump sets state->mode to FS_STATE_DUMP_MODE. But this is after some code paths have already looked at state->mode, such as fs_stateSave -> h_stateVerify -> h_Enumerate_r -> h_stateVerifyHost -> h_stateVerifyAddrHash. This doesn't cause any problems right now, since the value of FS_STATE_DUMP_MODE is 0, and we zero the whole 'state' struct when it is initialized. This is confusing, though, so move the assignment of FS_STATE_DUMP_MODE to earlier in the state-saving process, before anything looks at it. To try to avoid possible uninitialized use of state->mode in the future, change the FS_STATE_*_MODE constants so that none of them are 0, and make sure that code checking the 'mode' checks that the mode is a valid constant. [adeason@sinenomine.net: Added state mode checking.] Reviewed-on: https://gerrit.openafs.org/14726 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Andrew Deason (cherry picked from commit 900d89380dea5703a365aed61e998c5f1004b056) Change-Id: I76ca239c9c28cfb524631ce5f5688eeb443b846a Reviewed-on: https://gerrit.openafs.org/16018 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit a8ac4758226b7e750a66e53a7326bd4ad317dc2c Author: Mark Vitale Date: Fri Jul 17 11:58:25 2020 -0400 viced: Use calloc for fsstate data Internal struct fs_dump_state contains a number of pointer members to other internal headers that are allocated via malloc, and later zeroed or read in from disk. Use calloc instead (and remove some of the now-redundant memsets) to make sure we never accidentally use the uninitialized memory. While here, also use sizeof the member names rather than the member types. [adeason@sinenomine.net: Removed some memsets.] Reviewed-on: https://gerrit.openafs.org/14725 Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 95d3cbe7071b461ff64cfe248d11af7a0f12512d) Change-Id: Ia918e380ca55b921e6899136ed995a8ba548dfed Reviewed-on: https://gerrit.openafs.org/16017 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 1560c512f2eabfedd13e5df95148ea71e1a89138 Author: Mark Vitale Date: Sun Jun 21 21:44:17 2020 -0400 viced: Fix minor log message mistakes Fix a few minor mistakes/typos that have crept up in viced over time: - In PrintCallBackStats, struct FEs and struct CBs are 64 bytes, not 16 bytes. Show the actual size of the structs. - A log message in cb_stateDiskEntryToFE is missing the trailing newline. - In cb_stateVerifyHCBList, a log message mentions the non-existent cb_stateVerifyFCBList (instead of cb_stateVerifyHCBList) Reviewed-on: https://gerrit.openafs.org/14724 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 3ccf8eaeb0bc19be8e11241740d0bfd7325711d1) Change-Id: I8e12d7b1ec5369e58d5760759c7e9ffae638cbed Reviewed-on: https://gerrit.openafs.org/16016 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 73ed44db3a87a10cfd5b87bd1baa8bc492fdb9c7 Author: Michael Meffie Date: Thu Dec 5 14:56:24 2024 -0500 rx: Add rxi_GetLocalAddr() prototype Commit 91378d93b9 (rx: Don't send packets to localhost if -rxbind set) added the rxi_GetLocalAddr() function, but missed the prototype. Add the function prototype to fix a GCC missing-prototype warning when building the linux kernel module. Fixes the build error when building the kernel module for Linux 6.8 or later when the tree was configured with --enable-checking: .../src/libafs/MODLOAD-6.8.0-49-generic-SP/rx.c:9693:1: error: no previous prototype for ‘rxi_GetLocalAddr’ [-Werror=missing-prototypes] 9693 | rxi_GetLocalAddr(struct sockaddr_in *sin) | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Reviewed-on: https://gerrit.openafs.org/15978 Tested-by: BuildBot Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Cheyenne Wills Tested-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit d6a2b4b44ddaec54f78737ab1971ffe4d3c28117) Change-Id: Ief384e4e46b5e46196a88cebd1db6cd30de02f82 Reviewed-on: https://gerrit.openafs.org/16012 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 2f094fe573d0fafdcbc078585e8a0542f9255ac1 Author: Andrew Deason Date: Mon Nov 11 16:16:33 2024 -0600 rx: Don't send packets to localhost if -rxbind set For some platforms (SOLARIS, FBSD), shutting down the libafs client currently involves sending a packet to localhost to wakeup the listener thread. If rx is bound to a specific host address (the -rxbind option was passed to afsd), this won't work, because rx won't receive packets sent to localhost. This results in the client hanging forever when trying to 'umount afs', until a packet is otherwise sent to the rx socket. To fix this, send the packet to the bound host address instead, if -rxbind was given. Otherwise, send the packet to localhost, like before. Introduce the small helper function rxi_GetLocalAddr() to consolidate the logic of what address to use. Reviewed-on: https://gerrit.openafs.org/15906 Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills Tested-by: Andrew Deason (cherry picked from commit 91378d93b9dbaf8e7ae8b3d0f655de63397cd545) Change-Id: Ibeb50ff00311f0c34095405ba4a136e648a37018 Reviewed-on: https://gerrit.openafs.org/16011 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 61722ff2c8ee9deb451701ba54c8df8c2456d2b9 Author: Andrew Deason Date: Mon Nov 11 15:34:50 2024 -0600 rx: Introduce 'rx_host' internal global Remember what local address we're bound to (as passed to rx_InitHost(), which is given when -rxbind is passed to various programs), like we do for our local port with rx_port. Store this in a new internal global variable, rx_host. This commit just introduces the new variable, but does not use it. Future commits will add code that make use of this information. Reviewed-on: https://gerrit.openafs.org/15905 Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Marcio Brito Barbosa Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills (cherry picked from commit 1cb8deb64fb54562ce25aef17e4c7be7a7b65444) Change-Id: Iace31cdd823283de4024c9de77d017d09b05125b Reviewed-on: https://gerrit.openafs.org/16065 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit ae8b53feda27cf5daa0d79d425ed56f3f707a176 Author: Andrew Deason Date: Fri Jan 3 11:48:10 2025 -0700 Avoid rxi_tracename overflow When processing the -trace option for the vlserver (and a couple of other places), we can easily overflow the rxi_tracename array if the given string is too big. While the way this global setting works in general isn't the best, at least for now just prevent the buffer overflow by doing a simple bounds check with strlcpy. Reviewed-on: https://gerrit.openafs.org/14753 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Cheyenne Wills (cherry picked from commit a794383f5e035231797a3683ae67dbf9e9d7bcd3) Conflicts: src/rx/test/testserver.c - added the "extern char rxi_tracename" from the master commit: "rx: Cleanup and build src/rx/test" (236cb51b833d) Change-Id: I456a1db092f5180c11f4a6f5ad872e11799a1103 Reviewed-on: https://gerrit.openafs.org/16010 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit 6527bbe4f6074f63ffdd23d3357058cf31624914 Author: Andrew Deason Date: Mon Nov 6 13:49:59 2023 -0600 LINUX: Block non-fatal signals when sleeping Currently, when sleeping on LINUX, we either block all signals (afs_osi_Sleep), or do not block signals at all (afs_osi_SleepSig). The only caller of afs_osi_SleepSig() is afs_read(), with the intention that a user can interrupt the process while it's waiting for data from an unresponsive server. This can cause problems when afs_read() is called during a paging request. In this case, if we are interrupted by a signal, we'll return an error (EINTR) from afs_linux_readpage(), which causes a SIGBUS to be sent to the process if it's not already dying. If we're interrupted by a fatal signal, the process is already dying so this is fine. But if we're interrupted by a non-fatal signal with an installed signal handler, the SIGBUS almost always causes the process to die immediately (and maybe dump core), where it otherwise would have been fine. This can be very confusing to a user when it happens, since it's not immediately obvious that AFS was involved at all; the dumped core often just shows the SIGBUS generated during a mundane memory load or store. This situation is most easily seen when running golang out of /afs, but has also been seen with git and other programs. Anything that makes heavy use of signals while data is being fetched from /afs is likely to trigger the behavior. This problem in general may not be specific to Linux, since the relevant code path is in cross-platform code (afs_read -> afs_osi_SleepSig). But notably, this does not happen on Solaris[1]; other platforms may have their own quirks that prevent this from becoming a problem. To avoid this for Linux, block all signals except SIGKILL when we're sleeping via afs_osi_SleepSig(). This allows the process to be killed if needed, but prevents interruption from any non-fatal signal. Ideally we would put our process in TASK_KILLABLE state, using functions like wait_event_killable() or wait_event_state() instead of blocking signals. But these functions have evolved over time, making this approach complex or even impossible for various Linux versions in our current design. Future commits may improve this; for now, do the simpler fix and just block signals. We could theoretically still allow non-fatal signals to interrupt sleeps when called from a syscall like read(). But this is difficult with the current structure of our Linux integration (syscall i/o is implemented on top of the paging system, like most Linux filesystems), and other filesystems tend to not do this. Also, interrupting a stalled afs_read() in general doesn't currently work very well anyway. The only callers of afs_osi_SleepSig() look like this, to wait for a background fetch (BOP_FETCH) to complete: while (!code && tdc->mflags & DFFetchReq) { /* other locks, etc */ ReleaseReadLock(&tdc->lock); code = afs_osi_SleepSig(&tdc->validPos); ObtainReadLock(&tdc->lock); } A signal will cause afs_osi_SleepSig() to return, but then we must wait to get tdc->lock. The background BOP_FETCH operation will keep tdc->lock write-locked for the entire fetch from the fileserver (afs_CacheFetchProc()), so we won't be able to continue until the fetch completes. Future commits may improve this, but for now just avoid the unnecessary SIGBUS errors. [1] On Solaris, the equivalent code path (afs_GetOnePage()) does not go through afs_read() with noLock==0, but instead calls afs_GetDCache() to handle fetching data. It does call afs_ustrategy() to fill a page, which does technically call afs_read(), but with noLock==1, and so avoids the case where we submit a BOP_FETCH and wait for it. Fetching data from the network happens in the afs_GetDCache() call, and so does not use afs_osi_SleepSig(). Reviewed-on: https://gerrit.openafs.org/15637 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit addee4295946fc9af6027fc555b27945d2edead9) Change-Id: Id6676f1e899538c9407ad85a02238666a1463def Reviewed-on: https://gerrit.openafs.org/16008 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 4608f1478b9d2d85cd69264abda697c4d9970c0c Author: Andrew Deason Date: Mon Nov 6 13:32:48 2023 -0600 LINUX: Refactor afs_osi_Sleep Instead of having afs_osi_Sleep() call afs_osi_SleepSig() directly, have both afs_osi_Sleep() and afs_osi_SleepSig() call a common helper function, afs_linux_sleep(). This makes it easier for future commits to alter the behavior for the _Sleep and _SleepSig variants. This commit should incur no noticeable change in behavior. We now manipulate the signal mask outside of AFS_GLOCK, but this doesn't matter because 'current' and the signal mask are unrelated to any of our locks. The signal mask is protected by SIG_LOCK (a wrapper from osi_machdep.h for various different locks for different kernel versions), and is handled in this commit the same as it was before. Reviewed-on: https://gerrit.openafs.org/15636 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk (cherry picked from commit 4f0244e2950d93101368bc78367b67b1ec2ef264) Change-Id: I9633eab087bc3af15e4db3d11bf24b746f8c3868 Reviewed-on: https://gerrit.openafs.org/16007 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 141469dc16e2af16750ed89b9fa1443385b50e79 Author: Marcio Barbosa Date: Wed Jul 31 08:26:59 2024 +0000 volinfo: Refuse zero and non-numeric -volumeid Currently, volinfo/volscan offers an optional -volumeid parameter, allowing users to specify the id of a single volume to generate output for. If this option is omitted, volinfo/volscan processes every volume in the specified partition, or all local partitions if no partition is specified. Internally, when the -volumeid parameter is not provided, its corresponding variable defaults to 0, which volinfo/volscan interprets as an indication to process all volumes. Unfortunately, if an invalid volume id is specified (e.g., a volume name instead of a number), volinfo/volscan incorrectly treats it as 0 and processes all volumes instead of validating the input and notifying the user. This issue occurs because strtoul(), the function used to convert the volume id string to a number, returns 0 when it fails to perform a valid conversion, leading volinfo/volscan to misinterpret invalid volume ids as 0. This commit fixes this issue by adding validation for the -volumeid option. It parses the result from strtoul() and returns an error if the volume id is invalid. This ensures that users are properly informed when an invalid id is provided, preventing unintended processing of all volumes in the given partition. Reviewed-on: https://gerrit.openafs.org/15771 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason (cherry picked from commit 4f8a5b1a2295ba37eb4cb0eda2c459f07ac4f09a) Change-Id: I068bd2ffa5e1e055b0e7fb3de874cc0bad0a3b71 Reviewed-on: https://gerrit.openafs.org/15817 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 2374d31de562a6aeec05ada7d9a0b8a3a8226f41 Author: Andrew Deason Date: Thu May 18 13:34:14 2023 -0500 AIX: Don't specify -qlanglvl=stdc99 for libuafs Commit beff42414ae (aix-5-update-20041207) added -qlanglvl=stdc99 to our CFLAGS for libuafs, apparently to handle __file__ (or __FILE__) in afs_osi_pag.c. The clang-based xlc 17.1 on AIX does not understand this argument, which causes an error: CC .../src/libuafs/afs_osi_pag.lo .ibm-clang: error: unknown argument: '-qlanglvl=stdc99' afs_osi_pag.c doesn't directly use __FILE__. Various other files in src/afs indirectly reference __FILE__, so this probably is not needed at all anymore. Just remove it. Reviewed-on: https://gerrit.openafs.org/15447 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: Andrew Deason Reviewed-by: Michael Meffie (cherry picked from commit 895d82bae8737677134fc0b5b36104acb4d2b24b) Change-Id: I5a304393bf15ee6e08d9ae0df7ebfede3e7c5967 Reviewed-on: https://gerrit.openafs.org/15812 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 5cc6b04664ba1e952c16ed6accd71b16785aebcd Author: Andrew Deason Date: Thu May 18 13:10:08 2023 -0500 AIX: Declare syscall() In various places, we make direct libafs syscalls. On platforms with a dedicated libafs syscall number, this involves passing AFS_SYSCALL to a generic OS-provided function that issues the given syscall (usually called syscall()). On AIX, there is no generic syscall() function for issuing system calls. Instead, system calls are treated like function calls, and are translated into system calls at link-time. So our calls to e.g. lpioctl() and lsetpag() are issuing system calls on AIX, and we have no userspace definition of these functions. Along with lpioctl() and lsetpag(), libafs also defines a system call confusingly named 'syscall'. Since this is our system call, of course the system headers provide no declaration for it, and so this causes errors when building using the clang-based xlc 17.1, such as: .../src/volser/volmain.c:195:2: error: call to undeclared function 'syscall'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] syscall(AFS_SYSCALL /* AFS_SYSCALL */ , 28 /* AFSCALL_CALL */ , a3, ^ To avoid these errors, declare a prototype for syscall(). But be clear that this is a function (technically a system call) provided by OpenAFS, not by the OS. Ideally our prototype would match the definition of syscall() in afs_syscall.c, but our various callers pass a varying number of arguments (as is normal for syscall() on other platforms). So at least for now, declare it as a function with unspecified args. Reviewed-on: https://gerrit.openafs.org/15446 Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 9c4ce09091a953a7062e8e451c0a4b5d4393db51) Change-Id: I5c4d51119feade1b3caab238daf87e1e5d4a2050 Reviewed-on: https://gerrit.openafs.org/15811 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 82332cc6d045fe112d6d6d14c57e5e6a4c3bc016 Author: Andrew Deason Date: Thu May 18 12:43:19 2023 -0500 AIX: Avoid COMPAT_43 for clang We currently define COMPAT_43 for AIX. This causes some socket-related structures and functions to be defined to be compatible with BSD 4.3, but causes us to not get function prototypes for recvmsg() and sendmsg(). When using the clang-based XLC 17.1, this causes errors: .../src/rx/rx_lwp.c:414:12: error: call to undeclared function 'recvmsg'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] code = recvmsg(socket, msg_p, flags); ^ .../src/rx/rx_lwp.c:432:12: error: call to undeclared function 'sendmsg'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] while (sendmsg(socket, msg_p, flags) == -1) { ^ To avoid this, don't define COMPAT_43. To try to make sure we don't change anything when using the old xlc, still define COMPAT_43 when we're not using clang. Reviewed-on: https://gerrit.openafs.org/15445 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 8207d4d74e6b243ace853f2c5fb6d44f22c7710f) Change-Id: Ifb1ddb117456c7674a07c2ebd692ac3e88428529 Reviewed-on: https://gerrit.openafs.org/15810 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 3869465a75650373915495aec6a0428e7fd21db7 Author: Mark Vitale Date: Mon May 22 11:18:04 2023 -0400 macos: Remove vestigial AFS_MOUNT_AFS references Commit 6b96a49eb6 "Retire AFS_MOUNT_AFS" removed all AFS_MOUNT_AFS references. However, a few were inadvertently reintroduced with the following commits: f379e1b255 "macos: Add support for MacOS 14.X (Sonoma)" e5a97ef2b4 "macos: Add support for MacOS 13.0 (Ventura)" 7a862f940b "macos: Add support for MacOS 12.0" 39b74c2c37 "macos: Refactor param.x86_darwin_200.h" acc955bc17 "macos: add support for MacOS 11.0" Remove them. No functional change is incurred by this commit. [mmeffie: Remove ones added by 14.x too] Reviewed-on: https://gerrit.openafs.org/15453 Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 3eb74d2b95d6651f96ce112fe2db455d4bc56b2a) Change-Id: Ifa69eafc10c5c73a0286912d6609f70855d666d9 Reviewed-on: https://gerrit.openafs.org/15809 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit b558769b77043acb2719b24d48643abbd717bef1 Author: Andrew Deason Date: Wed Dec 29 15:29:14 2021 -0600 LINUX: Test for rcu_read_unlock with rcu_read_lock If we're going to call rcu_read_lock(), we're also going to need to call rcu_read_unlock(). Make sure both functions are available before saying that rcu_read_lock is available. Without this, trying to use rcu_read_lock/unlock can result in errors during the kernel build for kernels where rcu_read_unlock calls rcu_read_unlock_strict (a GPLONLY function). This started in Linux commit aa40c138cc8f (rcu: Report QS for outermost PREEMPT=n rcu_read_unlock() for strict GPs), which was included in Linux 5.10. Reviewed-on: https://gerrit.openafs.org/14876 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit d9a9245f51b6ffaafa6021e4abe64bbfec0ee17b) Change-Id: I5da58531269ff87c0f5d6fd889157abe87960571 Reviewed-on: https://gerrit.openafs.org/15808 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 11f4ffc7f623d286d260dab9346709f163c1f462 Author: Andrew Deason Date: Mon May 8 16:04:58 2023 -0500 Remove almost all bcopy/bzero/bcmp calls Get rid of some remaining references to bcopy, bzero, and bcmp. In a few places (such as ka-forwarder.c, and linked_list.c), these were being called without including strings.h, which causes errors on AIX when using the clang-based xlc 17.1 compiler. Remove references even inside comments or documentation, to make it easier to make sure they've all been removed. Leave some references inside platform-specific or kernel code, since those are more likely to need bcopy() et al, and tend to only impact that platform. Note that most references to bcopy() et al were removed by commit c5c521af0e (convert-from-bsd-to-posix-string-and-memory-functions-20010807). Reviewed-on: https://gerrit.openafs.org/15432 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit 4fee9a2f9eceb88937f45b44340e567d8c945773) Change-Id: Ia209f518f2db9d1e6d87f0e825b6fad361f2901c Reviewed-on: https://gerrit.openafs.org/15807 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit c9afe7026d9ad30ffe662723bd55f51a0df79010 Author: Stephan Wiesand Date: Fri Apr 5 14:54:24 2024 -0400 make-release: create SHA256 checksums too Check for utilities to create both MD5 and SHA256 message digest files. Search the PATH plus some common directories for the message digest utilities. Exit with an error at the end of make-release when one or more message digest files are not generated. In addition, omit the path component in the generated files by running the message digest utilities in the directory containing the files being checked. Before: $ make dist ... $ cat packages/openafs-1.9.1-333-g4bf33-doc.tar.gz.md5 920793bcd7bd9bc8fbff9016ed2cc8bb packages/openafs-1.9.1-333-g4bf33-doc.tar.gz After: $ make dist ... $ cat packages/openafs-1.9.1-333-g4bf33-doc.tar.gz.md5 920793bcd7bd9bc8fbff9016ed2cc8bb openafs-1.9.1-333-g4bf33-doc.tar.gz [mmeffie: Add change directories, search PATH, update commit message.] Reviewed-on: https://gerrit.openafs.org/14566 Tested-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 407c6371572b1b7e815f30c0718e14b1c6b385e5) Change-Id: I2fd0150267cb243b26fd515ab9a68c83ff3c0e70 Reviewed-on: https://gerrit.openafs.org/15806 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit e0626c45c6eac5aa560d6883ceab7993135d50f5 Author: Michael Meffie Date: Thu Apr 16 09:41:41 2020 -0400 make-release: Run git describe once Run git describe once at the beginning of make-release to find the version information used to derive the tarball file names and saved in the .version file. This is a cleanup and refactoring change to prepare for a future commit. Reviewed-on: https://gerrit.openafs.org/14150 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 188ca8bf5276084a6892e5cfba3e24e478804382) Change-Id: Ifb226ed80edd74dd66e5f88282b058492b52d5a0 Reviewed-on: https://gerrit.openafs.org/15805 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 44895df543526d29eddca4a7e8f0a21b2e158a12 Author: Michael Meffie Date: Fri Mar 27 11:29:24 2020 -0400 make-release: Create output directory if needed Automatically create the --dir directory if it does not already exist, which makes this script slightly easier to use. Remove the now uneeded mkdir from the top-level makefile. Reviewed-on: https://gerrit.openafs.org/14115 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit d0753c0ace8e43a7dc1db35c3f41130352278c04) Change-Id: I91f8658b42835a6045eab3fafeab2bb977cbdb2d Reviewed-on: https://gerrit.openafs.org/15804 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 7e87a0ea550cd2580b2facee36820eb71cd8cfb8 Author: Michael Meffie Date: Thu Apr 16 07:21:51 2020 -0400 make-release: Remove unused optional version argument The make-release help shows an optional version argument, but in fact the version info is always generated from the git tag name argument, which makes sense when creating releases. Continue to throw away the second positional argument just in case someone is still passing a second argument, but issue a warning if they do. Reviewed-on: https://gerrit.openafs.org/14149 Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk Tested-by: Benjamin Kaduk (cherry picked from commit d20d392091a13c3944973bcb0ce84783a4e0d179) Change-Id: Iabdc3e9fe966da35744974c769da86c65380424f Reviewed-on: https://gerrit.openafs.org/15803 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 24ddb358e4e2c18a9fab649f1ea1b8250ec148b8 Author: Michael Meffie Date: Thu Apr 16 07:37:39 2020 -0400 make-release: Clean up whitespace and spelling Fix whitespace errors, convert tabs to spaces, fix spelling errors, and fix pod markup in the make-release script. Reviewed-on: https://gerrit.openafs.org/14148 Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Benjamin Kaduk (cherry picked from commit 46eb00ffa1c6d7deda2c1b1b4fa1780b36e64417) Change-Id: I13e48e28c4b9e30a550c4912609b7ac9a58ba952 Reviewed-on: https://gerrit.openafs.org/15802 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 16b53b79ae420f66445ffd463fb8217a42a7e011 Author: Michael Meffie Date: Mon Dec 18 15:47:37 2023 -0500 rx: Print free and allocated counters as unsigned values Commit b967654434 (rxdebug-print-values-unsigned-20090512) changed the output of rxdebug to print counters as unsigned values. However, that commit missed changing the format of the "free" and "allocated" packets counters. Change the printf format specifiers of the "free" and "allocated" packet counters to print them as unsigned values. The free packets counter is stored as an afs_int32, which maybe a long on some platforms. This counter was previously cast to an int type in commit 1d93f2da22eb (rx-warnings-and-prototyping-20010623) to avoid a format specifier warning. Update the cast to an unsigned int to be clear this is an unsigned value. Reviewed-on: https://gerrit.openafs.org/15608 Reviewed-by: Andrew Deason Reviewed-by: Mark Vitale Reviewed-by: Cheyenne Wills Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit bee056613311c2a95f946c8eb25b6def97e7ec29) Change-Id: I14376240c059bb833648609e131719ada6bb74a8 Reviewed-on: https://gerrit.openafs.org/15801 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 659f08df7f4bf8ff298ef37ac551a989f1fd9871 Author: Cheyenne Wills Date: Thu Aug 15 16:08:18 2024 -0600 rx: Remove includes for MIN/MAX in rx_packet.h The commit: "opr: replace MIN/MAX macros with opr_min/opr_max" (Change I2d7b54193ec91f7ead9c5c5f714d9a8bc7533bf7) replaced all uses of the MIN and MAX macros with opr_min and opr_max. The include for sys/param.h and sys/sysmacros.h in rx_packet.h are no longer needed for MIN/MAX. Remove the preprocessor conditionals and the includes for param.h and sysmacros.h. Reviewed-on: https://gerrit.openafs.org/15823 Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: BuildBot (cherry picked from commit d299dfbfe90482b26b5f5551eb5be1b8e76d6ac4) Change-Id: Ic1dec6f69bb8f9fd6eaffd0d893f0b2113193ae7 Reviewed-on: https://gerrit.openafs.org/15855 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 9de1b31c4891897169ae3dc36032760bd653ffde Author: Andrew Deason Date: Thu Oct 20 18:31:43 2022 -0500 rx: Use atomics for rx_securityClass refcounts Currently, the refCount in struct rx_securityClass is not protected by any locks. Thus, if two threads create or destroy a connection using the same rx_securityClass at the same time (or call rxs_Release), the refCount can become inaccurate. If the refCount is undercounted, we can prematurely free it while it's still referenced by other connections or services, leading to segfaults, data corruption, etc. For client connections, this can happen between any threads that create and destroy a connection using the same security class struct. For server connections, only two threads can race in this way: the rx listener thread (which creates connections), and the rx event thread (which destroys idle connections in rxi_ReapConnections). To fix this, ideally we would change the refCount field to be an rx_atomic_t. However, struct rx_securityClass is declared in the public installed rx.h header, which cannot include rx_atomic.h. So instead, change refCount users to go through a few new functions: rxs_Ref(), rxs_DecRef(), and rxs_SetRefs(). These functions interpret the refCount as an rx_atomic_t, and so allows callers to use safe refcounting without needing to call rx_atomic_* functions directly. Rename the existing refCount field to refCount_data, and declare it as a char[8]. This gives us enough space to use it as an rx_atomic_t, but avoids using rx_atomic_t in a public header, and discourages callers from manipulating the refCount directly. Thanks to mvitale@sinenomine.net for helping investigate the relevant issue. Reviewed-on: https://gerrit.openafs.org/15158 Reviewed-by: Cheyenne Wills Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Michael Meffie (cherry picked from commit 9d7b94493c3d0230c15417436885a4211caeb411) [cwills@sinenomine.net] Changes to rxgk/rxgk_client.c and rxgk/rxgk_server.c are not applicable to 1.8.x Change-Id: I37d6944daa155a47ba1b8a0e717af7b5753a7b41 Reviewed-on: https://gerrit.openafs.org/15850 Reviewed-by: Michael Meffie Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk commit 0f610fb5ad52ad5d188ea0104e9cadb7fac0fae1 Author: Andrew Deason Date: Wed Oct 12 14:42:33 2022 -0500 rxkad: Consolidate refCount decrement To make code changes easier, all rxkad code that deals with incrementing/decrementing the rx_securityClass refCount should be done in the same place. Right now, there's only one incrementing code path, but there are two decrement code paths that are duplicated. Change the rxkad_DestroyConnection refCount-handling logic to just call rxkad_Close(), since the behavior is identical. Reviewed-on: https://gerrit.openafs.org/15153 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Benjamin Kaduk (cherry picked from commit f2831d109d7a111a1dbdce33e02bcea560127206) Conflicts: src/rxkad/rxkad_common.c In 1.8.x, the function rxkad_DestroyConnection() still needs to return a value, because the master commit 'rx: Do not ignore RXS_* op errors' (635594d6cceba) is not in 1.8.x. Change-Id: I097976505ee16d3f8209aa1ff3a82d675ff95ec8 Reviewed-on: https://gerrit.openafs.org/15851 Reviewed-by: Benjamin Kaduk Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Michael Meffie commit 1d73cc339095e13b99f83ffff81079cc4d300189 Author: Andrew Deason Date: Wed Oct 23 15:46:16 2019 -0500 Do not build shared-only libs for --disable-shared Commit 0f1e54c4 (Pass -shared when linking some shared libraries) changed some of our linking rules to pass -shared to libtool when linking. When building with the --disable-shared configure option, this causes those linker rules to fail, since shared libraries are disabled. Before commit 0f1e54c4, we could build with --disable-shared successfully. To allow us to build again with --disable-shared, just don't build the relevant shared-only libraries at all, when shared libraries are disabled. To accomplish this, introduce a new substitution variable, SHARED_ONLY, which allows certain lines in Makefiles to become commented-out when shared libraries are disabled. Update all of the shared-only libraries to be built conditionally based on this variable. Except for libuafs.la, which appears to be not referenced by anything. Just remove the rules for that instead. Reviewed-on: https://gerrit.openafs.org/13927 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk Tested-by: BuildBot (cherry picked from commit 10d176afd23bbf684017a7946dffb1d592ea04fa) Change-Id: I1f4c6601a6af2fd8b47469fac32db3dbe377a8e9 Reviewed-on: https://gerrit.openafs.org/16099 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit de1d0ce9c3705670c1f0c974006b5bbc7c747864 Author: Andrew Deason Date: Tue Jan 7 13:02:21 2020 -0600 libtool: Serialize building libfoo.la and libfoo.a We have a few libraries where we have separate targets to build libfoo.la (to get libfoo.so) and libfoo.a. Currently, these targets can be built in parallel, and both are built with libtool. This can cause problems because of two behaviors with libtool: - When running --mode=link for libfoo.a or libfoo.la, it effectively runs 'rm -rf .libs/libfoo.*' to clean up its work area. - When running --mode=link for libfoo.a, libtool sets up some scratch space in .libs/libfoo.ax to unpack various static libs. So when 'make libfoo.a' is running, libtool creates a .libs/libfoo.ax dir, and unpacks various object files inside of it. If while that is running, 'make libfoo.la' runs, it causes libtool to remove that directory and all its contents. This causes 'make libfoo.a' to fail with confusing messages like this (for libafsrpc.a): /bin/sh ../../libtool --quiet --mode=link --tag=CC gcc -static -O -o libafsrpc.a [...] find: '.libs/libafsrpc.ax/libopr_pic.a': No such file or directory ar: .libs/libafsrpc.ax/libfsint_pic.a/afscbint.cs.o: No such file or directory make[3]: *** [Makefile:59: libafsrpc.a] Error To avoid this, prevent building libfoo.la and libfoo.a at the same time, by just making libfoo.la depend on libfoo.a. Do this for all of the libraries we build in this way: libafshcrypto, libkopenafs, libafsauthent, and libafsrpc. Reviewed-on: https://gerrit.openafs.org/14017 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 48d181ca1f4d753a51305d0352dadefed4323c00) Change-Id: Idca8ff9d69441325a835e6f866a2cc7732d5e258 Reviewed-on: https://gerrit.openafs.org/16117 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 6e2b61ddfbb26d4316134a5cb6d5e4de24f5c8cd Author: Andrew Deason Date: Wed Jan 15 11:43:30 2025 -0700 tests: Fix manpage tests for objdir builds The manpage tests have a couple of problems when running for objdir builds: - We try to specify './tests-lib/perl5' as a directory to find our helper library. However, the cwd when we're running the tests is in an objdir build, where the helper library is in the srcdir. Fix this by using the SOURCE env var specified by the tests wrapper. - All of these tests specify the directory in which to find the man pages in a subdir of BUILD, but our manpages are located in the src dir (since they are built by regen.sh, not by configure/make). Fix this by specifying a SOURCE-based directory instead. To avoid needing to make the same change for each of these tests, also refactor the manpage tests so each test only needs to specify the subdirectory and command name, and get rid of some of the common boilerplate. Reviewed-on: https://gerrit.openafs.org/13940 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0b8b6683fb525bbeaf118014beb2371e0cf23d90) Conflicts: tests/bozo/bos-man-t tests/bucoord/backup-man-t tests/kauth/kas-man-t tests/ptserver/pts-man-t tests/venus/fs-man-t tests/volser/vos-man-t cwills@sinenomine.net conflicts are due the different order of commits. In master the commit: "tests: Fix manpage tests for objdir builds" (0b8b6683fb525) is applied before "tests: Accommodate c-tap-harness 4.7" (624219a1b2192). In 1.8.x the commit: "tests: Accommodate c-tap-harness 4.7" (0453c15b2a2cb) is already present. Change-Id: I065c6e4e16619bd90c8cf8d28fa5b5cddd67c410 Reviewed-on: https://gerrit.openafs.org/16092 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit cd6331800578ae6d34c56964bd55fdb1a5149cd4 Author: Andrew Deason Date: Wed Jan 15 11:23:00 2025 -0700 tests: Fix most tests for objdir builds Fix a few miscellaneous issues with building and running our tests in objdir builds: - Our C tests use -I$(srcdir)/../.. in the CFLAGS, so we can #include . However, basic.h actually gets copied from src/external/c-tap-harness/tests/tap/ to tests/tap/ during the build, and so basic.h is available in the objdir, not srcdir. For objdir builds, this causes building the tests to fail with failing to find basic.h. Fix this to use TOP_OBJDIR as the include path instead. - Our 'make check' in tests/ tries to run ./libwrap; but our cwd will be in the objdir for objdir builds, and libwrap is a script in our srcdir. Fix this to run libwrap from the srcdir path. - In tests/opr/softsig-t, it tries to find the 'softsig-helper' binary in the same dir as 'softsig-t'. However, softsig-t is just a script in the srcdir, but softsig-helper is a binary built in the objdir. Fix this to use the BUILD env var provided by the tests wrapper, by default. Reviewed-on: https://gerrit.openafs.org/13939 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit f4ab3767b7e65028b93e731da6f09ee385c51daf) [cwills@sinenomine.net] - A change is required in tests/opr/softsig-t The change is required due to different order of commits. In master the commit: "tests: Fix most tests for objdir builds" (f4ab3767b7e65) is applied before "tests: Accommodate c-tap-harness 4.7" (624219a1b2192). In 1.8.x the commit: "tests: Accommodate c-tap-harness 4.7" (0453c15b2a2cb) is already present. Change-Id: Ide0d2028ec936f047e6cda5e29257cb0d263fde8 Reviewed-on: https://gerrit.openafs.org/16091 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 84affc46686ff9c3f67b6c66117e6dd654f19638 Author: Andrew Deason Date: Fri Aug 16 12:48:21 2019 -0500 Pass -shared when linking some shared libraries Currently, we use $(LT_LDLIB_shlib) to build most of our shared libraries. This invokes libtool, passing our various flags like PTH_LDFLAGS and PTH_CFLAGS (since all of our shared-library code is for pthreads). Notably, we do NOT pass the -shared flag; the -shared flag tells libtool to only build a shared library, and to not also build a static library (on systems where libtool supports building shared and static libraries simultaneously). Because of this, our LT_LDLIB_shlib invocations build both, which is reasonably correct for our per-module convenience libraries (that end up getting linked statically into the binaries that we install), but is not entirely correct for the public libraries that we install. Specifically, for ABI compatibility purposes, we must provide both shared and static libraries of the public libraries that we install, and since libtool on AIX does not build (or install) a static library at all with --mode-link unless -static is passed, we have separate rules to build the shared and static libraries for final installation. This can cause install errors with parallel make (on non-AIX systems), and possibly other errors, when we go to install the relevant library into TOP_LIBDIR. For example, in src/kopenafs, we have the following rules: ${TOP_LIBDIR}/libkopenafs.${SHLIB_SUFFIX}: libkopenafs.la ${LT_INSTALL_DATA} libkopenafs.la ${TOP_LIBDIR}/libkopenafs.la ${RM} ${TOP_LIBDIR}/libkopenafs.la ${TOP_LIBDIR}/libkopenafs.a: libkopenafs.a ${INSTALL_DATA} libkopenafs.a $@ The rule to install libkopenafs.so will invoke libtool to do the install, which will install libkopenafs.so, libkopenafs.so.X.Y, and libkopenafs.a (from .libs/libkopenafs.a, not the libkopenafs.a we built separately). If we are running the rule to install libkopenafs.a in parallel, it may fail with an error like so: /usr/bin/install -c -m 644 libkopenafs.a /home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a /usr/bin/install: cannot create regular file '/home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a': File exists make[3]: *** [Makefile:35: /home/buildbot/openafs/fedora26-x86_64/build/lib/libkopenafs.a] Error 1 Even without that error, this confusion means that the libkopenafs.a installed into TOP_LIBDIR may be the one from src/kopenafs/libkopenafs.a, or the one from libtool's src/kopenafs/.libs/libkopenafs.a; it depends on what order the rules are run. If those libraries are different, that could potentially cause all sorts of other problems. To avoid this, we can pass -shared to libtool when building our shared libraries. We used to pass -shared when building shared libraries, since -shared is almost always one our SHLIB_LDFLAGS set in src/osconf.m4. However, ever since commit 2c3a517e (Retire Makefile.shared), SHD_CFLAGS, SHD_LDFLAGS, and SHD_CCRULE have all been unused, and SHD_LDFLAGS was the only place where we used SHLIB_LDFLAGS. As a result, we never use SHLIB_LDFLAGS anywhere, and so we never pass -shared to anything. However, we cannot pass -shared to libtool when building all of our shared libraries, since we do need the static library for our per-module convenience libraries. For example, liboafs_rx.la has no separately-built static library (librx.a is for LWP, liboafs_rx.{so,a} is for pthreads), but liboafs_rx needs to be linked statically into all of our command-line tools. So to fix this, introduce a new linking rule, called LT_LDLIB_shlib_only, which causes the given library to be built only as a shared library (by giving -shared to libtool), and not as a static library. Update the build rules to use this new linking rule for the libraries that need it, and leave the others alone. Since the only use of LT_LDLIB_shlib_missing is also used for a public library (afshcrypto), also pass -shared in that rule. Also remove SHD_* and SHLIB_LDFLAGS variables, since they are unused. Reviewed-on: https://gerrit.openafs.org/13786 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0f1e54c47c179bdbd69799170d9740e3e58e86db) Change-Id: I9254ae91fe160a17fcfa4cbb55d0fe6909eb2302 Reviewed-on: https://gerrit.openafs.org/16098 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 8c7330cc8c9b20cb1c023564da1272b03853164b Author: Michael Meffie Date: Thu Aug 8 13:57:05 2024 -0400 doc: Add section 3 man pages to AdminRef The section 3 man pages are missing in the AdminRef document, so add section 3 to the Makefile and perl script which generates the AdminRef doc. Currently, the only man page in section 3 is the AFS::ukernel, so only one page is missing. Reviewed-on: https://gerrit.openafs.org/15828 Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie Tested-by: BuildBot (cherry picked from commit 7dc8a7ddc204766f1c083919c8732920b0552a68) Change-Id: I960a671f1b02789f7427dba15459e9f2568d152b Reviewed-on: https://gerrit.openafs.org/16026 Reviewed-by: Andrew Deason Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 239f3d538e2293332b94e14c42f5c953d49464b9 Author: Michael Meffie Date: Thu Aug 8 14:49:15 2024 -0400 doc: Add AdminRef .gitignore file Add a .gitignore file to the AdminRef directory to ignore generated files. Reviewed-on: https://gerrit.openafs.org/15826 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit 1bcc1e54a5a87da91c3108d836921361ac13c3d8) Change-Id: Ie3d84c0ad13ec2ad70d01c542fcab7a273b6b6c2 Reviewed-on: https://gerrit.openafs.org/16118 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk commit d9acc8f7fa86f42ae223b951a8464c4f63a7d194 Author: Andrew Deason Date: Sat May 11 16:09:15 2024 -0500 doc: Fix doc/xml for objdir builds Fix various issues so that building the documentation in doc/xml works for objdir builds: - set srcdir=@srcdir@ like all other Makefile's, so VPATH is set correctly via Makefile.config - Pass "--path '@abs_builddir@'" to all xml/xsl processors, so they can find the generated version.xml (otherwise they only look in srcdir) - Pass --output when building PDFs, so the generated PDF doesn't go in srcdir - Specify $(srcdir) for $(BOOK).xml and generate-xml.pl - Change generate-xml.pl to find pod2refentry in srcdir instead of '.' Reviewed-on: https://gerrit.openafs.org/15856 Tested-by: BuildBot Reviewed-by: Michael Meffie Tested-by: Michael Meffie Reviewed-by: Cheyenne Wills (cherry picked from commit d86c4d632edd25bf1f6e4c1dc44c10eff309bf4a) Change-Id: Ic628aa4d32b5d978a16d9fdc9125908b9f96b12f Reviewed-on: https://gerrit.openafs.org/16027 Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk commit 3df74018300b8894a6cbfdb39bbb204cb2320586 Author: Michael Meffie Date: Thu Aug 8 14:40:28 2024 -0400 doc: Sort man page entries in AdminRef The AdminRef is a collection of OpenAFS man pages in a single document. Unfortunately, the man pages are not listed in any particular order, but rather just the order found by reading the unsorted directory entries. Change the generate-xml script so the man pages are in sorted order in the generated AdminRef document. Instead of writing the man page references after processing each page, save each entry in a list, and then sort the list after all the pages have been processed. Also, check the exit code of the pod2refentry script so errors are not ignored while generating the AdminRef document. Reviewed-on: https://gerrit.openafs.org/15827 Tested-by: BuildBot Reviewed-by: Cheyenne Wills Reviewed-by: Michael Meffie (cherry picked from commit 6ff968264fd31abb7ab6e80dfb8d4906a83fa960) Change-Id: I6e4617b86b06d8721bf3dbf595217058511ec6b7 Reviewed-on: https://gerrit.openafs.org/16025 Reviewed-by: Cheyenne Wills Reviewed-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: Andrew Deason Reviewed-by: Benjamin Kaduk commit 6c696aaa639dfc63f97920d1c37e35fd457254e3 Author: Andrew Deason Date: Wed May 12 15:35:01 2021 -0500 doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 0881560e77d9d9f545eeaeeec730739dcece7c2f) Change-Id: Ibb843e1d4acc373442b77e5f0884402828fcc992 Reviewed-on: https://gerrit.openafs.org/16115 Reviewed-by: Andrew Deason Tested-by: Andrew Deason Reviewed-by: Michael Meffie Tested-by: Cheyenne Wills Reviewed-by: Mark Vitale Reviewed-by: Benjamin Kaduk