| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0003-Catch-up-to-roken-s-rename-of-base64-symbols.patch | Catch up to roken's rename of base64 symbols Upstream roken (i.e., heimdal) renamed their base64 encode/decode routines to have a rk_ prefix in 2014, but upstream OpenAFS hasn't pulled in an update to their bundled heimdal files since then. So, upstream is still using the old name, whereas we are trying to link against a more modern libroken, and must use the new names. |
Benjamin Kaduk <kaduk@mit.edu> | no | 2016-12-11 | ||
| 0005-tests-skip-vos-tests-when-a-vlserver-is-already-runn.patch | 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. (cherry picked from commit bf1b3e2fc12a7502cfd74eb109eeb7131f7230d3) |
Michael Meffie <mmeffie@sinenomine.net> | no | 2020-01-10 | ||
| 0006-tests-do-not-resolve-addresses-in-vos-vl-test.patch | tests: do not resolve addresses in vos/vl test The vos-t test adds a set of 10.* test addresses to a test vlserver and runs vos to read them back. When the test is run in an environment where hosts have been assigned in the 10.* internal network, vos will resolve the addresses to hostnames and the test fails. Pass the -noresolve option to vos for this test when checking for the expected list of addresses. Example test output before this commit: ./vos-t ... # seen: 10.0.0.0 10.0.0.1 myhost.example.com 10.0.0.3 ... not ok 5 - vos output matches (cherry picked from commit dcf44ab5fc5c1f5e2e759ea4b6156f7e1faa4b7a) |
Michael Meffie <mmeffie@sinenomine.net> | no | 2020-01-10 | ||
| 0007-Temporarily-disable-flaky-test.patch | Temporarily disable flaky test The volser test consistently fails on the armhf buildd but succeeds on the porterbox. The nature of the test in question suggests that the issue in the test triggers only on a machine with a specific network configuration using specific addresses in 10.0.0.0/8, which should help track down the issue causing the test to fail on the buildd. |
Benjamin Kaduk <kaduk@mit.edu> | no | 2020-03-24 | ||
| 0005-Avoid-duplicate-definitions-of-globals.patch | Avoid duplicate definitions of globals GCC 10 changed a default flag from -fcommon to -fno-common. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 for some background. The change in gcc 10 results in build link-time errors. For example: ../../src/xstat/.libs/liboafs_xstat_cm.a(xstat_cm.o):(.bss+0x2050): multiple definition of `numCollections'; Ensure that only one definition for global data objects exist and change references to use "extern" as needed. To ensure that future changes do not introduce duplicated global definitions, add the -fno-common flag to XCFLAGS when using the configure --enable-checking setting. [cwills@sinenomine.net: Note for 1.8.x: renamed terminationEvent to cm_terminationEvent/fs_terminationEvent instead of deleting it.] (cherry picked from commit 0e2072ae386d4111bef161eb955964b649c31386) (cherry picked from commit a2eec64374d6b754b29c509b554573cb6e53eb46) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-05-22 | ||
| 0006-afsmonitor-remove-unused-LWP_WaitProcess.patch | afsmonitor: remove unused LWP_WaitProcess Remove the unimplemented once-only flag and the unused LWP_WaitProcess call. (cherry picked from commit 7c27365ea24aed5787f6fc03f30f6085c78ece51) (cherry picked from commit d5fc5283e91ea94a67df8364a5b8bf8970ffe934) |
Michael Meffie <mmeffie@sinenomine.net> | no | 2017-10-09 | ||
| 0007-LINUX-Include-linux-time.h-for-linux-errqueue.h.patch | LINUX: Include linux/time.h for linux/errqueue.h The configuration test for errqueue.h fails with an undefined structure error on a Linux 3.17 (or higher) system. This prevents setting HAVE_LINUX_ERRQUEUE_H, which is used to define AFS_RXERRQ_ENV. Linux commit f24b9be5957b38bb420b838115040dc2031b7d0c (net-timestamp: extend SCM_TIMESTAMPING ancillary data struct) - which was picked up in linux 3.17 added a structure that uses the timespec structure. After this commit, we need to include linux/time.h to pull in the definition of the timespec struct. (cherry picked from commit 086d185872da5f19447cf5ec7846e7ce5104563f) (cherry picked from commit 0f67e733e82a9001f3f9253c5e1880be845d537b) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-04-02 | ||
| 0008-LINUX-5.8-Replace-kernel_setsockopt-with-new-funcs.patch | LINUX 5.8: Replace kernel_setsockopt with new funcs Linux 5.8-rc1 commit 'net: remove kernel_setsockopt' (5a892ff2facb) retires the kernel_setsockopt function. In prior kernel commits new functions (ip_sock_set_*) were added to replace the specific functions performed by kernel_setsockopt. Define new config test 'HAVE_IP_SOCK_SET' if the 'ip_sock_set' functions are available. The config define 'HAVE_KERNEL_SETSOCKOPT' is no longer set in Linux 5.8. Create wrapper functions that replace the kernel_setsockopt calls with calls to the appropriate Linux kernel function(s) (depending on what functions the kernel supports). Remove the unused 'kernel_getsockopt' function (used for building with pre 2.6.19 kernels). For reference Linux 2.6.19 introduced kernel_setsockopt Linux 5.8 removed kernel_setsockopt and replaced the functionality with a set of new functions (ip_sock_set_*) (cherry picked from commit c48072b9800759ef1682b91ff1e962f6904a2594) (cherry picked from commit d7fc5bf9bf031089d80703c48daf30d5b15a80ca) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-07-03 | ||
| 0009-LINUX-5.8-do-not-set-name-field-in-backing_dev_info.patch | LINUX 5.8: do not set name field in backing_dev_info Linux-5.8-rc1 commit 'bdi: remove the name field in struct backing_dev_info' (1cd925d5838) Do not set the name field in the backing_dev_info structure if it is not available. Uses an existing config test 'STRUCT_BACKING_DEV_INFO_HAS_NAME' Note the name field in the backing_dev_info structure was added in Linux-2.6.32 (cherry picked from commit d8ec294534fcdee77a2ccd297b4b167dc4d5573d) (cherry picked from commit 335f37be13d2ff954e4aeea617ee66502170805e) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-07-03 | ||
| 0010-LINUX-5.8-use-lru_cache_add.patch | LINUX 5.8: use lru_cache_add With Linux-5.8-rc1 commit 'mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()' (6058eaec), the lru_cache_add_file function is removed since it was functionally equivalent to lru_cache_add. Replace lru_cache_add_file with lru_cache_add. Introduce a new autoconf test to determine if lru_cache_add is present For reference, the Linux changes associated with the lru caches: __pagevec_lru_add introduced before v2.6.12-rc2 lru_cache_add_file introduced in v2.6.28-rc1 __pagevec_lru_add_file replaces __pagevec_lru_add in v2.6.28-rc1 vmscan: split LRU lists into anon & file sets (4f98a2fee) __pagevec_lru_add removed in v5.7 with a note to use lru_cache_add_file mm/swap.c: not necessary to export __pagevec_lru_add() (bde07cfc6) lru_cache_add_file removed in v5.8 mm: fold and remove lru_cache_add_anon() and lru_cache_add_file() (6058eaec) lru_cache_add exported mm: fold and remove lru_cache_add_anon() and lru_cache_add_file() (6058eaec) Openafs will use: lru_cache_add on 5.8 kernels lru_cache_add_file from 2.6.28 through 5.7 kernels __pagevec_lru_add/__pagevec_lru_add_file on pre 2.6.28 kernels (cherry picked from commit 7d85ce221d6ccc19cf76ce7680c74311e4ed2632) (cherry picked from commit facff58b840a47853592510617ba7a1da2e3eaa9) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-07-03 | ||
| 0011-LINUX-5.9-Remove-HAVE_UNLOCKED_IOCTL-COMPAT_IOCTL.patch | LINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL Linux-5.9-rc1 commit 'fs: remove the HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL defines' (4e24566a) removed the two referenced macros from the kernel. The support for unlocked_ioctl and compat_ioctl were introduced in Linux 2.6.11. Remove references to HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL using the assumption that they were always defined. Notes: With this change, building against kernels 2.6.10 and older will fail. RHEL4 (EOL in March 2017) used a 2.6.9 kernel. RHEL5 uses a 2.6.18 kernel. In linux-2.6.33-rc1 the commit messages for "staging: comedi: Remove check for HAVE_UNLOCKED_IOCTL" (00a1855c) and "Staging: comedi: remove check for HAVE_COMPAT_IOCTL" (5d7ae225) both state that all new kernels have support for unlocked_ioctl/compat_ioctl so the checks can be removed along with removing support for older kernels. (cherry picked from commit 13a49aaf0d5c43bce08135edaabb65587e1a8031) (cherry picked from commit e7902252f15acfc28453c531f6fa3b29c9c91b92) |
Cheyenne Wills <cwills@sinenomine.net> | no | 2020-08-21 | ||
| 0012-rx-rx_InitHost-do-not-overwrite-RAND_bytes-rx_nextCi.patch | rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core") introduced the use of RAND_bytes() to generate the initial 'rx_nextCid' but failed to remove the rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT; assignment inherited from IBM/Transarc. At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation overflows the value CID range. This triggers broken overflow logic in update_nextCid(). (cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473) |
Jeffrey Altman <jaltman@auristor.com> | no | 2021-01-14 | ||
| 0013-rx-update_nextCid-overflow-handling-is-broken.patch | rx: update_nextCid overflow handling is broken The overflow handling in update_nextCid() produces a rx_nextCid value of 0x80000001 which itself is out of the valid range. When used to construct the first call of a new connection the connection id for the call becomes 0x80000002, and all subsequent connections also trigger the overflow handling and thus also receive connection id 0x80000002. If the same connection id is used for multiple connections from the same endpoint the accepting rx peer will be very confused. When authenticated connections are used, the CHALLENGE/RESPONSE will fail because of a mismatch in the connection's callNumber array. If an initiator makes only a single connection to a given rx peer, that connection would succeed, but once multiple connections are initiated all communication from a broken initiator to any rx peer will fail. The incorrect overflow calculation was introduced by 39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid generation into the rx core"). This change corrects the overflow value to become 1 << RX_CIDSHIFT (cherry picked from commit 2c0a3901cbfcb231b7b67eb0899a3133516f33c8) |
Jeffrey Altman <jaltman@auristor.com> | no | 2021-01-14 | ||
| 0014-Remove-overflow-check-from-update_nextCid.patch | Remove overflow check from update_nextCid The rx_nextCid global has been an unsigned type since http://gerrit.openafs.org/11106 (which was actually merged before the refactoring of overflow check to avoid signed integer overflow) and thus there is no need to avoid signed overflow. The per-connection cid has been unsigned since the IBM import. The natural unsigned behavior on overflow of wrapping is the desired behvaior here, so just remove the extra logic and always increment. |
Benjamin Kaduk <kaduk@mit.edu> | no | 2021-01-14 |