mirror of
https://git.openafs.org/openafs.git
synced 2025-01-31 05:27:44 +00:00
13472 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Michael Meffie
|
088a77b99b |
build: package ltmain.sh in the libafs_tree
Commit 0a58d2188[1] "cf: Run AFS_LT_INIT after setting CC" moved the location of LT_INIT (libtool initialization) to a common macro, so it is now expanded in configure-libafs. This breaks the linux DKMS packaging, which uses configure-libafs to build the kernel module, since the ltmain.sh aux file is not included in the dkms package. For now, just include the ltmain.sh aux file in the libafs_tree files to fix DKMS build. Later, we should restructure the autoconf macros so the LT_INIT macro is not expanded in the configure-libafs configure script, since we do not need libtool to build the kernel module. Thanks to Alex T Prengel for reporting this issue on the openafs-info mail list. 1) 0a58d21881d7e91deccb416e8d2c272e14b412dd cf: Run AFS_LT_INIT after setting CC Reviewed-on: https://gerrit.openafs.org/15076 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 76f26c63c7fe9661dfcf267cf75638747c81b7ef) Change-Id: I595811dec056b8ec4a7cf36f6f96532a1e452e4e Reviewed-on: https://gerrit.openafs.org/15542 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Indira Sawant <indira.sawant@ibm.com> Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Cheyenne Wills
|
1d5b5244a6 |
afs: Use literal NULL for NULL function pointer
The clang compiler complains that this function pointer cast is not a
prototype.
.../osi_file.c:141:27: error: this function declaration is not a
prototype [-Werror,-Wstrict-prototypes]
afile->proc = (int (*)())0;
^
void
Just use NULL instead of trying to create a cast to 0.
Reviewed-on: https://gerrit.openafs.org/14902
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 689fb56fca57274e73c8394e8588650449565cd8)
Change-Id: I61cf49178a80d011b0169a729c3a08e9829cddad
Reviewed-on: https://gerrit.openafs.org/15541
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Indira Sawant <indira.sawant@ibm.com>
Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
d50ced2a17 |
cf: Avoid nested C functions built by autoconf
Currently, two of the Linux-related autoconf macros try to compile code
containing nested C functions (AC_CHECK_LINUX_OPERATION and
LINUX_KMEM_CACHE_CREATE_CTOR_TAKES_VOID). For example, the
AC_CHECK_LINUX_OPERATION check for 'follow_link' generates this code
where 'op' is a nested function inside 'conftest':
#include <linux/module.h>
#include <linux/fs.h>
void conftest(void)
{
struct inode_operations ops;
const char *op(struct dentry *dentry, void **link_date) {
return (const char *)0;
};
ops.follow_link = op;
}
Nested functions are a gcc-specific feature, and are not supported by
other compilers (e.g. clang), causing these checks to always fail when
using clang, leading to incorrect configure results.
To fix this, change AC_CHECK_LINUX_OPERATION and
LINUX_KMEM_CACHE_CREATE_CTOR_TAKES_VOID macros to just define the
relevant function as a proper top-level function.
(these were discovered by forcing a clang build of both the Linux kernel
and the openafs kernel module)
Reviewed-on: https://gerrit.openafs.org/14901
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a4878a5e26b9997e40a3b197cea5f8c3b24f2539)
Change-Id: Ie186658167a3f9e162fe85722aa0792cbe4fcfda
Reviewed-on: https://gerrit.openafs.org/15540
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
f900670194 |
ukernel: Fix AFS_GUNLOCK panic in rx_ServerProc
At the beginning of UKERNEL's rx_ServerProc a call to AFS_GUNLOCK panics with 'afs global lock not held'. The commit 'afs: Drop GLOCK for various Rx calls' (d5e1428a3b) altered afs_RXCallBackServer so the global lock is released prior to calling rx_ServerProc, and to reacquire the lock after rx_ServerProc returns. Remove the AFS_GUNLOCK at the start and the AFS_GLOCK at the end of UKERNEL's rx_ServerProc. Reviewed-on: https://gerrit.openafs.org/14963 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 07076d63edfb9fe7a2311958e9410d5eadb227d9) Change-Id: If7b0b755e693cb5d892d3300c47fbbdaf76f2f59 Reviewed-on: https://gerrit.openafs.org/15539 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Michael Meffie
|
e5d871ab40 |
vlserver: Use bounded string copy in FindByName()
Although the volname string passed to FindByName() is currently always limited 65 characters (including the terminating nul), to be on the safe side, use the bounded strlcpy() function when coping the volname to the temporary tname local variable to avoid the possibility of overwriting the stack with an unbounded strcpy(). Reviewed-on: https://gerrit.openafs.org/14763 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 494ec08cd04da6f96be02c7dc22d9bb0c409d63b) Change-Id: I87b225de7d4ce81a4017f47f2d5088ebffd7c66a Reviewed-on: https://gerrit.openafs.org/15538 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Michael Meffie
|
883a1a27e6 |
bozo: Log a warning if the bosserver is not started in restricted mode
Log a warning to the BosLog when the bosserver is not started in restricted mode to encourage admins to enable restricted mode. Also, log a notice when restricted mode is enabled to reassure admins restricted mode is enabled on start up. Reviewed-on: https://gerrit.openafs.org/14762 Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit d91b92e308dc2ac2e489581839c1fc1bf9147e16) Change-Id: Id35b089855797541bbc2f59982b3da7b4fab824e Reviewed-on: https://gerrit.openafs.org/15537 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Andrew Deason
|
92ba67d5a6 |
afs: Let afs_ShakeLooseVCaches run longer
Currently, when afs_ShakeLooseVCaches runs osi_TryEvictVCache, we check if osi_TryEvictVCache slept (i.e. dropped afs_xvcache/GLOCK). If we sleep over 100 times, then we stop trying to evict vcaches and return. If we have recently accessed a lot of AFS files, this limitation can severely reduce our ability to keep our number of vcaches limited to a reasonable size. For example: Say a Linux client runs a process that quickly accesses 1 million files (a simple 'find' command) and then does nothing else. A few minutes later, afs_ShakeLooseVCaches is run, but since all of the newly accessed vcaches have dentries attached to them, we will sleep on each one in order to try to prune the attached dentries. This means that afs_ShakeLooseVCaches will evict 100 vcaches, and then return, leaving us with still almost 1 million vcaches. This will happen repeatedly until afs_ShakeLooseVCaches finally works its way through all of the vcaches (which takes quite a while, if we only clear 100 at once), or the dentries get pruned by other means (such as, if Linux evicts them due to memory pressure). The limit of 100 sleeps was originally added in commit 29277d96 (newvcache-dont-spin-20060128), but the current effect of it was largely introduced in commit 9be76c0d (Refactor afs_NewVCache). It exists to ensure that afs_ShakeLooseVCaches doesn't take forever to run, but the limit of 100 sleeps may seem quite low, especially if those 100 sleeps run very quickly. To avoid the situation described above, instead of limiting afs_ShakeLooseVCaches based on a fixed number of sleeps, limit it based on how long we've been running, and set an arbitrary limit of roughly 3 seconds. Only check how long we've been running after 100 sleeps like before, so we're not constantly checking the time while running. Log a new warning if we exit afs_ShakeLooseVCaches prematurely if we've been running for too long, to help indicate what is going on. Reviewed-on: https://gerrit.openafs.org/14254 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit cd65475e95e25c8e7071e099a682bdcc03d2cce1) Change-Id: I6c8e440a3c4dec5e6d769f40d9638a3edc6ad333 Reviewed-on: https://gerrit.openafs.org/15536 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
ee32460bf2 |
afs: Fix EIO error when reading a 4G or larger file
When reading a file with a file length of >= 4G, the cache manager is failing the read with an EIO error. In afs_GetDCache, the call to IsDCacheSizeOK is passed a parameter that contains only the lower 32bits of the file length (which requires a 64 bit value). This results in the EIO error if the length is over 2^32 -1. The AFSFetchStatus.Length member needs to be combined with the AFSFetchStatus.Length_hi to obtain the full 64bit file length. Fix the calls to IsDCacheSizeOK to use the full 64bit file length. Commit "afs: Check dcache size when checking DVs 7c60a0fba11dd24494a5f383df8bea5fdbabbdd7" - gerrit 13436 - added the IsDCacheSizeOK function and the associated calls. As a note, the AFSFetchStatus.DataVersion is the lower 32 bits of the full 64bit version number, AFSFetchStatus.dataVersionHigh contains the high order 32bits. The function IsDCacheSizeOK is passed just the 32bit component, the only use of the parameter is in an error message. Reviewed-on: https://gerrit.openafs.org/14002 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit bebae936b4ef3bf47624c0ff0baae5521bad804e) Change-Id: I68f3ee04af25c7e99e0795804226ba5075af0ea8 Reviewed-on: https://gerrit.openafs.org/15535 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
652211e8d0 |
afs: Skip IsDCacheSizeOK for CDirty/VDIR
IsDCacheSizeOK currently can incorrectly flag a dcache as corrupted, since the size of a dcache may not match the size of the underlying file in a couple of RW conditions: - If someone is writing to a file beyond EOF, the intermediate 'sparse' area may be populated by 0-length dcaches until the data is written to the fileserver. - Directories may be modified locally instead of being fetched from the fileserver, which can sometimes result in a directory blob of differing sizes. To avoid false positives detecting dcache corruption, just skip the IsDCacheSizeOK check for directories, and any file with pending writes (CDirty). Also add some extra information to the logging messages when this "corruption" is detected, so false positives may be more easily detected in the future. Reviewed-on: https://gerrit.openafs.org/13747 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit e6b97b337bc97fdb1c8e4f1a0572c62dfc82d979) Change-Id: I177020c37ba92d8730fe4c68ca610f1b39c3d69b Reviewed-on: https://gerrit.openafs.org/15533 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
b46d63252b |
afs: Check dcache size when checking DVs
Currently, if the dcache for a file has nonsensical length (due to cache corruption or other bugs), we never notice, and we serve obviously bad data to applications. For example, the vcache metadata for a file may say the file is 2k bytes long, but the dcache for that file only has 1k bytes in it (or more commonly, 0 bytes). This situation is easily detectable, since the dcache and vcache refer to the same version of the same file (when the DVs match), and so we can check if the two lengths make sense together. So to avoid giving bad data to userspace applications, perform a sanity check on the lengths at the same time we check for DV matches (to see if the dcache looks "fresh" and not stale). If the lengths do not make sense together, we just pretend that the dcache is old, and so we'll ignore it and fetch a new copy from the fileserver. Also check the size of the data fetched from the fileserver for a newly-fetched dcache in afs_GetDCache, to avoid returning a bad dcache if the dcache isn't already present in the cache. Reviewed-on: https://gerrit.openafs.org/13436 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit 7c60a0fba11dd24494a5f383df8bea5fdbabbdd7) Change-Id: I197d197f3f2eaf0473c76c60c9df842a3bed934a Reviewed-on: https://gerrit.openafs.org/15532 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Marcio Barbosa
|
b7ac4842a1 |
volser: warn if older version of volume is restored
Volume restores work by overwriting vnodes with the data in the given volume dump. If we restore a partial incremental dump from an older version of the volume, this generally results in a partly-corrupted volume, since directory vnodes may contain references that don't exist in the current version of the volume (or are supposed to be in a different directory). Currently, the volserver does not prevent restoring older volume data to a volume, and this doesn't necessarily always result in corrupted data (for instance, if we are restoring a full volume dump over an existing volume). But restoring old volume data seems more likely to be a mistake, since reverting a volume back to an old version, even without corrupting data, is a strange thing to do and may cause problems with our methods of cache consistency. So, log a warning when this happens, so if this is a mistake, it doesn't happen silently. But we still do not prevent this action, since it's possible something could be doing this intentionally. We detect this just by checking if the updateDate in the given header is older than the current updateDate for the volume on disk. Note: Restoring a full dump file (-overwrite f) will not result in corrupted data. In this scenario, the restore operation removes the volume on disk first (if present). After that, the dump file is restored. In this case, we do not log anything (the volume is not corrupted). Reviewed-on: https://gerrit.openafs.org/13251 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 8375a7f7dd0e3bcbf928a23f874d1a15a952cdef) Change-Id: Ic119b0a7b1eac5e01fabbadc0aa679d5f2617d53 Reviewed-on: https://gerrit.openafs.org/15531 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Indira Sawant <indira.sawant@ibm.com> Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
538f450033 |
hcrypto: rename abort to _afscrypto_abort
The Linux 6.5 commit:
panic: make function declarations visible (d9cdb43189)
added a declaration for abort into panic.h.
When building the Linux kernel module, the build fails with the
following:
src/crypto/hcrypto/kernel/config.h:95:20: error: static declaration of
‘abort’ follows non-static declaration
95 | static_inline void abort(void) {osi_Panic("hckernel aborting\n"
);}
| ^~~~~
...
from ./include/linux/wait.h:9,
from /openafs/src/afs/sysincludes.h:118,
from /openafs/src/crypto/hcrypto/kernel/config.h:30:
./include/linux/panic.h:36:6: note: previous declaration of ‘abort’
with type ‘void(void)’
36 | void abort(void);
| ^~~~~
Update the declaration in hcrypto/kernel/config.h to change the function
name from abort to _afscrypto_abort and use a preprocessor define to
map abort to _afscrypto_abort.
Reviewed-on: https://gerrit.openafs.org/15501
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c4c16890d9d2829f6bef1ef58feafb30b1d59da3)
Change-Id: I54cc9156b98320d04fe6f7bb595a150d5ba87b49
Reviewed-on: https://gerrit.openafs.org/15523
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
63801cfd1f |
Linux 6.5: Use register_sysctl()
The linux 6.5 commit:
"sysctl: Remove register_sysctl_table" (b8cbc0855a)
removed the Linux function register_sysctl_table(). The replacement
function is register_sysctl(), which offers a simpler interface.
Add an autoconf test for the Linux function register_sysctl and add a
call to register_sysctl when available.
Notes:
The Linux function register_sysctl was added in Linux 3.3 with the
commit:
'sysctl: Add register_sysctl for normal sysctl users' (fea478d410)
with a note that it is a simpler interface.
The function register_sysctl_table was marked as deprecated with the
Linux 6.3 commit:
'proc_sysctl: enhance documentation' (1dc8689e4c)
Reviewed-on: https://gerrit.openafs.org/15500
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fb31d299e6caa015f6288ba9186da6277d3d6a8d)
Change-Id: I60f68f1dd95c32bada7179e98250fd44d7c2ddf3
Reviewed-on: https://gerrit.openafs.org/15522
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Andrew Deason
|
d15c7ab50c |
LINUX: Make sysctl definitions more concise
Our sysctl definitions are quite verbose, and adding new ones involves copying a bunch of lines. Make these a little easier to specify, by defining some new preprocessor macros. Reviewed-on: https://gerrit.openafs.org/13700 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 1b0bb8a7fcbd69d513ed30bb76fd0693d1bd3319) Change-Id: Ib656634ed956b845c89656069aa297253acce785 Reviewed-on: https://gerrit.openafs.org/15521 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
fef2457693 |
Linux 6.5: Replace generic_file_splice_read
The Linux 6.5 commit:
'splice: Remove generic_file_splice_read()' (c6585011bc)
replaces the function generic_file_splice_read() with the function
filemap_splice_read().
The Linux function 'filemap_splice_read()' was introduced with the
Linux 6.3 commits:
'splice: Add a func to do a splice from a buffered file without
ITER_PIPE' (07073eb01c)
'splice: Export filemap/direct_splice_read()' (7c8e01ebf2)
With updates in Linux 6.5:
'splice: Fix filemap_splice_read() to use the correct inode'
(c37222082f) -- which fixes a problem in the code.
'splice: Make filemap_splice_read() check s_maxbytes' (83aeff881e)
Due to the fact that there could be problems with splice support prior
to Linux 6.5 (where filemap_splice_read()'s use was expanded to
additional filesystems other than just cifs), we only want to use
'filemap_splice_read()' in Linux 6.5 and later.
The LINUX/osi_vnodeops.c file is updated to use 'filemap_splice_read()',
for Linux 6.5 and later, for the splice_read member of the
file_operations structure.
Reviewed-on: https://gerrit.openafs.org/15486
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0e06eb78f293bb295b0fe12da24abd8dc1160149)
Change-Id: I3b5436234d275253a37987dc40a522ae8f3cae1e
Reviewed-on: https://gerrit.openafs.org/15520
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Andrew Deason
|
be21a20419 |
UKERNEL: Build linktest with COMMON_CFLAGS
Currently, 'linktest' in libuafs is built with a weird custom rule
that specifies several various CFLAGS and LDFLAGS, etc. One
side-effect of this is that linktest is built without specifying -O,
even if optimization is otherwise enabled.
Normally nobody would care about the optimization of linktest, since
it's never supposed to be run, but this can cause an error when
building with -D_FORTIFY_SOURCE=1 on some systems (such as RHEL7):
In file included from /usr/include/sys/types.h:25:0,
from /.../src/config/afsconfig.h:1485,
from /.../src/libuafs/linktest.c:15:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^
cc1: all warnings being treated as errors
make[3]: *** [linktest] Error 1
For now, to fix this just include $(COMMON_CFLAGS) in the flags we
give for linktest, so $(OPTMZ) also gets pulled in, and building
linktest gets a little closer to a normal compilation step.
Reviewed-on: https://gerrit.openafs.org/14324
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c4f853aa00f1650b678cbd22ad1e2a9cf01c1303)
Change-Id: I842fc630979fa98950f09326a556da1f7d1cd23b
Reviewed-on: https://gerrit.openafs.org/15519
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Andrew Deason
|
128772e328 |
cf: Undef _FORTIFY_SOURCE for use-after-free check
Commit f2003ed68c (gcc: Avoid false positive use-after-free in crypto)
added a configure check to detect whether the compiler we're using
exhibits the use-after-free warning bug. We add -O0 to CFLAGS for the
test to make sure the bug triggers for gcc 12, but if the user has
specified, for example, CFLAGS=-D_FORTIFY_SOURCE=1, this causes
the compile check to always fail:
/usr/include/features.h:330:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
This causes _OPENAFS_UAF_COMPILE_IFELSE to always fail, and so we
throw an AC_MSG_ERROR during configure.
To allow the build to continue with _FORTIFY_SOURCE, make sure
_FORTIFY_SOURCE is undefined for this specific test. The compile test
can then succeed with -O0 (unless we trigger the use-after-free bug,
of course).
Reviewed-on: https://gerrit.openafs.org/15499
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2e6b80e4bcdb476e95c8cff46ebaae69f092abec)
Change-Id: Ibafe136c2d0364741f0ea2e3d823e181d7983f20
Reviewed-on: https://gerrit.openafs.org/15518
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
Mark Vitale
|
03bc379df9 |
vol: Don't leak volume bitmaps
Since the original IBM code import, attach2 has set the volume's index bitmaps to NULL in preparation for allocating and initalizing new bitmaps. However, the volume may already have bitmaps from previous operations, and this is much more likely with DAFS. In this case, the old bitmaps are leaked. Instead, free any existing bitmap before allocating a new one. Discovered via Solaris libumem.so.1. Reviewed-on: https://gerrit.openafs.org/15428 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 4b42b07fde2cb87ecb0f3135612a4c086227fa09) Change-Id: I8d67a4ef75218acc6e5852b77b90e7898e78585e Reviewed-on: https://gerrit.openafs.org/15517 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Mark Vitale
|
3b383abaa9 |
rxkad: Free memory used to check rxkad response
Since its introduction with commit 7e4e06b87a09 "Derive DES/fcrypt session key from other key types", rxkad_derive_des_key has failed to free the memory associated with its HMAC context struct. This results in a leak of at least 352 bytes for each rxkad challenge response processed by an OpenAFS server when using rxkad-kdf. Free the memory by calling HMAC_CTX_cleanup after each round of the loop. Discovered via Solaris libumem.so.1. Reviewed-on: https://gerrit.openafs.org/15427 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 915c9ec007810f99a5ea8be73426fc8882f615fd) Change-Id: I4710c1180cdca19cc963d7409ef15e74efd51498 Reviewed-on: https://gerrit.openafs.org/15516 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
898098e01e |
LINUX: Make 'fs flush*' invalidate dentry
Our 'fs flush' and related commands (flushall, flushvolume) clear the
relevant entries in the OpenAFS stat cache and data cache, which can
fix problems if the cache ever becomes incorrect for any reason. (This
can happen after bugs, repairing corrupted volumes, disaster recovery
scenarios, and similar edge cases.)
However, on Linux, these commands don't affect the VFS dentry cache.
If someone needs to use an 'fs flush' command to fix a problem, this
will fix the OpenAFS cache, but the Linux dcache can still be wrong.
The only way to manually flush dcache entries is to use the global
'drop_caches' mechanism, which is a very heavweight operation, only
accessible to root.
For example:
$ ls -l
ls: cannot access foo.1: No such file or directory
total 2
drwxrwxr-x. 2 bin adeason 2048 Apr 6 14:20 dir
-?????????? ? ? ? ? ? foo.1
$ fs flush .
$ ls -l
ls: cannot access foo.1: No such file or directory
total 2
drwxrwxr-x. 2 bin adeason 2048 Apr 6 14:20 dir
-?????????? ? ? ? ? ? foo.1
$ sudo sysctl -q -w vm.drop_caches=3
$ ls -l
total 3
drwxrwxr-x. 2 bin adeason 2048 Apr 6 14:20 dir
-rw-rw-r--. 1 bin adeason 29 Sep 22 2022 foo.1
To make the 'fs flush' commands be effective in more situations,
change afs_ResetVCache() to also invalidate the dcache entries
associated with each vcache we reset. To make things simpler and
reduce locking complexity, do this by setting d_time to 0, and don't
directly run dcache-managing functions like d_invalidate or d_drop,
etc.
The above example now becomes:
$ ls -l
ls: cannot access foo.1: No such file or directory
total 2
drwxrwxr-x. 2 bin adeason 2048 Apr 6 14:20 dir
-?????????? ? ? ? ? ? foo.1
$ fs flush .
$ ls -l
total 3
drwxrwxr-x. 2 bin adeason 2048 Apr 6 14:20 dir
-rw-rw-r--. 1 bin adeason 29 Sep 22 2022 foo.1
Reviewed-on: https://gerrit.openafs.org/15391
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d460b616ebad763f7e480e194b2bffc28df99721)
Change-Id: I184046469c396b0421752d91c47477ebe8eaed13
Reviewed-on: https://gerrit.openafs.org/15515
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Michael Meffie
|
a50282c70f |
build: Add rpm target
Add a top-level makefile target to build RPMs for Red Hat distributions from the currently checked out commit. The resulting rpms are placed in the packages/rpmbuild/RPMS/<arch> directory. The rpm target is intended to be a convenience for testing changes to the rpm packaging or generating packages for local testing. Reviewed-on: https://gerrit.openafs.org/14114 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit 8b68f1a4e1e3ae06de0d6c5a8af60ef99cacb83a) Change-Id: I31fcd579d9610303cb44b4813ecaf8dd00e09e7e Reviewed-on: https://gerrit.openafs.org/15514 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Michael Meffie
|
f9db826205 |
makesrpm: Support custom version strings
The makesrpm.pl script generates a source RPM by creating a temporary rpmbuild workspace, populating the SOURCES and SPECS directories in that workspace, running rpmbuild to build the source RPM, and finally copying the resulting source RPM out of the temporary workspace. The name of the source RPM file created by rpmbuild depends on the package version and release strings. Unfortunately, the format of the source RPM file name changed around OpenAFS 1.6.0, so makesrpm.pl has special logic to find the version string and extra code depending on the detected OpenAFS version. Instead of trying to predict the name of the resulting source RPM file from the OpenAFS version string, and having different logic for old versions of OpenAFS, use a filename glob to find resulting source RPM file name in the temporary rpmbuild workspace. Remove the major, minor, and patch level variables, which were only used to guess the name of the resulting source RPM file name. Convert '-' characters to '_' in the package version and package release, since the '-' character is reserved by rpm as a field separator. While here, add the --dir option to specify the path of the generated source RPM, and change the 'srpm' makefile target to use the new --dir option, instead of changing the current directory before running makesrpm.pl. Also, add a dependency on the 'dist' makefile target, since the the source and document tarballs are required to build the source RPM. Add pod documentation and add the --help (-h) option to print a brief help message, and add the --man option to print the full man page. With this change, we can build a source RPM even when the .version file in the src.tar.bz file has a custom format or was created from a checkout of the master branch or other non-release reference. Reviewed-on: https://gerrit.openafs.org/14116 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 7cc6b97ad26089ecb88019468f3ef7c0222cebe1) Change-Id: I6f533aa4dff42c8e256fd7cf07831e0f6c0b0c63 Reviewed-on: https://gerrit.openafs.org/15513 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Michael Meffie
|
2899837875 |
bozo: Do not create client directory and symlinks
Each time the bosserver starts, it checks for the presence of the client configuration directory and the CellServDB and ThisCell files within it. When not found, the bosserver creates the client cell configuration directory. When the CellServDB and ThisCell files are not present in the client configuration directory, the bosserver creates symlinks to the server's CellServDB and ThisCell files. This feature of the bosserver was a convenience when older versions of vos and pts required a client configuration directory. However, modern deployments tend to use packaging, with separate client and server packages. The client configuration directory and files in it are typically managed by the client packaging. Currently, packagers must work around these symlinks created by the bosserver. Additionally, the CellServDB and ThisCell symlinks are hazardous since writing to the client-side configuration will overwrite the server configuration. This commit removes the creation the client configuration directory and the CellServDB and ThisCell symlinks during bosserver startup. This change is intended to decouple the server from the client, help to avoid overwriting the server configuration, and avoid requiring client artifacts on a server. Reviewed-on: https://gerrit.openafs.org/12586 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit c8aae4da4fcfd22c19fc9c8835960005554ac9d6) Change-Id: I76d24eadaecd19d21f12b8bd85eca2a4888d3e4c Reviewed-on: https://gerrit.openafs.org/15512 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Michael Meffie
|
c495c81754 |
Add command fallback to server config
Add an initialization retry in the bos, vos, and pts commands to fallback to the server configuration directory when initialization fails with the client configuration directory. This allows admins to run unauthenticated bos, vos, and pts commands on servers without a client configuration (including symlinks created by the bosserver) without any extra command line options. Perform the initialization retry only when the -localauth or -config options are not given. The bos, vos, and pts commands already use the server configuration path when the -localauth option is given, so there is no point in retrying the same path. The vos and pts -config option specifies the path to be used, so we do not fallback to a different directory when the user specifies the configuration path to be used. While here, change the scope of the confdir variable in vos.c from a global to a local variable, since it is only used within the MyBeforeProc() function. This change does not add a vsu_ClientInit() retry in the bos salvage command. That command always requires authorization, so when run without -localauth requires a token (and therefore a cache manager and client cell configuration). Update the bos, vos, and pts man pages to describe this new fallback method to lookup the configuration directory. (The AFSCONF environment variable and .AFSCONF files are currently undocumented in the man pages. They should be documented or removed from the code in a future change.) Reviewed-on: https://gerrit.openafs.org/15351 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 77eb1728331e0825ecb6fbe29db334c61b5276d0) Conflicts: (1.8.x does not have rxgk support) src/ptserver/pts.c src/volser/vos.c Change-Id: I1e0ffb8a074098ed6d4750d8e02cbfb8c0dbaff5 Reviewed-on: https://gerrit.openafs.org/15511 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
c77491e189 |
pts: Use cmd_AddParmAtOffset for common parms
Update pts to use cmd_AddParmAtOffset and symbolic constants for our common parameters, instead of using bare literals like '16'. Reviewed-on: https://gerrit.openafs.org/13946 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit d0941e81b2f1f499cebb57d8a81d82802913d9be) Conflicts: (1.8.x does not have rxgk support) src/ptserver/pts.c Change-Id: I0bc2c6038c0d7983c6364ec186aef18105b02d3a Reviewed-on: https://gerrit.openafs.org/15510 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
d80485cd95 |
viced: Verify primary host address
Currently, h_stateVerifyHost verifies that all of the valid entries on h->z.interface are on the host address hashtable. If we don't have a h->z.interface, we check the primary address h->z.host/h->z.port instead. But if we do have a h->z.interface, we don't check h->z.host/h->z.port at all. Normally, the primary address should always be included in the h->z.interface list (in a 'valid==1' entry), and so checking the primary address is redundant. However, currently it is possible in some edge cases for the primary address to be missing from the hashtable and to not be listed as a valid address in h->z.interface. In such cases, we don't flag an error or even log a warning, since we don't check the primary address separately. (These cases are bugs, and will be addressed in future commits.) To detect this case, change h_stateVerifyHost to always check h->z.host, just like we do for the entries in h->z.interface. Reviewed-on: https://gerrit.openafs.org/15070 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 9d144491d94e7e19e2d710601a37045ef1ef1fdc) Change-Id: Icdd65c081372e1057df67401643973e1ac6f016e Reviewed-on: https://gerrit.openafs.org/15509 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
6fc1d81eb7 |
gcc: Avoid false positive use-after-free in crypto
Due to a bug in gcc-12 and gcc-13, several warnings are generated for a
use-after-free in crypto.c, which leads to a build failure with
--enable-checking:
src/external/heimdal/krb5/crypto.c:1157:9: error: pointer ‘p’ may be
used after ‘realloc’ [-Werror=use-after-free]
1157 | free(p);
| ^~~~~~~
src/external/heimdal/krb5/crypto.c:1155:20: note: call to ‘realloc’
here
1155 | result->data = realloc(p, sz);
| ^~~~~~~~~~~~~~
However, reviewing the code around these warnings shows that the
use-after-free warnings are incorrectly generated (false positive). The
documentation for realloc states that realloc will return a NULL and not
alter the storage passed if there was an error allocating and the size
passed is non-zero.
There is a possible work-around for the false positive. One can use a
variable that is not a member of a structure to hold and test the value
returned from realloc, then update the structure member from that
variable.
However, the code that is producing the message is in a heimdal external
file, so we cannot modify the source. So just use the compiler flag
-Wno-use-after-free to avoid the warning/error.
Update configure to add tests for the -Wno-use-after-free flag, update
the Makefile to add the flag for CFLAGS.crypto.lo, and update CODING
for the new exception.
Because this is an important check, only disable the warning if the
compiler exhibits this specific bug. We do this by adding specific
configure tests for the compiler bug and conditionally set a CFLAG
variable if the bug is present.
NOTE: The false positive and work-around can be demonstrated with the
following code using gcc-12 (with -O0) or gcc-13 (not sensitive to the
optimization level):
somestruct->somepointer = realloc(ptr, somesize);
if (somestruct->somepointer == NULL && somesize != 0) {
free(ptr); << gets flagged as use-after-free
handle enomem...
}
However the following doesn't get flagged:
char *tmpptr = realloc(ptr, somesize);
if (tmpptr == NULL && somesize != 0) {
free(ptr);
handle enomem...
}
somestruct->somepointer = tmpptr;
The GCC ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110501
has been marked as confirmed.
Reviewed-on: https://gerrit.openafs.org/15471
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit f2003ed68c2fecf679d0b04146427258d39369ea)
Change-Id: Ib7ae86c66f0ef1fc12d4ff4b796b712dc97e2e13
Reviewed-on: https://gerrit.openafs.org/15508
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
6867a3e842 |
cf: Fix cast-function-type err w/disable-checking
If the Linux kernel has CONFIG_WERROR enabled, and openafs is configured
with --disable-checking, the libafs kernel module fails to build:
/src/libafs/MODLOAD-5.14.0-305.el9.x86_64-MP/evp.c:501:9:
error: cast between incompatible function types from
‘void (*)(void *)’ to ‘int (*)(EVP_MD_CTX *)’ {aka
‘int (*)(struct hc_EVP_MD_CTX *)’} [-Werror=cast-function-type]
501 | (hc_evp_md_init)null_Init,
| ^
The openafs commit:
Linux-5.17: Kernel build uses -Wcast-function-type (6bdfa97673)
fixed above error when the Linux kernel has CONFIG_WERROR enabled and
openafs is configured with --enable-checking. But we will still fail
when CONFIG_WERROR is enabled and openafs is configured with
--disable-checking (which is the default).
Update osconf.m4 to always set CFLAGS_NOCAST_FUNCTION_TYPE, so that it
can be used to avoid the above compiler check even when checking is
disabled.
NOTE: The only use of CFLAGS_NOCAST_FUNCTION_TYPE is to correct the
warnings flagged in external/heimdal/hcrypto/evp.c and evp-algs.c.
NOTE: --enable-checking=all can be used to bypass setting the define.
Reviewed-on: https://gerrit.openafs.org/15417
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
(cherry picked from commit 2357ac6ae59ad1908b14b5e76e5931c7071ee9a2)
Change-Id: I96ccf89a7316449a0492d08dbfc0e625e143d933
Reviewed-on: https://gerrit.openafs.org/15507
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
Kailas Zadbuke
|
bb1b7b1adc |
afs: Check UHasTokens in afs_GCUserData
It looks that EndTimestamp holds the user’s token expiration time even after function afs_MarkUserExpired() gets called from afs_pag_destroy(). So it seems that the PAGs/tokens are not being reclaimed. This will lead to pag buildup on the system. The PAG/'struct unixuser' is not being freed because afs_GCUserData() checks afs_HasUsableTokens(), which checks EndTimestamp, which says the tokens still haven't expired. So the PAG doesn't get freed. This behavior has existed since commit ba1d050c6e (Make unixuser's vid advisory). To fix this, change afs_GCuserData() to check for the UHasTokens flag, and ignore any tokens if UHasTokens isn't set. This causes the PAG to be freed, since we don't look at the EndTimestamp of the tokens at all. Thanks Todd DeSantis for your support. Signed-off-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-on: https://gerrit.openafs.org/15404 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 630d423897e5fffed1873aa9d12c4e74a8481041) Change-Id: I74b1ea1173df904928ad027e48b231058c1e0f1d Reviewed-on: https://gerrit.openafs.org/15506 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Stephan Wiesand
|
a0b7f71122 |
Make OpenAFS 1.8.10
Update version strings for the 1.8.10 release, and add the finishing touch to NEWS. Change-Id: I5ade3bf8eb05474c5e4344e7c727545e807a0053 Reviewed-on: https://gerrit.openafs.org/15490 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>openafs-stable-1_8_10 |
||
|
Stephan Wiesand
|
a48dc74d79 |
Make OpenAFS 1.8.10pre1
Update version strings for the first 1.8.10 prerelease. Change-Id: I116eb9852e7799540fea4cd439f513d571231f45 Reviewed-on: https://gerrit.openafs.org/15282 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>openafs-stable-1_8_10pre1 |
||
|
Stephan Wiesand
|
30e8312664 |
Update NEWS for 1.8.10pre1
Release notes for the first 1.8.10 prerelease. Change-Id: Ie7ed1b65444239528edcb4861ad3e99af54c4bbb Reviewed-on: https://gerrit.openafs.org/15440 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
abeed74bb0 |
LINUX: Set .getattr for symlinks
On Linux, we can define a .getattr callback for files and directories,
which is called when a caller requests metadata for the file, such as
during lstat(). For regular files and directories, we set this to
afs_linux_getattr(), which updates the metadata for the file in
question if it's out of date (CStatd not set).
For symlinks, however, we don't set .getattr at all. This would seem
to allow symlink metadata to become stale if another client changes
it, but the metadata often happens to stay up to date via other means.
For example, we can see the following happen:
- Another client changes, for example, the owner of a symlink we have
cached.
- The fileserver sends us a callback break, and so we clear CStatd for
the vcache for the symlink.
- lstat() is called for the symlink, which causes
afs_linux_dentry_revalidate() to be called for the cached dentry.
Since CStatd is not set for the vcache, we verify the entry by
calling afs_lookup(), and then update the symlink's metadata via
afs_getattr() and vattr2inode().
However, if CStatd _is_ set for the symlink when lstat() is called,
afs_linux_dentry_revalidate() will not update anything, and will just
return success. So, if we manage to set CStatd for the symlink without
updating it's Linux VFS metadata, the Linux metadata won't be updated,
and we'll report the old metadata to the caller of lstat().
We can set CStatd without updating the Linux VFS info in a few
different ways. A few pioctls such as PRemoveMount or PFlushMount can
do this if they encounter an error, but the only code paths that call
these pioctls in OpenAFS (via the 'fs' utility) also lstat() the
relevant path, so this doesn't happen in practice.
A more common way that this can occur is via afs_DoBulkStat(). If
userspace triggers a bulkstat that includes the symlink in question,
the symlink would gain the CStatd flag without any interaction with
the Linux VFS.
For example, say a symlink was chown'd from 'adeason' to 'root'. On
another client with the symlink cached, running 'ls -l' on the symlink
itself would show the updated owner, because
afs_linux_dentry_revalidate() updates the metadata:
$ ls -l dir.slink
lrwxr-xr-x. 1 root root 3 May 5 14:48 dir.slink -> dir
But if we 'ls -l' the entire directory, which contains other entries,
we will bulkstat many of the entries, possibly including the symlink.
And so we may see the old metadata:
$ ls -l
total 9
[...]
lrwxr-xr-x. 1 adeason root 3 May 5 14:48 dir.slink -> dir
Triggering this behavior requires a bulkstat to be triggered before we
access the symlink itself, and so triggering this behavior depends on
the order of the entries in the directory as well as whether the other
items in the dir are cached. As such, triggering this behavior during
normal operation tends to be inconsistent and confusing.
The only lstat() info for symlinks that can change like this is the
owner, group, and modtime; mode bits cannot change, and neither can
the length/size (or the contents in general). So, stale metadata tends
to not be very noticeable.
To fix all of this, set .getattr to afs_linux_getattr() for symlinks,
just like we do for regular files and directories. This ensures that
we will update the Linux VFS metadata for the symlink when it is
requested, so we won't return stale metadata to callers.
This behavior appears to have existed for symlinks on Linux for quite
a while, possibly since our Linux 2.6 support was added. The behavoir
may have been introduced around commit b860b359d58
(initial-linux24-support-20001105) or commit 00543744955
(linux22-fix-20040405). Before those commits, we defined a .revalidate
callback for symlinks, which was called on older Linux versions before
fetching file metadata, and so probably ensured that an lstat() on a
symlink returned properly updated info.
Reviewed-on: https://gerrit.openafs.org/15423
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2b32b130f534068251ce9fd1b621de6e480d56d7)
Change-Id: I194308e2a4783cc3205c6cfd54880421635f6b38
Reviewed-on: https://gerrit.openafs.org/15443
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Andrew Deason
|
4394a3ee84 |
Retire AFS_MOUNT_AFS
Currently, the AFS_MOUNT_AFS #define is used to mean two completely different things: - The string "afs", corresponding to the first argument to mount(2) on many platforms and some related calls inside libafs (e.g. getnewvnode() on FBSD). - An integer identifying the AFS filesystem (e.g. gfsadd() on AIX). Depending on the platform and the build context (UKERNEL vs KERNEL), AFS_MOUNT_AFS gets defined to one of those two things. This is very confusing, and has led to mistakes in the past, such as those fixed in commit 446457a1 (afs: Set AFS_VFSFSID to a numerical value). To avoid such confusion, get rid of AFS_MOUNT_AFS completely, and replace it with two new symbols: - AFS_MOUNT_STR, the string "afs". - AFS_FSNO, the integer given to gfsadd() et al. When AFS_MOUNT_AFS is split this way, AFS_MOUNT_STR then is always defined to the same value, so remove it from the param.h files for our platforms. Instead, define it in afs.h for libafs use, and in afsd_kernel.c (the only place outside of src/afs that uses it). Also remove the logic for conditionally defining MOUNT_AFS from the param.h files, moving the logic to the same locations as AFS_MOUNT_STR. Note that this commit removes the numeric definition for AFS_MOUNT_AFS in param.sgi_65.h (aka AFS_FSNO). We never actually used this value, since AFS_FSNO is not used on IRIX; instead, we tend to use the 'afs_fstype' global instead of a constant number. Reviewed-on: https://gerrit.openafs.org/14323 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 6b96a49eb6268adf9fc7e077fe849af7802a1575) Change-Id: Iebb35b323ceb50f9603387c46168b80ec800735d Reviewed-on: https://gerrit.openafs.org/15422 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Tested-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Benjamin Kaduk
|
ee6944d96d |
rxevent: fix mismatched #endif
We should only assign to 'ev' once, rather than assigning a second time to an uninitialized value. Reported by Ben Huntsman and diagnosed by Jeffrey Altman. Reviewed-on: https://gerrit.openafs.org/15106 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit e51ed7be3849025e9b47d1a644a4fcd99b774b30) Change-Id: I06ac2155170d8f005afd9551c69d5ef3e60afff3 Reviewed-on: https://gerrit.openafs.org/15442 Reviewed-by: Ben Huntsman <ben@huntsmans.net> Tested-by: Ben Huntsman <ben@huntsmans.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
e4e9122365 |
opr: Avoid sigwait on SIGWAITING
On AIX, calling sigwait() on a sigset containing SIGWAITING (or SIGKILL or SIGSTOP), causes sigwait to return with an EINVAL error. Currently, signalHandler() calls sigwait() with SIGWAITING, because SIGWAITING is in the sigset returned by softsigSignalSet(). And so, sigwait() returns EINVAL, and our opr_Verify in signalHandler() fails, causing a crash. To avoid this, remove SIGWAITING from the sigset in softsigSignalSet(). This is AIX-specific, since the SIGWAITING signal is AIX-specific. Reviewed-on: https://gerrit.openafs.org/14705 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit c2db41258370159c1257ee79df10afa4a2a2d9e8) Change-Id: I433e4842b684c5f0f453e20d2f5d455b10a792eb Reviewed-on: https://gerrit.openafs.org/15441 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
Ben Huntsman
|
332b5593d4 |
AIX: Free pinned_heap during shutdown to prevent kernel panic
During shutdown, the function shutdown_osisleep is called in
src/afs/afs_osi.c. The body of this function is platform-
specific, and on AIX there is a call to xmfree:
xmfree(tmp);
However, on AIX, xmfree actually takes two arguments:
int xmfree ( ptr, heap)
caddr_t ptr;
caddr_t heap;
This is called elsewhere in the OpenAFS code correctly for
kernel_heap. In src/afs/AIX/osi_sleep.c we start using the
pinned_heap, but never xmfree it. Therefore, we need to do so here
during the shutdown. Here we include a header file which defines
pinned_heap, and then supply it as an argument to xmfree. This
prevents a kernel panic during OS shutdown.
The panic might go unnoticed in many environments, as during a
reboot, the system will normally dump and restart anyway. However,
if kdb is loaded (bosboot -a -D), the system will break into the
debugger before the full shutdown procedure completes. The stack
trace shows the following:
KDB(0)> stack
pvthread+01D200 STACK:
[00023900]abend_trap+000000 ()
[000EFF24]xmfree_frontend+0000A4 (??, ??, ??)
[F1000000C064CF1C]shutdown_osisleep@AF72_5+0000BC (??)
[F1000000C064CB7C]shutdown_osi+00001C ()
[F1000000C064A51C]afs_shutdown+0003BC (0000000100000001)
[F1000000C05A8DD4]afs_unmount+000094 (F1000A01501D4C10, 0000000000000000)
[F1000000C059FCE0]vfs_unmount+0000A0 (F1000A01501D4C10, 0000000000000000,
F1000A015047B07C)
[00014D70].hkey_legacy_gate+00004C ()
[006A6AAC]vfs_unmount+00008C (??, ??, ??)
[006B4228]kunmount+000228 (??, ??, ??, ??)
[006B4944]uvmount+000204 (??, ??)
[00003954]syscall+00024C ()
[100084FC]helper_UMfunc+00027C (??, ??)
[10003D48]dounmount+0000C8 (??, ??, ??, ??)
[100044DC]umountmain+0001BC (??, ??)
[10000AD4]main+0000B4 (??, ??)
[10000168]__start+000068 ()
Reviewed-on: https://gerrit.openafs.org/15419
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4810cca10bc32df7ba7809fc2bf095d20e2febd8)
Change-Id: I687caa6daae83fc7986e76d370b55f90f5ca53cc
Reviewed-on: https://gerrit.openafs.org/15425
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Ben Huntsman
|
a2ab598bae |
AIX: AFS_SMALLOCSIZ too small on newer OS releases
Addresses a situation where a write in AFS space can cause a kernel
panic. In src/afs/afs_osi_uio.c in the function afsio_partialcopy:
size_t space_len = sizeof(struct uio) +
sizeof(struct iovec) * AFS_MAXIOVCNT;
/* Allocate a block that can contain both the UIO and the iovec */
space = osi_AllocSmallSpace(space_len);
On newer AIX systems (since at least 6.1), space_len is larger than
AFS_SMALLOCSIZ. When osi_AllocSmallSpace is called, the following
test in src/afs/afs_osi_alloc.c causes a kernel panic:
if (size > AFS_SMALLOCSIZ)
osi_Panic("osi_AllocSmallS: size=%d\n", (int)size);
This is due to the following definition in src/config/afs_args.h:
/*
* Note that the AFS_*ALLOCSIZ values should be multiples of sizeof(void*) to
* accomodate pointer alignment.
*/
/* Used in rx.c as well as afs directory. */
/* XXX Because of rxkad_cprivate... XXX */
All the supported AIX platforms define AFS_AIX32_ENV in
src/config/param.rs_aixXX.h, where XX is the AIX version. Therefore,
all the AIX platforms end up with AFS_SMALLOCSIZ = 152 bytes instead
of 256. To resolve this, we will modify the preprocessor test to use
the second case for AIX versions greater than 6.1. This issue may be
present on earlier releases of AIX as well, but AIX 5.3 and older
test systems were not available at this time.
Also, a spelling error in the comment was fixed.
Reviewed-on: https://gerrit.openafs.org/15418
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8a2d4faa73d0f2e03a4016d7f84c5d5437040cec)
Change-Id: I5a2fc4ad1a829f1ee30387da20ce477c84fa020f
Reviewed-on: https://gerrit.openafs.org/15424
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
af58c5cd15 |
Linux: Clear msghdr structure before use
The msghdr structure is used as a parameter to the Linux kernel functions kernel_sendmsg() and kernel_recvmsg(). Some required fields need to be set prior to calling these functions, but there are also additional structure members that may not be used by the calling code. Some of these fields may be initialized by the Linux kernel functions being used, but there may be some that are left uninitialized. To ensure that all fields in the msghdr structure are cleared, use memset to zero the entire structure. This will eliminate the need to set individual fields to 0 or NULL. Reviewed-on: https://gerrit.openafs.org/15409 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 795ef90d4041f1a5a1139435cc70f96457e0f64b) Change-Id: Id037e2e548c27b23e2746f804ddcaf7b79d905c4 Reviewed-on: https://gerrit.openafs.org/15411 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
12ce31ce1d |
Linux: Do not initialize msghdr's msg_iter/msg_iov
Since the initial Linux commit (2.6.12-rc2) the Linux function kernel_recvmsg() handles the initialization of the msghdr members related to the iov (msghdr.msg_iter and for earlier kernels msghdr.msg_iov and msghdr.msg_iovlen). The code in osi_NetReceive for Linux unnecessarily initializes these structure members prior to calling kernel_recvmsg(). Remove the unnecessary code from osi_NetReceive along with the surrounding preprocessor check for STRUCT_MSGHDR_HAS_MSG_ITER. Since this is the only location that uses this define, also remove the associated autoconf test. NOTE: This was discovered while investigating changes needed for Linux 6.4, due to: "iov_iter: add iter_iovec() helper" (de4f5fed3f) which renamed the Linux structure iter_iovec's member iov to __iov. Since the openafs code that was affected by the Linux 6.4 change is being removed as unnecessary, this commit is not Linux 6.4 specific, but effects all versions of Linux. Reviewed-on: https://gerrit.openafs.org/15408 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 5a7630acfd8bfd462b633475a6e195d9dbdfb451) Change-Id: I3a803f76ab84f1e055e91cf4f2be96440f141746 Reviewed-on: https://gerrit.openafs.org/15410 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
0967702c3f |
AIX: Fix undefined symbols
Various pieces of our code try to use symbols in our internal libraries that are not exported in the respective .sym file. On AIX, this causes the following build failures: ld: 0711-317 ERROR: Undefined symbol: .ubik_CallRock ld: 0711-317 ERROR: Undefined symbol: DISK_function_names ld: 0711-317 ERROR: Undefined symbol: VOTE_function_names ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[4]: *** [Makefile:45: afscp] Error 8 make[4]: Leaving directory '/.../src/libadmin/test' ld: 0711-317 ERROR: Undefined symbol: PR_function_names ld: 0711-317 ERROR: Undefined symbol: KAA_function_names ld: 0711-317 ERROR: Undefined symbol: KAT_function_names ld: 0711-317 ERROR: Undefined symbol: KAM_function_names ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[4]: *** [Makefile:117: rxstat_get_peer] Error 8 make[4]: Leaving directory '/.../src/libadmin/samples' ld: 0711-317 ERROR: Undefined symbol: .osi_audit_cmd_Options ld: 0711-317 ERROR: Undefined symbol: .osi_audit_open ld: 0711-317 ERROR: Undefined symbol: .afsconf_SuperIdentity ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:71: butc] Error 8 make[3]: Leaving directory '/.../src/tbutc' ld: 0711-317 ERROR: Undefined symbol: .pr_Initialize2 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:111: pts] Error 8 make[3]: Leaving directory '/.../src/tptserver' ld: 0711-317 ERROR: Undefined symbol: .AFSVolListPartitions ld: 0711-317 ERROR: Undefined symbol: .AFSVolXListPartitions ld: 0711-317 ERROR: Undefined symbol: .RXAFS_GetStatistics64 ld: 0711-317 ERROR: Undefined symbol: .AFSVolPartitionInfo64 ld: 0711-317 ERROR: Undefined symbol: .AFSVolPartitionInfo ld: 0711-317 ERROR: Undefined symbol: .RXAFS_GetStatistics ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:65: fsprobe_test] Error 8 make[3]: Leaving directory '/.../src/fsprobe' ld: 0711-317 ERROR: Undefined symbol: fsprobe_Results ld: 0711-317 ERROR: Undefined symbol: gtxframe_exitValue ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:45: scout] Error 8 make[3]: Leaving directory '/.../src/scout' ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_toString ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_freeString ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:50: check_sysid] Error 8 make[3]: Leaving directory '/.../src/viced' ld: 0711-317 ERROR: Undefined symbol: .GetLogLevel make[3]: *** [Makefile:130: fileserver] Error 8 make[3]: Leaving directory '/.../src/viced' ld: 0711-317 ERROR: Undefined symbol: .GetLogDest ld: 0711-317 ERROR: Undefined symbol: .GetLogFilename ld: 0711-317 ERROR: Undefined symbol: .CloseLog make[3]: *** [Makefile:166: salvageserver] Error 8 make[3]: Leaving directory '/.../src/tsalvaged' ld: 0711-317 ERROR: Undefined symbol: .rxkad_StringToLevel ld: 0711-317 ERROR: Undefined symbol: .FilepathNormalize ld: 0711-317 ERROR: Undefined symbol: .ConstructLocalPath ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:32: upserver] Error 8 make[3]: Leaving directory '/.../src/update' ld: 0711-317 ERROR: Undefined symbol: xstat_fs_Results ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:77: xstat_fs_test] Error 8 make[3]: Leaving directory '/.../src/xstat' ld: 0711-317 ERROR: Undefined symbol: .afsconf_DeleteKeyBySubType ld: 0711-317 ERROR: Undefined symbol: .afsconf_DeleteKeyByType ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[3]: *** [Makefile:35: asetkey] Error 8 make[3]: Leaving directory '/.../src/aklog' ld: 0711-317 ERROR: Undefined symbol: .afsconf_FindService ld: 0711-317 ERROR: Undefined symbol: .afsconf_AddKey ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetLatestKeyByTypes ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[4]: *** [Makefile:19: authcon-t] Error 8 make[4]: Leaving directory '/.../tests/auth' ld: 0711-317 ERROR: Undefined symbol: .afsconf_AddUser ld: 0711-317 ERROR: Undefined symbol: .afsconf_IsSuperIdentity ld: 0711-317 ERROR: Undefined symbol: .afsconf_AddIdentity ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetNthUser ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetNthIdentity ld: 0711-317 ERROR: Undefined symbol: .afsconf_DeleteUser ld: 0711-317 ERROR: Undefined symbol: .afsconf_DeleteIdentity ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[4]: *** [Makefile:25: superuser-t] Error 8 make[4]: Leaving directory '/.../tests/auth' ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetKeys ld: 0711-317 ERROR: Undefined symbol: .rx_opaque_new ld: 0711-317 ERROR: Undefined symbol: .rx_opaque_free ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetKeyByTypes ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetKeysByType ld: 0711-317 ERROR: Undefined symbol: .afsconf_PutTypedKeyList ld: 0711-317 ERROR: Undefined symbol: .afsconf_GetLatestKeysByType ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[4]: *** [Makefile:31: keys-t] Error 8 make[4]: Leaving directory '/.../tests/auth' ld: 0711-317 ERROR: Undefined symbol: ._afsconf_Touch ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[1]: *** [Makefile:34: realms-t] Error 8 make[1]: Leaving directory '/.../tests/auth' ld: 0711-317 ERROR: Undefined symbol: .opr_cache_get ld: 0711-317 ERROR: Undefined symbol: .opr_cache_put ld: 0711-317 ERROR: Undefined symbol: .opr_cache_init ld: 0711-317 ERROR: Undefined symbol: .opr_cache_free ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[1]: *** [Makefile:16: cache-t] Error 8 make[1]: Leaving directory '/.../tests/opr' ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_isNil ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_equal ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_hash ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_fromString ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_create ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_unpack ld: 0711-317 ERROR: Undefined symbol: .opr_uuid_pack ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[1]: *** [Makefile:37: uuid-t] Error 8 make[1]: Leaving directory '/.../tests/opr' ld: 0711-317 ERROR: Undefined symbol: .rxevent_Init ld: 0711-317 ERROR: Undefined symbol: .rxevent_Post ld: 0711-317 ERROR: Undefined symbol: .rxevent_Cancel ld: 0711-317 ERROR: Undefined symbol: .rxevent_RaiseEvents ld: 0711-317 ERROR: Undefined symbol: .rxevent_Put ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make[1]: *** [Makefile:18: event-t] Error 8 make[1]: Leaving directory '/.../tests/rx' To fix these, export the relevant symbols from the library's .sym file. Reviewed-on: https://gerrit.openafs.org/14707 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 9656a6b92b86849aa964529947bacb5aea4d83eb) Backport notes: The following symbols are not present in the 1.8.x branch at this time, so removed from this backported patch: * afsconf_GetLatestRXGKKey * opr_cache_free * opr_cache_get * opr_cache_init * opr_cache_put * osi_audit_close * osi_audit_cmd_Options * osi_audit_open * pr_Initialize2 * ubik_CallRock The following symbol files are not present in the 1.8.x branch at this time, so were removed from this backported patch: * src/fsprobe/liboafs_fsprobe.la.sym * src/gtx/liboafs_gtx.la.sym * src/xstat/liboafs_xstat_fs.la.sym Change-Id: Idd7059fe9e372d9131fa575412b391f03cb24bb3 Reviewed-on: https://gerrit.openafs.org/15403 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
5e282943ff |
LINUX: Introduce afs_d_alias_foreach
We have a couple of places in the code that iterate over the dentry aliases of an inode, and each of these involves a small #ifdef ladder to handle slightly different ways of traversing the relevant list. Split this logic into its own compatibility macro, afs_d_alias_foreach[_reverse], to contain this ugliness in osi_compat.h and make the callers more readable. This commit should incur no functional change; it is just code reorganization. Reviewed-on: https://gerrit.openafs.org/15390 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit 5aaed53f07fae0856e6da9defc408960e72364a7) Change-Id: I107c01917512da6c1043880cb93754be37919c47 Reviewed-on: https://gerrit.openafs.org/15401 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Andrew Deason
|
7f9445bbeb |
afs: Fix a few ARCH/osi_vcache.c style errors
Most of the ARCH/osi_vcache.c implementations were defining functions
like:
void
osi_foo(args) {
/* impl */
}
But our prevailing style is:
void
osi_foo(args)
{
/* impl */
}
Fix them to follow our prevailing style, and fix a couple of the more
obvious errors with identation and goto label.
Reviewed-on: https://gerrit.openafs.org/13699
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ee7019a7630d01f29fecebd89ca69ad8a37e24e2)
Change-Id: I2a34a0d8fd7b6c3721ede0c40c212c3993402235
Reviewed-on: https://gerrit.openafs.org/15400
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
|
||
|
Cheyenne Wills
|
f6fbb85c00 |
Linux 6.3: Use mnt_idmap for inode op functions
Through a series of Linux 6.3 commits starting with: 'f2fs: project ids aren't idmapped' (64b4cdf22f) and ending with 'fs: move mnt_idmap' (3707d84c13) the inode operations functions were changed to take a mnt_idmap structure instead of a user_namespace structure. These were pulled in via the the merge commit: 'Pull vfs idmapping updates from Christian Brauner' (05e6295f7b) The commit message for the merge contains background and overall information for this conversion. The above change simply changes the functions to use a different structure (mnt_idmap instead of user_namespace). For afs, it is a simple change to swap the structures. But for some of the Linux calls (generic_fillattr(), setattr_prepare(), and inode_op->setattr()) we would like to use the Linux symbol nop_mnt_idmap, but that symbol is exported as GPL only. Instead, we will obtain its address from the current task structure at libafs initialization (much the same way as obtaining current user namespace for afs_ns). Add autoconf tests to determine if inode_operations.create() uses the mnt_idmap structure. If so set a generic configure define for "IOP_TAKES_MNT_IDMAP". Update afs's inode operations functions to take and use a mnt_idmap instead of a user_namespace. At libafs initialization, obtain the mnt_idmap from the current task and save it as an afs global variable, afs_mnt_idmap, to be used where needed. Reviewed-on: https://gerrit.openafs.org/15347 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 858ee34545e57acab1e4e5813cd1b9a011538b9e) Change-Id: If89c6f401db04826ef45de83b91240f106cca616 Reviewed-on: https://gerrit.openafs.org/15389 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Cheyenne Wills
|
7a3ad3bc1c |
Linux 6.3: Include linux/filelock.h if available
Linux 6.3 commit 'filelock: move file locking definitions to separate header file' (5970e15dbc) relocated file lock related declarations from 'linux/fs.h' into its own header file, 'linux/filelock.h'. Add autoconf tests to check for the header file 'linux/filelock.h' and update function checks for locks_lock_file_wait() and posix_lock_file(). Update osi_compat.h to include linux/filelock.h if it is available. Reviewed-on: https://gerrit.openafs.org/15346 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> (cherry picked from commit 6873dc925c5acc0ce7d65cf778ffee09c82a9898) Change-Id: If131bee5b466a119f54b05388a065e6af23698cf Reviewed-on: https://gerrit.openafs.org/15388 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Ben Huntsman
|
30cf5d8f93 |
AIX: Avoid including net/netisr.h on AIX 7.2 and above
On AIX 7.2 and higher, /usr/include/net/netisr.h includes a header <sys/libsysp.h>. This is an internal kernel library header that IBM does not ship. The include of sys/libsysp.h is new in AIX 7.2. The only information we need from net/netisr.h are the definitions for NETISR_MAX and NET_KPROC. Using the macro AFS_AIX72_ENV, defined in src/config/param.rs_aix72.h and param.rs_aix73.h, we can just provide these definitions directly and avoid the include of net/netisr.h. As part of this update we also add the macro AFS_AIX72_ENV to src/config/param.rs_aix72.h as it was missing there but is required for the edit to src/rx/AIX/rx_knet.c to work. On earlier versions of AIX, we will continue to include net/netisr.h. A case has been opened with IBM and they acknowledge the problem and are working on a solution. However, we still need to be able to deal with the situation as shipped from IBM. A future AIX 7.4 will likely be able to include net/netisr.h again. Reviewed-on: https://gerrit.openafs.org/15312 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit ca67e8c84891200398e577d76c0125966d22b01e) Change-Id: Icc3e241e09876a4e9ed3e779c1ba904e0762f92c Reviewed-on: https://gerrit.openafs.org/15386 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Ben Huntsman
|
e83ce49c2d |
comerr: Update rule for compile_et
Update the build rule for compile_et under new platform rs_aix73. Reviewed-on: https://gerrit.openafs.org/15311 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> (cherry picked from commit b713b62b3358482a818436a54975596188cb002b) Change-Id: I726cf21a2c70305c24c3f43f2504e70a98536aa7 Reviewed-on: https://gerrit.openafs.org/15385 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Ben Huntsman
|
9b94108664 |
configure: Add platform rs_aix73
Enable the configure script to detect and configure AIX 7.3. Update INSTALL to reflect new platform. Reviewed-on: https://gerrit.openafs.org/15310 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit d03723e87a16e19a34950ca84a6139095a0694f9) Change-Id: I6727512ee343b3ee4cbb03c1e6242a69f407b987 Reviewed-on: https://gerrit.openafs.org/15384 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Ben Huntsman
|
c962d1b911 |
INSTALL: Update INSTALL to reflect AIX platforms
Update the INSTALL file to reflect the current rs_aix platforms that we can build for. Reviewed-on: https://gerrit.openafs.org/15142 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit 4580f213b3a25dd57e6fd721f7ecc0ecad84fb07) Change-Id: I3e0d62258e57ff6a54fae2e49a427c764e03a9ae Reviewed-on: https://gerrit.openafs.org/15383 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |
||
|
Ben Huntsman
|
cff8ef661b |
AIX: Fix issue with make install on AIX 7.1 and higher
Added rules to src/export/Makefile.in for the install target under AIX 7.1 and higher. Reviewed-on: https://gerrit.openafs.org/15146 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> (cherry picked from commit f4fc18b80e81f10b17729ef06cca6a9548d36130) Change-Id: I0fcc1429111eaafa489adec330b5eb900022293e Reviewed-on: https://gerrit.openafs.org/15382 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> |