#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57

#1 doadump (textdump=3D<optimized out>) at /usr/src/sys/ke= rn/kern_shutdown.c:405

#2 0xffffffff80b324f7 in kern_reboot (howto=3D260) at /usr/= src/sys/kern/kern_shutdown.c:523

#3 0xffffffff80b329ce in vpanic (fmt=3D0xffffffff8115edb8 &= quot;%s", ap=3Dap@entry=3D0xfffffe005d6dfa10)

at /usr/src/sys/kern/kern_shutdown.c:967

#4 0xffffffff80b32823 in panic (fmt=3D<unavailable>) = at /usr/src/sys/kern/kern_shutdown.c:891

#5 0xffffffff80fff91b in trap_fatal (frame=3D0xfffffe005d6d= faf0, eva=3D200) at /usr/src/sys/amd64/amd64/trap.c:952

#6 0xffffffff80fff966 in trap_pfault (frame=3D<unavailab= le>, usermode=3Dfalse, signo=3D<optimized out>,

ucode=3D<optimized out>) at /usr/src/sys/amd64/amd64/tr= ap.c:760

#7 <signal handler called>

#8 0xffffffff832bb1d3 in rxi_FindIfnet () from /usr/vice/et= c/libafs.ko

#9 0x0000000000000000 in ?? ()

rxi_FindIfnet is in src/rx/rx_kcommon.c. One thing that I notic= ed that jumps out at me is that on FreeBSD, the code calls CURVNET_SET.&nbs= p; This same call and some similar ones are also present in a section of sr= c/afs/afs_server.c that needed some changes due to removed calls in FreeBSD 14.1.

However, I'm much less familiar with FreeBSD than I am with AIX, so I would= appreciate a pointer if I'm looking in the right direction or this is= a red herring.

Debugging on this version of FreeBSD is also made more difficult as trying = to build the OpenAFS tree with debug enabled results in many errors similar= to this:

usr/bin/ctfconvert -g -l openafs .libs/camellia.o ERROR: ctfconvert: rc =3D= 1 Unsupported version [_dwarf_info_load(229)]

As always, many thanks in advance for any tips/pointers!

-Ben

--_000_BYAPR07MB587986BFAC90590D3D5AE6FFA7512BYAPR07MB5879namp_-- From ben@huntsmans.net Tue Nov 5 01:07:22 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 5 Nov 2024 01:07:22 +0000 Subject: [OpenAFS-devel] Can't load kernel module on custom Linux 6.5.2 Message-ID: --_000_BYAPR07MB5879773367C52142C62D5F40A7522BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there- This is totally unrelated to my previous e-mail regarding FreeBSD. Has anyone seen this error on Linux: # insmod openafs.ko insmod: ERROR: could not insert module openafs.ko: Device or resource busy This is on a "custom" Linux system not based on RHEL/SLES/Ubuntu/Debian.= The architecture is amd64, the kernel is 6.5.2, and the configure options= were --enable-transarc-paths --with-linux-kernel-packaging The kernel was recently recompiled to eliminate that as an issue also. Thank you! -Ben --_000_BYAPR07MB5879773367C52142C62D5F40A7522BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there-

This is totally unrelated to my previous e-mail regarding Free= BSD.

Has anyone seen this error on Linux:

# insmod openafs.ko
insmod: ERROR: could not insert module openafs.ko: Device or resource busy<= /div>

This is on a "custom" Linux system not based on RHEL= /SLES/Ubuntu/Debian. The architecture is amd64, the kernel is 6.5.2, = and the configure options were --enable-transarc-paths --with-linux-kernel-= packaging

The kernel was recently recompiled to eliminate that as an iss= ue also.

Thank you!

-Ben

--_000_BYAPR07MB5879773367C52142C62D5F40A7522BYAPR07MB5879namp_-- From kaduk@mit.edu Tue Nov 5 03:52:15 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 4 Nov 2024 19:52:15 -0800 Subject: [OpenAFS-devel] Can't load kernel module on custom Linux 6.5.2 In-Reply-To: References: Message-ID: To answer the question as stated, no, I have not seen this myself. But ... On Tue, Nov 05, 2024 at 01:07:22AM +0000, Ben Huntsman wrote: > Hi there- > This is totally unrelated to my previous e-mail regarding FreeBSD. > > Has anyone seen this error on Linux: > > # insmod openafs.ko > insmod: ERROR: could not insert module openafs.ko: Device or resource busy There is sometimes some more helpful information in the dmesg output; is there anything relevant there? -Ben > > This is on a "custom" Linux system not based on RHEL/SLES/Ubuntu/Debian. The architecture is amd64, the kernel is 6.5.2, and the configure options were --enable-transarc-paths --with-linux-kernel-packaging > > The kernel was recently recompiled to eliminate that as an issue also. > > Thank you! > > -Ben > > From kaduk@mit.edu Tue Nov 5 04:16:06 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 4 Nov 2024 20:16:06 -0800 Subject: [OpenAFS-devel] OpenAFS on FreeBSD 14.1 In-Reply-To: References: Message-ID: On Mon, Nov 04, 2024 at 06:00:00PM +0000, Ben Huntsman wrote: > Hi there! > Has anyone looked at getting OpenAFS working on FreeBSD 14.1 lately? They've changed a bunch of stuff. I managed to get it to compile, and I can load the kernel module and start bosserver, but as soon as I run bos setcell, I get a kernel panic. In fact, any command which takes a -server argument causes a panic. I don't have a FreeBSD-14 system up yet, no. > Here's a backtrace from a dump: > > First of all, the stack backtrace while starting kgdb: > > ... > KDB: stack backtrace: > #0 0xffffffff80b7fbfd at kdb_backtrace+0x5d > #1 0xffffffff80b32961 at vpanic+0x131 > #2 0xffffffff80b32823 at panic+0x43 > #3 0xffffffff80fff91b at trap_fatal+0x40b > #4 0xffffffff80fff966 at trap_pfault+0x46 > #5 0xffffffff80fd6a48 at calltrap+0x8 > #6 0xffffffff832e3dfb at afs_syscall_call+0x1627 That suggests that some basic processing in the syscall stub is accessing memory in ways it shouldn't, as if we were trying to dereference a userspace pointer rather than copyin() the data it points to. But I did not think that anything big had changed in FreeBSD that would cause us to start breaking spontaneously... > #7 0xffffffff832485c3 at afs3_syscall+0x89 > #8 0xffffffff8100073b at amd64_syscall+0x67b > #9 0xffffffff80fd735b at fast_syscall_common+0xf8 > ... > > And the backtrace: > > (kgdb) backtrace > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:405 > #2 0xffffffff80b324f7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:523 > #3 0xffffffff80b329ce in vpanic (fmt=0xffffffff8115edb8 "%s", ap=ap@entry=0xfffffe005d6dfa10) > at /usr/src/sys/kern/kern_shutdown.c:967 > #4 0xffffffff80b32823 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:891 > #5 0xffffffff80fff91b in trap_fatal (frame=0xfffffe005d6dfaf0, eva=200) at /usr/src/sys/amd64/amd64/trap.c:952 > #6 0xffffffff80fff966 in trap_pfault (frame=, usermode=false, signo=, > ucode=) at /usr/src/sys/amd64/amd64/trap.c:760 > #7 > #8 0xffffffff832bb1d3 in rxi_FindIfnet () from /usr/vice/etc/libafs.ko > #9 0x0000000000000000 in ?? () > > > rxi_FindIfnet is in src/rx/rx_kcommon.c. One thing that I noticed that jumps out at me is that on FreeBSD, the code calls CURVNET_SET. This same call and some similar ones are also present in a section of src/afs/afs_server.c that needed some changes due to removed calls in FreeBSD 14.1. CURVNET_SET is something we do need to be doing and is FreeBSD-specific, but keeping track of when to set/restore it is a place where we've had issues in the past. Looking at the specific call make me wonder if the global rx_socket is actually initialized at this point. > However, I'm much less familiar with FreeBSD than I am with AIX, so I would appreciate a pointer if I'm looking in the right direction or this is a red herring. Getting the debug build working might be more fruitful than starting at a coarse-grained backtrace or debug-via-printf. > Debugging on this version of FreeBSD is also made more difficult as trying to build the OpenAFS tree with debug enabled results in many errors similar to this: > > usr/bin/ctfconvert -g -l openafs .libs/camellia.o ERROR: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] I am not sure whether the CTF support got any real exercise on FreeBSD, so I would be inclined to suggest modifying src/config/cc-wrapper.in to just exit early and see if that lets the build progress. I would want to get it tracked down and fixed eventually, but it seems like it might be unrelated to your proximate issues. -Ben From ben@huntsmans.net Tue Nov 5 04:17:36 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 5 Nov 2024 04:17:36 +0000 Subject: [OpenAFS-devel] Can't load kernel module on custom Linux 6.5.2 In-Reply-To: References: Message-ID: --_000_BYAPR07MB5879CCDA861E2D1925C88A89A7522BYAPR07MB5879namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben- Thank you for the reply! I posted this on behalf of a colleague. It wa= s determined that this was due to the user not building the kernel with the= AFS Support option. Thank you!! -Ben ________________________________ From: Benjamin Kaduk Sent: Monday, November 4, 2024 7:52 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Can't load kernel module on custom Linux 6.5.2 To answer the question as stated, no, I have not seen this myself. But ... On Tue, Nov 05, 2024 at 01:07:22AM +0000, Ben Huntsman wrote: > Hi there- > This is totally unrelated to my previous e-mail regarding FreeBSD. > > Has anyone seen this error on Linux: > > # insmod openafs.ko > insmod: ERROR: could not insert module openafs.ko: Device or resource bus= y There is sometimes some more helpful information in the dmesg output; is there anything relevant there? -Ben > > This is on a "custom" Linux system not based on RHEL/SLES/Ubuntu/Debia= n. The architecture is amd64, the kernel is 6.5.2, and the configure optio= ns were --enable-transarc-paths --with-linux-kernel-packaging > > The kernel was recently recompiled to eliminate that as an issue also. > > Thank you! > > -Ben > > --_000_BYAPR07MB5879CCDA861E2D1925C88A89A7522BYAPR07MB5879namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ben-

Thank you for the reply! I posted this on behalf of a co= lleague. It was determined that this was due to the user not building= the kernel with the AFS Support option.

Thank you!!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Monday, November 4, 2024 7:52 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Can't load kernel module on custom Linu= x 6.5.2

To answer the question as stated, no, I have not s= een this myself. But ...

On Tue, Nov 05, 2024 at 01:07:22AM +0000, Ben Huntsman wrote:
> Hi there-
>    This is totally unrelated to my previous e-mail rega= rding FreeBSD.
>
>    Has anyone seen this error on Linux:
>
> # insmod openafs.ko
> insmod: ERROR: could not insert module openafs.ko: Device or resource = busy

There is sometimes some more helpful information in the dmesg output; is there anything relevant there?

-Ben

>
>    This is on a "custom" Linux system not bas= ed on RHEL/SLES/Ubuntu/Debian. The architecture is amd64, the kernel = is 6.5.2, and the configure options were --enable-transarc-paths --with-lin= ux-kernel-packaging
>
>    The kernel was recently recompiled to eliminate that= as an issue also.
>
> Thank you!
>
> -Ben
>
>

--_000_BYAPR07MB5879CCDA861E2D1925C88A89A7522BYAPR07MB5879namp_-- From cwills@sinenomine.net Tue Nov 5 14:32:43 2024 From: cwills@sinenomine.net (Cheyenne Wills) Date: Tue, 5 Nov 2024 07:32:43 -0700 Subject: [OpenAFS-devel] Can't load kernel module on custom Linux 6.5.2 In-Reply-To: References: Message-ID: <20241105073243.2ff2d9bc.cwills@sinenomine.net> The in-kernel AFS is different entity from OpenAFS and the two will conflict with each other. If you are trying to use OpenAFS, make sure that the kernel AFS module is not loaded Check the kernel .config to see if CONFIG_AFS_FS=y (the kernel AFS module is built into the kernel. Or if CONFIG_AFS_FS=m (the kernel AFS module is loadable) and if kafs.ko is loaded (lsmod|grep kafs). Either of these situations will conflict with openAFS's kernel module. Other things to check: Check the OpenAFS configure and build logs to ensure that the kernel module was built cleanly. After installing the OpenAFS kernel module (openafs.ko) to the appropriate directory, make sure that you run a depmod -a. You can manually do a modprobe openafs to see if the kernel module loads (check dmesg for any errors), then you can do a rmmod to unload the kernel module. If you are still having problems, post the kernel level you are trying to build. Just be aware that Linux 6.12-rc will require some patches that I haven't yet pushed to gerrit. -- Cheyenne Wills cwills@sinenomine.net On Tue, 5 Nov 2024 04:17:36 +0000 Ben Huntsman wrote: > Hi Ben- > Thank you for the reply! I posted this on behalf of a colleague. > It was determined that this was due to the user not building the > kernel with the AFS Support option. > > Thank you!! > > -Ben > > ________________________________ > From: Benjamin Kaduk > Sent: Monday, November 4, 2024 7:52 PM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Can't load kernel module on custom Linux > 6.5.2 > > To answer the question as stated, no, I have not seen this myself. > But ... > > On Tue, Nov 05, 2024 at 01:07:22AM +0000, Ben Huntsman wrote: > > Hi there- > > This is totally unrelated to my previous e-mail regarding > > FreeBSD. > > > > Has anyone seen this error on Linux: > > > > # insmod openafs.ko > > insmod: ERROR: could not insert module openafs.ko: Device or > > resource busy > > There is sometimes some more helpful information in the dmesg output; > is there anything relevant there? > > -Ben > > > > > This is on a "custom" Linux system not based on > > RHEL/SLES/Ubuntu/Debian. The architecture is amd64, the kernel is > > 6.5.2, and the configure options were --enable-transarc-paths > > --with-linux-kernel-packaging > > > > The kernel was recently recompiled to eliminate that as an issue > > also. > > > > Thank you! > > > > -Ben > > > > From ben@huntsmans.net Tue Nov 5 16:24:29 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 5 Nov 2024 16:24:29 +0000 Subject: [OpenAFS-devel] OpenAFS on FreeBSD 14.1 In-Reply-To: References: Message-ID: --_000_BYAPR07MB587925318E74E3C52D6EB246A7522BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! Thanks for the reply! > Getting the debug build working might be more fruitful than starting at a coarse-grained backtrace or debug-via-printf. I'm looking into this. On FreeBSD 14.1, we have both gcc 13.3.0 and clang = 18.1.5 installed. If we just run ./configure, it selects gcc by default. = Building with gcc compiles with a few changes, but throws all those CTF err= ors. building with clang breaks on this: src/rx/rx_packet.c:1770:13: error: passing arguments to a function without = a prototype is deprecated in all versions of C and is not supported in C23 = [-Werror,-Wdeprecated-non-prototype] 1770 | (*free) (amb); | ^ Going back to the gcc build, I used the following configure options: --enable-transarc-paths --enable-kauth --enable-debug --enable-debug-kernel= --enable-debug-locks --enable-debug-lwp However, something doesn't look right in the kernel module. Shouldn't ther= e be more than this: objdump --syms /usr/vice/etc/libafs.ko | grep debug 00000000000006c8 l O .bss 0000000000000008 debugvc 000000000025c9f8 l O .bss 0000000000000004 debugsetsp 000000000025a7c0 l O .bss 0000000000000008 rx_tq_debug 0000000000000000 l d .gnu_debuglink 0000000000000000 .gnu_debuglink When I run kgdb during the startup messages it prints this: Reading symbols from /usr/vice/etc/libafs.ko... (No debugging symbols found in /usr/vice/etc/libafs.ko) Any idea how to actually enable debugging info on the kernel module? Many thanks! -Ben --_000_BYAPR07MB587925318E74E3C52D6EB246A7522BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

Thanks for the reply!

> Getting the debug build working might be more fruitful than starting a= t a
coarse-grained backtrace or debug-via-printf.

I'm looking into this. On FreeBSD 14.1, we have both gcc 13.3.0 and c= lang 18.1.5 installed. If we just run ./configure, it selects gcc by = default. Building with gcc compiles with a few changes, but throws al= l those CTF errors. building with clang breaks on this:

src/rx/rx_packet.c:1770:13: error: passing arguments to a function without = a prototype is deprecated in all versions of C and is not supported in C23 = [-Werror,-Wdeprecated-non-prototype]

1770 | (*free) (amb);

| ^

Going back to the gcc build, I used the following configure options:

--enable-transarc-paths --enable-kauth --enable-debug --enable-debug-kernel= --enable-debug-locks --enable-debug-lwp

However, something doesn't look right in the kernel module. Shouldn't= there be more than this:

objdump --syms /usr/vice/etc/libafs.ko | grep debug

00000000000006c8 l O .bss 0000000000000008 debugvc

000000000025c9f8 l O .bss 0000000000000004 debugsetsp

000000000025a7c0 l O .bss 0000000000000008 rx_tq_debug

0000000000000000 l d .gnu_debuglink 0000000000000000 .gn= u_debuglink

When I run kgdb during the startup messages it prints this:

Reading symbols from /usr/vice/etc/libafs.ko...

(No debugging symbols found in /usr/vice/etc/libafs.ko)

Any idea how to actually enable debugging info on the kernel module?

Many thanks!

-Ben

--_000_BYAPR07MB587925318E74E3C52D6EB246A7522BYAPR07MB5879namp_-- From kaduk@mit.edu Tue Nov 5 17:37:51 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 5 Nov 2024 09:37:51 -0800 Subject: [OpenAFS-devel] OpenAFS on FreeBSD 14.1 In-Reply-To: References: Message-ID: On Tue, Nov 05, 2024 at 04:24:29PM +0000, Ben Huntsman wrote: > Hi there! > Thanks for the reply! > > > Getting the debug build working might be more fruitful than starting at a > coarse-grained backtrace or debug-via-printf. > > I'm looking into this. On FreeBSD 14.1, we have both gcc 13.3.0 and clang 18.1.5 installed. If we just run ./configure, it selects gcc by default. Building with gcc compiles with a few changes, but throws all those CTF errors. building with clang breaks on this: > > src/rx/rx_packet.c:1770:13: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C23 [-Werror,-Wdeprecated-non-prototype] > 1770 | (*free) (amb); > | ^ That looks like a new compiler rightly complaining about super-janky code, on first look. It's vaguely possible that there are some preprocess ifdefs such that we shouldn't actually be trying to build that code for FreeBSD but it looks like that's the only implementation of rx_mb_to_packet() and the function is referenced from FBSD/rx_knet.c so I think we need to fix it. > Going back to the gcc build, I used the following configure options: > > --enable-transarc-paths --enable-kauth --enable-debug --enable-debug-kernel --enable-debug-locks --enable-debug-lwp > > However, something doesn't look right in the kernel module. Shouldn't there be more than this: > > objdump --syms /usr/vice/etc/libafs.ko | grep debug > 00000000000006c8 l O .bss 0000000000000008 debugvc > 000000000025c9f8 l O .bss 0000000000000004 debugsetsp > 000000000025a7c0 l O .bss 0000000000000008 rx_tq_debug > 0000000000000000 l d .gnu_debuglink 0000000000000000 .gnu_debuglink > > > When I run kgdb during the startup messages it prints this: > > Reading symbols from /usr/vice/etc/libafs.ko... > (No debugging symbols found in /usr/vice/etc/libafs.ko) > > Any idea how to actually enable debugging info on the kernel module? So, not speaking with certainty here, but we do leverage very heavily the stock FreeBSD kernel module build logic for our kmod build, which means that some of the OpenAFS-specific knobs may not be doing much. Are you running a kernel config with makeoptions DEBUG=-g? It looks like since a9c1939eeb36372872f3258a9ae7259a564332c3 we assume GENERIC is used, so if you're doing a custom kernel you'd need to pass --with-bsd-kernel-build to configure. -Ben From ben@huntsmans.net Sun Nov 10 23:34:49 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 10 Nov 2024 23:34:49 +0000 Subject: [OpenAFS-devel] Libtool on AIX Message-ID: --_000_BYAPR07MB58792E4AFCC579DB31FC0460A75F2BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! I'm not super familiar with libtool's inner workings, so I was wondering= if someone could help point me in the right direction. On AIX, if we conf= igure with --enable-transarc-paths (though I think this happens even withou= t it), and after the make, run "make dest", the resulting binaries don't wo= rk. I'm currently trying this on AIX 7.1. The shared libraries should end u= p in rs_aix71/dest/lib. Let's say I try to run afsd: ./afsd --help exec(): 0509-036 Cannot load program ./afsd because of the following errors= : 0509-150 Dependent module libafshcrypto.a(libafshcrypto.so.2) cou= ld not be loaded. 0509-022 Cannot load module libafshcrypto.a(libafshcrypto.so.2). 0509-026 System error: A file or directory in the path name does no= t exist. Ok, expected with shared libraries. On AIX I can set my LD_LIBRARY_PATH to= /wherever/rs_aix71/dest/lib, and try again: $ ./afsd --help exec(): 0509-036 Cannot load program ./afsd because of the following errors= : 0509-150 Dependent module /whereever/rs_aix71/dest/lib/libafshcry= pto.a(libafshcrypto.so.2) could not be loaded. 0509-152 Member libafshcrypto.so.2 is not found in archive Let's see what is in that archive: $ ar t /wherever/rs_aix71/dest/lib/libafshcrypto.a aes.o camellia.o camellia-ntt.o des.o engine.o evp.o evp-hcrypto.o evp-cc.o hmac.o md2.o md4.o md5.o pkcs5.o rand-egd.o rand-timer.o rand-unix.o rand.o rc2.o rc4.o rijndael-alg-fst.o rnd_keys.o sha.o sha256.o sha512.o ui.o validate.o rand-fortuna.o Sure enough, that's the static archive. Let's see what exists in the build= directory: $ find /wherever -name libafshcrypto.a /wherever/lib/libafshcrypto.a /wherever/rs_aix71/dest/lib/libafshcrypto.a /wherever/src/crypto/hcrypto/.libs/libafshcrypto.a /wherever/src/crypto/hcrypto/libafshcrypto.a Ok, we're interested in the contents of src/crypto/hcrypto/libafshcrypto.a = and src/crypto/hcrypto/.libs/libafshcrypto.a: $ ar t /whereever/src/crypto/hcrypto/libafshcrypto.a aes.o camellia.o camellia-ntt.o des.o engine.o evp.o evp-hcrypto.o evp-cc.o hmac.o md2.o md4.o md5.o pkcs5.o rand-egd.o rand-timer.o rand-unix.o rand.o rc2.o rc4.o rijndael-alg-fst.o rnd_keys.o sha.o sha256.o sha512.o ui.o validate.o rand-fortuna.o ... That's the static archive... $ ar t /whereever/src/crypto/hcrypto/.libs/libafshcrypto.a libafshcrypto.so.2 Aha, that's the shared library archive! Now, on AIX, you can have an archive file with both static and shared objec= ts in it. So what we really want here is for the installed libafshcrypto.a= to have all the .o files, and also the libafshcrypto.so.2 in it. Let's look at the "dest" make rule in src/crypto/hcrypto/Makefile: dest: $(SHARED_LIBS) libafshcrypto.a ${LT_INSTALL_DATA} libafshcrypto.la ${DEST}/lib/libafshcrypto.la ${RM} ${DEST}/lib/libafshcrypto.la ${INSTALL_DATA} libafshcrypto.a ${DEST}/lib/libafshcrypto.a AHA, that looks like the problem! First we install the shared library, the= n we overwrite it with the static library! Of course this only breaks on A= IX because on AIX the names of the shared and the static libraries are the = same. I thought that is what the --with-aix=3Dsoname=3Daix configure optio= n is supposed to take care of, which is the default. Ideally libtool could= either build the combined library in src/crypto/hcrypto so that this works= as-is, or else the Makefile needs to be heavily reworked with some AIX spe= cifics. This library is just one example out of many, all of them have the= same issue on AIX with the "dest" target, as well as the "install" target. Another alternative that I might prefer, would be for the default on AIX to= be to disable shared libraries altogether. This would be more similar to = the original IBM AFS. Would that be possible, something everyone could agr= ee on, and anyone know how to do that? Obviously this is a big problem, as the AIX build doesn't work unless you s= elect only one or the other shared/static library options manually as a ./c= onfigure option. Thanks in advance for any suggestions! -Ben --_000_BYAPR07MB58792E4AFCC579DB31FC0460A75F2BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

I'm not super familiar with libtool's inner workings, so = I was wondering if someone could help point me in the right direction.= On AIX, if we configure with --enable-transarc-paths (though I think= this happens even without it), and after the make, run "make dest", the resulting binaries don't work.

I'm currently trying this on AIX 7.1. The shared librari= es should end up in rs_aix71/dest/lib. Let's say I try to run afsd:

./afsd --help

exec(): 0509-036 Cannot load program ./afsd because of the following errors= :

0509-150 Dependent module libafshcrypto.= a(libafshcrypto.so.2) could not be loaded.

0509-022 Cannot load module libafshcrypto.a(lib= afshcrypto.so.2).

0509-026 System error: A file or directory in t= he path name does not exist.

Ok, expected with shared libraries. On AIX I can set my LD_LIBRARY_PA= TH to /wherever/rs_aix71/dest/lib, and try again:

$ ./afsd --help

exec(): 0509-036 Cannot load program ./afsd because of the following errors= :

0509-150 Dependent module /whereever/rs_= aix71/dest/lib/libafshcrypto.a(libafshcrypto.so.2) could not be loaded.

0509-152 Member libafshcrypto.so.2 is no= t found in archive

Let's see what is in that archive:

$ ar t /wherever/rs_aix71/dest/lib/libafshcrypto.a

aes.o

camellia.o

camellia-ntt.o

des.o

engine.o

evp.o

evp-hcrypto.o

evp-cc.o

hmac.o

md2.o

md4.o

md5.o

pkcs5.o

rand-egd.o

rand-timer.o

rand-unix.o

rand.o

rc2.o

rc4.o

rijndael-alg-fst.o

rnd_keys.o

sha.o

sha256.o

sha512.o

ui.o

validate.o

rand-fortuna.o

Sure enough, that's the static archive. Let's see what exists in the = build directory:

$ find /wherever -name libafshcrypto.a

/wherever/lib/libafshcrypto.a

/wherever/rs_aix71/dest/lib/libafshcrypto.a

/wherever/src/crypto/hcrypto/.libs/libafshcrypto.a

/wherever/src/crypto/hcrypto/libafshcrypto.a

Ok, we're interested in the contents of src/crypto/hcrypto/libafshcrypto.a = and src/crypto/hcrypto/.libs/libafshcrypto.a:

$ ar t /whereever/src/crypto/hcrypto/libafshcrypto.a

aes.o

camellia.o

camellia-ntt.o

des.o

engine.o

evp.o

evp-hcrypto.o

evp-cc.o

hmac.o

md2.o

md4.o

md5.o

pkcs5.o

rand-egd.o

rand-timer.o

rand-unix.o

rand.o

rc2.o

rc4.o

rijndael-alg-fst.o

rnd_keys.o

sha.o

sha256.o

sha512.o

ui.o

validate.o

rand-fortuna.o

... That's the static archive...

$ ar t /whereever/src/crypto/hcrypto/.libs/libafshcrypto.a

libafshcrypto.so.2

Aha, that's the shared library archive!

Now, on AIX, you can have an archive file with both static and shared objec= ts in it. So what we really want here is for the installed libafshcry= pto.a to have all the .o files, and also the libafshcrypto.so.2 in it.

Let's look at the "dest" make rule in src/crypto/hcrypto/Makefile= :

dest: $(SHARED_LIBS) libafshcrypto.a

${LT_INSTALL_DATA} libafshcrypto.la ${DEST}/lib= /libafshcrypto.la

${RM} ${DEST}/lib/libafshcrypto.la

${INSTALL_DATA} libafshcrypto.a ${DEST}/lib/lib= afshcrypto.a

AHA, that looks like the problem! First we install the shared library= , then we overwrite it with the static library! Of course this only b= reaks on AIX because on AIX the names of the shared and the static librarie= s are the same. I thought that is what the --with-aix=3Dsoname=3Daix configure option is supposed to take care of, wh= ich is the default. Ideally libtool could either build the combined l= ibrary in src/crypto/hcrypto so that this works as-is, or else the Makefile= needs to be heavily reworked with some AIX specifics. This library is just one example out of many, all of them= have the same issue on AIX with the "dest" target, as well as th= e "install" target.

Another alternative that I might prefer, would be for the default on AIX to= be to disable shared libraries altogether. This would be more simila= r to the original IBM AFS. Would that be possible, something everyone= could agree on, and anyone know how to do that?

Obviously this is a big problem, as the AIX build doesn't work unless you s= elect only one or the other shared/static library options manually as a ./c= onfigure option.

Thanks in advance for any suggestions!

-Ben

--_000_BYAPR07MB58792E4AFCC579DB31FC0460A75F2BYAPR07MB5879namp_-- From kaduk@mit.edu Mon Nov 11 01:32:01 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sun, 10 Nov 2024 17:32:01 -0800 Subject: [OpenAFS-devel] Libtool on AIX In-Reply-To: References: Message-ID: tl'dr `make dest` is not going to work on AIX at all. You should be able to get a decent approximation by setting a PREFIX and passing some specific paths to configure for where various things go and using a `make install` workflow. I did not quickly find an explicit place where I documented this but the commit message for 87ce2a6f05e313dad43311fba93224f33b86f54f is pretty clear that `make dest` and libtool do not go well together. It kind of works by accident on most platforms but is doomed on AIX because libtool on AIX fundamentally requires re-linking at install time, but `make dest` assumes that you can "install" to a path and then move the resulting binaries around without breaking things. I need to do something else right now but might be able to dig up some references and write more at some point later. -Ben On Sun, Nov 10, 2024 at 11:34:49PM +0000, Ben Huntsman wrote: > Hi there! > I'm not super familiar with libtool's inner workings, so I was wondering if someone could help point me in the right direction. On AIX, if we configure with --enable-transarc-paths (though I think this happens even without it), and after the make, run "make dest", the resulting binaries don't work. > > I'm currently trying this on AIX 7.1. The shared libraries should end up in rs_aix71/dest/lib. Let's say I try to run afsd: > > ./afsd --help > exec(): 0509-036 Cannot load program ./afsd because of the following errors: > 0509-150 Dependent module libafshcrypto.a(libafshcrypto.so.2) could not be loaded. > 0509-022 Cannot load module libafshcrypto.a(libafshcrypto.so.2). > 0509-026 System error: A file or directory in the path name does not exist. > > Ok, expected with shared libraries. On AIX I can set my LD_LIBRARY_PATH to /wherever/rs_aix71/dest/lib, and try again: > > $ ./afsd --help > exec(): 0509-036 Cannot load program ./afsd because of the following errors: > 0509-150 Dependent module /whereever/rs_aix71/dest/lib/libafshcrypto.a(libafshcrypto.so.2) could not be loaded. > 0509-152 Member libafshcrypto.so.2 is not found in archive > > Let's see what is in that archive: > > $ ar t /wherever/rs_aix71/dest/lib/libafshcrypto.a > aes.o > camellia.o > camellia-ntt.o > des.o > engine.o > evp.o > evp-hcrypto.o > evp-cc.o > hmac.o > md2.o > md4.o > md5.o > pkcs5.o > rand-egd.o > rand-timer.o > rand-unix.o > rand.o > rc2.o > rc4.o > rijndael-alg-fst.o > rnd_keys.o > sha.o > sha256.o > sha512.o > ui.o > validate.o > rand-fortuna.o > > Sure enough, that's the static archive. Let's see what exists in the build directory: > > $ find /wherever -name libafshcrypto.a > /wherever/lib/libafshcrypto.a > /wherever/rs_aix71/dest/lib/libafshcrypto.a > /wherever/src/crypto/hcrypto/.libs/libafshcrypto.a > /wherever/src/crypto/hcrypto/libafshcrypto.a > > Ok, we're interested in the contents of src/crypto/hcrypto/libafshcrypto.a and src/crypto/hcrypto/.libs/libafshcrypto.a: > > $ ar t /whereever/src/crypto/hcrypto/libafshcrypto.a > aes.o > camellia.o > camellia-ntt.o > des.o > engine.o > evp.o > evp-hcrypto.o > evp-cc.o > hmac.o > md2.o > md4.o > md5.o > pkcs5.o > rand-egd.o > rand-timer.o > rand-unix.o > rand.o > rc2.o > rc4.o > rijndael-alg-fst.o > rnd_keys.o > sha.o > sha256.o > sha512.o > ui.o > validate.o > rand-fortuna.o > > ... That's the static archive... > > $ ar t /whereever/src/crypto/hcrypto/.libs/libafshcrypto.a > libafshcrypto.so.2 > > Aha, that's the shared library archive! > > Now, on AIX, you can have an archive file with both static and shared objects in it. So what we really want here is for the installed libafshcrypto.a to have all the .o files, and also the libafshcrypto.so.2 in it. > > Let's look at the "dest" make rule in src/crypto/hcrypto/Makefile: > > dest: $(SHARED_LIBS) libafshcrypto.a > ${LT_INSTALL_DATA} libafshcrypto.la ${DEST}/lib/libafshcrypto.la > ${RM} ${DEST}/lib/libafshcrypto.la > ${INSTALL_DATA} libafshcrypto.a ${DEST}/lib/libafshcrypto.a > > AHA, that looks like the problem! First we install the shared library, then we overwrite it with the static library! Of course this only breaks on AIX because on AIX the names of the shared and the static libraries are the same. I thought that is what the --with-aix=soname=aix configure option is supposed to take care of, which is the default. Ideally libtool could either build the combined library in src/crypto/hcrypto so that this works as-is, or else the Makefile needs to be heavily reworked with some AIX specifics. This library is just one example out of many, all of them have the same issue on AIX with the "dest" target, as well as the "install" target. > > Another alternative that I might prefer, would be for the default on AIX to be to disable shared libraries altogether. This would be more similar to the original IBM AFS. Would that be possible, something everyone could agree on, and anyone know how to do that? > > Obviously this is a big problem, as the AIX build doesn't work unless you select only one or the other shared/static library options manually as a ./configure option. > > Thanks in advance for any suggestions! > > -Ben > From ben@huntsmans.net Mon Nov 11 04:01:04 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 11 Nov 2024 04:01:04 +0000 Subject: [OpenAFS-devel] Libtool on AIX In-Reply-To: References: Message-ID: --_000_BYAPR07MB5879401CC61C77D7DF8CF5D1A7582BYAPR07MB5879namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben! Thank you for replying! "make dest" seems to work on AIX when you use the --disable-shared optio= n. I didn't think you could use "make install" with --enable-transarc-path= s. Regardless, being a traditionalist I'd rather have the dest tree get bu= ilt on AIX anyway, so I'm interested in fixing it if possible. Anyway, I look forward to your additional findings when you get a chance= ! Thank you so much! -Ben ________________________________ From: Benjamin Kaduk Sent: Sunday, November 10, 2024 5:32 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Libtool on AIX tl'dr `make dest` is not going to work on AIX at all. You should be able to get a decent approximation by setting a PREFIX and passing some specific paths to configure for where various things go and using a `make install` workflow. I did not quickly find an explicit place where I documented this but the commit message for 87ce2a6f05e313dad43311fba93224f33b86f54f is pretty clear that `make dest` and libtool do not go well together. It kind of works by accident on most platforms but is doomed on AIX because libtool on AIX fundamentally requires re-linking at install time, but `make dest` assumes that you can "install" to a path and then move the resulting binaries around without breaking things. I need to do something else right now but might be able to dig up some references and write more at some point later. -Ben On Sun, Nov 10, 2024 at 11:34:49PM +0000, Ben Huntsman wrote: > Hi there! > I'm not super familiar with libtool's inner workings, so I was wonderi= ng if someone could help point me in the right direction. On AIX, if we co= nfigure with --enable-transarc-paths (though I think this happens even with= out it), and after the make, run "make dest", the resulting binaries don't = work. > > I'm currently trying this on AIX 7.1. The shared libraries should end= up in rs_aix71/dest/lib. Let's say I try to run afsd: > > ./afsd --help > exec(): 0509-036 Cannot load program ./afsd because of the following erro= rs: > 0509-150 Dependent module libafshcrypto.a(libafshcrypto.so.2) c= ould not be loaded. > 0509-022 Cannot load module libafshcrypto.a(libafshcrypto.so.2). > 0509-026 System error: A file or directory in the path name does = not exist. > > Ok, expected with shared libraries. On AIX I can set my LD_LIBRARY_PATH = to /wherever/rs_aix71/dest/lib, and try again: > > $ ./afsd --help > exec(): 0509-036 Cannot load program ./afsd because of the following erro= rs: > 0509-150 Dependent module /whereever/rs_aix71/dest/lib/libafshc= rypto.a(libafshcrypto.so.2) could not be loaded. > 0509-152 Member libafshcrypto.so.2 is not found in archive > > Let's see what is in that archive: > > $ ar t /wherever/rs_aix71/dest/lib/libafshcrypto.a > aes.o > camellia.o > camellia-ntt.o > des.o > engine.o > evp.o > evp-hcrypto.o > evp-cc.o > hmac.o > md2.o > md4.o > md5.o > pkcs5.o > rand-egd.o > rand-timer.o > rand-unix.o > rand.o > rc2.o > rc4.o > rijndael-alg-fst.o > rnd_keys.o > sha.o > sha256.o > sha512.o > ui.o > validate.o > rand-fortuna.o > > Sure enough, that's the static archive. Let's see what exists in the bui= ld directory: > > $ find /wherever -name libafshcrypto.a > /wherever/lib/libafshcrypto.a > /wherever/rs_aix71/dest/lib/libafshcrypto.a > /wherever/src/crypto/hcrypto/.libs/libafshcrypto.a > /wherever/src/crypto/hcrypto/libafshcrypto.a > > Ok, we're interested in the contents of src/crypto/hcrypto/libafshcrypto.= a and src/crypto/hcrypto/.libs/libafshcrypto.a: > > $ ar t /whereever/src/crypto/hcrypto/libafshcrypto.a > aes.o > camellia.o > camellia-ntt.o > des.o > engine.o > evp.o > evp-hcrypto.o > evp-cc.o > hmac.o > md2.o > md4.o > md5.o > pkcs5.o > rand-egd.o > rand-timer.o > rand-unix.o > rand.o > rc2.o > rc4.o > rijndael-alg-fst.o > rnd_keys.o > sha.o > sha256.o > sha512.o > ui.o > validate.o > rand-fortuna.o > > ... That's the static archive... > > $ ar t /whereever/src/crypto/hcrypto/.libs/libafshcrypto.a > libafshcrypto.so.2 > > Aha, that's the shared library archive! > > Now, on AIX, you can have an archive file with both static and shared obj= ects in it. So what we really want here is for the installed libafshcrypto= .a to have all the .o files, and also the libafshcrypto.so.2 in it. > > Let's look at the "dest" make rule in src/crypto/hcrypto/Makefile: > > dest: $(SHARED_LIBS) libafshcrypto.a > ${LT_INSTALL_DATA} libafshcrypto.la ${DEST}/lib/libafshcrypto.la > ${RM} ${DEST}/lib/libafshcrypto.la > ${INSTALL_DATA} libafshcrypto.a ${DEST}/lib/libafshcrypto.a > > AHA, that looks like the problem! First we install the shared library, t= hen we overwrite it with the static library! Of course this only breaks on= AIX because on AIX the names of the shared and the static libraries are th= e same. I thought that is what the --with-aix=3Dsoname=3Daix configure opt= ion is supposed to take care of, which is the default. Ideally libtool cou= ld either build the combined library in src/crypto/hcrypto so that this wor= ks as-is, or else the Makefile needs to be heavily reworked with some AIX s= pecifics. This library is just one example out of many, all of them have t= he same issue on AIX with the "dest" target, as well as the "install" targe= t. > > Another alternative that I might prefer, would be for the default on AIX = to be to disable shared libraries altogether. This would be more similar t= o the original IBM AFS. Would that be possible, something everyone could a= gree on, and anyone know how to do that? > > Obviously this is a big problem, as the AIX build doesn't work unless you= select only one or the other shared/static library options manually as a .= /configure option. > > Thanks in advance for any suggestions! > > -Ben > --_000_BYAPR07MB5879401CC61C77D7DF8CF5D1A7582BYAPR07MB5879namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ben!

Thank you for replying!

"make dest" seems to work on AIX when you use the --= disable-shared option. I didn't think you could use "make instal= l" with --enable-transarc-paths. Regardless, being a traditional= ist I'd rather have the dest tree get built on AIX anyway, so I'm intereste= d in fixing it if possible.

Anyway, I look forward to your additional findings when you ge= t a chance!

Thank you so much!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Sunday, November 10, 2024 5:32 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Libtool on AIX

tl'dr `make dest` is not going to work on AIX at a= ll. You should be able
to get a decent approximation by setting a PREFIX and passing some specific=
paths to configure for where various things go and using a `make install` workflow.

I did not quickly find an explicit place where I documented this but the commit message for 87ce2a6f05e313dad43311fba93224f33b86f54f is pretty clear=
that `make dest` and libtool do not go well together. It kind of work= s by
accident on most platforms but is doomed on AIX because libtool on AIX
fundamentally requires re-linking at install time, but `make dest` assumes<= br> that you can "install" to a path and then move the resulting bina= ries
around without breaking things.

I need to do something else right now but might be able to dig up some
references and write more at some point later.

-Ben

On Sun, Nov 10, 2024 at 11:34:49PM +0000, Ben Huntsman wrote:
> Hi there!
>    I'm not super familiar with libtool's inner workings= , so I was wondering if someone could help point me in the right direction.= On AIX, if we configure with --enable-transarc-paths (though I think= this happens even without it), and after the make, run "make dest", the resulting binaries don't work.
>
>    I'm currently trying this on AIX 7.1. The shar= ed libraries should end up in rs_aix71/dest/lib. Let's say I try to r= un afsd:
>
> ./afsd --help
> exec(): 0509-036 Cannot load program ./afsd because of the following e= rrors:
>         0509-150   D= ependent module libafshcrypto.a(libafshcrypto.so.2) could not be loaded. >         0509-022 Cannot load m= odule libafshcrypto.a(libafshcrypto.so.2).
>         0509-026 System error:= A file or directory in the path name does not exist.
>
> Ok, expected with shared libraries. On AIX I can set my LD_LIBRA= RY_PATH to /wherever/rs_aix71/dest/lib, and try again:
>
> $ ./afsd --help
> exec(): 0509-036 Cannot load program ./afsd because of the following e= rrors:
>         0509-150   D= ependent module /whereever/rs_aix71/dest/lib/libafshcrypto.a(libafshcrypto.= so.2) could not be loaded.
>         0509-152   M= ember libafshcrypto.so.2 is not found in archive
>
> Let's see what is in that archive:
>
> $ ar t /wherever/rs_aix71/dest/lib/libafshcrypto.a
> aes.o
> camellia.o
> camellia-ntt.o
> des.o
> engine.o
> evp.o
> evp-hcrypto.o
> evp-cc.o
> hmac.o
> md2.o
> md4.o
> md5.o
> pkcs5.o
> rand-egd.o
> rand-timer.o
> rand-unix.o
> rand.o
> rc2.o
> rc4.o
> rijndael-alg-fst.o
> rnd_keys.o
> sha.o
> sha256.o
> sha512.o
> ui.o
> validate.o
> rand-fortuna.o
>
> Sure enough, that's the static archive. Let's see what exists in= the build directory:
>
> $ find /wherever -name libafshcrypto.a
> /wherever/lib/libafshcrypto.a
> /wherever/rs_aix71/dest/lib/libafshcrypto.a
> /wherever/src/crypto/hcrypto/.libs/libafshcrypto.a
> /wherever/src/crypto/hcrypto/libafshcrypto.a
>
> Ok, we're interested in the contents of src/crypto/hcrypto/libafshcryp= to.a and src/crypto/hcrypto/.libs/libafshcrypto.a:
>
> $ ar t /whereever/src/crypto/hcrypto/libafshcrypto.a
> aes.o
> camellia.o
> camellia-ntt.o
> des.o
> engine.o
> evp.o
> evp-hcrypto.o
> evp-cc.o
> hmac.o
> md2.o
> md4.o
> md5.o
> pkcs5.o
> rand-egd.o
> rand-timer.o
> rand-unix.o
> rand.o
> rc2.o
> rc4.o
> rijndael-alg-fst.o
> rnd_keys.o
> sha.o
> sha256.o
> sha512.o
> ui.o
> validate.o
> rand-fortuna.o
>
> ... That's the static archive...
>
> $ ar t /whereever/src/crypto/hcrypto/.libs/libafshcrypto.a
> libafshcrypto.so.2
>
> Aha, that's the shared library archive!
>
> Now, on AIX, you can have an archive file with both static and shared = objects in it. So what we really want here is for the installed libaf= shcrypto.a to have all the .o files, and also the libafshcrypto.so.2 in it.=
>
> Let's look at the "dest" make rule in src/crypto/hcrypto/Mak= efile:
>
> dest: $(SHARED_LIBS) libafshcrypto.a
>         ${LT_INSTALL_DATA} lib= afshcrypto.la ${DEST}/lib/libafshcrypto.la
>         ${RM} ${DEST}/lib/liba= fshcrypto.la
>         ${INSTALL_DATA} libafs= hcrypto.a ${DEST}/lib/libafshcrypto.a
>
> AHA, that looks like the problem! First we install the shared li= brary, then we overwrite it with the static library! Of course this o= nly breaks on AIX because on AIX the names of the shared and the static lib= raries are the same. I thought that is what the --with-aix=3Dsoname=3Daix configure option is supposed to take care of= , which is the default. Ideally libtool could either build the combin= ed library in src/crypto/hcrypto so that this works as-is, or else the Make= file needs to be heavily reworked with some AIX specifics. This library is just one example out of many, all of = them have the same issue on AIX with the "dest" target, as well a= s the "install" target.
>
> Another alternative that I might prefer, would be for the default on A= IX to be to disable shared libraries altogether. This would be more s= imilar to the original IBM AFS. Would that be possible, something eve= ryone could agree on, and anyone know how to do that?
>
> Obviously this is a big problem, as the AIX build doesn't work unless = you select only one or the other shared/static library options manually as = a ./configure option.
>
> Thanks in advance for any suggestions!
>
> -Ben
>

--_000_BYAPR07MB5879401CC61C77D7DF8CF5D1A7582BYAPR07MB5879namp_-- From ben@huntsmans.net Mon Nov 11 20:26:59 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 11 Nov 2024 20:26:59 +0000 Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? Message-ID: --_000_BYAPR07MB5879E2CED4267CE6EB6DA8E8A7582BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone- First of all, please don't laugh, but I do have an older test cell that = runs kauth instead of krb5. This is at home, not for anything production, = so don't worry. That being said, is kauth currently broken? A colleague of mine tried i= t on Linux and gets a segfault when running klog, and I get the same behavi= or on AIX: $ dbx /usr/afs/bin/klog core Type 'help' for help. [using memory image in core] reading symbolic information ... Segmentation fault in unnamed block in IOMGR at line 362 in file "iomgr.c" 362 FD_ZERO(&IOMGR_writefds); (dbx) where libdebug assertion "(framep->getGpr(STKP, &addr) =3D=3D DB_SUCCESS && *next= Stkpp =3D=3D addr)" failed at line 1418 in file ../../../../../../../../../= ../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_= FrameProgress.C unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c" (dbx) And here's a blurb from around that line in src/lwp/iomgr.c: ... /* These are not declared in IOMGR so that they don't use up 6K of stack. *= / static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds; static int IOMGR_nfds =3D 0; static void *IOMGR(void *dummy) { for (;;) { int code; struct TM_Elem *earliest; struct timeval timeout, junk; bool woke_someone; FD_ZERO(&IOMGR_readfds); FD_ZERO(&IOMGR_writefds); FD_ZERO(&IOMGR_exceptfds); IOMGR_nfds =3D 0; ... I did the compile with the ./configure --enable-debug and -enable-debug-= lwp options specified. Can someone help explain how this code works, and w= hat might done to fix it? I'm a little fuzzy on the *IOMGR piece and I don= 't see that anyone calls IOMGR() directly in the code... Thank you! -Ben --_000_BYAPR07MB5879E2CED4267CE6EB6DA8E8A7582BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone-

First of all, please don't laugh, but I do have an older test = cell that runs kauth instead of krb5. This is at home, not for anythi= ng production, so don't worry.

That being said, is kauth currently broken? A colleague = of mine tried it on Linux and gets a segfault when running klog, and I get = the same behavior on AIX:

$ dbx /usr/afs/bin/klog core

Type 'help' for help.

[using memory image in core]

reading symbolic information ...

Segmentation fault in unnamed block in IOMGR at line 362 in file "iomg= r.c"

362 FD_ZERO(&IOMGR_writefds);=

(dbx) where

libdebug assertion "(framep->getGpr(STKP, &addr) =3D=3D DB_SUCC= ESS && *nextStkpp =3D=3D addr)" failed at line 1418 in file ..= /../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/= stackdebug/POWER/stackdb_FrameProgress.C

unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c"

(dbx)

And here's a blurb from around that line in src/lwp/iomgr.c:

...

/* These are not declared in IOMGR so that they don't use up 6K of stack. *= /

static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds;

static int IOMGR_nfds =3D 0;

static void *IOMGR(void *dummy)

{

for (;;) {

int code;

struct TM_Elem *earliest;

struct timeval timeout, junk;

bool woke_someone;

FD_ZERO(&IOMGR_readfds);

FD_ZERO(&IOMGR_writefds);

FD_ZERO(&IOMGR_exceptfds);

IOMGR_nfds =3D 0;

...

I did the compile with the ./configure --enable-debug and -ena= ble-debug-lwp options specified. Can someone help explain how this co= de works, and what might done to fix it? I'm a little fuzzy on the *I= OMGR piece and I don't see that anyone calls IOMGR() directly in the code...

Thank you!

-Ben

--_000_BYAPR07MB5879E2CED4267CE6EB6DA8E8A7582BYAPR07MB5879namp_-- From ben@huntsmans.net Tue Nov 12 01:58:51 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 12 Nov 2024 01:58:51 +0000 Subject: [OpenAFS-devel] Re: kauth broken - problem with IOMGR in lwp? In-Reply-To: References: Message-ID: --_000_BYAPR07MB587991B3CF7CF2A90C1D452CA7592BYAPR07MB5879namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In continuing to research this, I see there's a lot of interesting code in = lwp that can be enabled by defining DEBUG. So just to give it a whirl, I a= dded a line to lwp.h: #define DEBUG 1 And recompiled just lwp and kauth. Now the resulting klog works. Very biz= arre... I'm not sure what to make of it yet. -Ben ________________________________ From: openafs-devel-admin@openafs.org on = behalf of Ben Huntsman Sent: Monday, November 11, 2024 12:26 PM To: openafs-devel@openafs.org Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? Hi everyone- First of all, please don't laugh, but I do have an older test cell that = runs kauth instead of krb5. This is at home, not for anything production, = so don't worry. That being said, is kauth currently broken? A colleague of mine tried i= t on Linux and gets a segfault when running klog, and I get the same behavi= or on AIX: $ dbx /usr/afs/bin/klog core Type 'help' for help. [using memory image in core] reading symbolic information ... Segmentation fault in unnamed block in IOMGR at line 362 in file "iomgr.c" 362 FD_ZERO(&IOMGR_writefds); (dbx) where libdebug assertion "(framep->getGpr(STKP, &addr) =3D=3D DB_SUCCESS && *next= Stkpp =3D=3D addr)" failed at line 1418 in file ../../../../../../../../../= ../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_= FrameProgress.C unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c" (dbx) And here's a blurb from around that line in src/lwp/iomgr.c: ... /* These are not declared in IOMGR so that they don't use up 6K of stack. *= / static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds; static int IOMGR_nfds =3D 0; static void *IOMGR(void *dummy) { for (;;) { int code; struct TM_Elem *earliest; struct timeval timeout, junk; bool woke_someone; FD_ZERO(&IOMGR_readfds); FD_ZERO(&IOMGR_writefds); FD_ZERO(&IOMGR_exceptfds); IOMGR_nfds =3D 0; ... I did the compile with the ./configure --enable-debug and -enable-debug-= lwp options specified. Can someone help explain how this code works, and w= hat might done to fix it? I'm a little fuzzy on the *IOMGR piece and I don= 't see that anyone calls IOMGR() directly in the code... Thank you! -Ben --_000_BYAPR07MB587991B3CF7CF2A90C1D452CA7592BYAPR07MB5879namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In continuing to research this, I see there's a lot of interesting code in = lwp that can be enabled by defining DEBUG. So just to give it a whirl= , I added a line to lwp.h:

#define DEBUG 1

And recompiled just lwp and kauth. Now the resulting klog works. = ; Very bizarre... I'm not sure what to make of it yet.

-Ben

From: openafs-devel-admin@o= penafs.org <openafs-devel-admin@openafs.org> on behalf of Ben Huntsma= n <ben@huntsmans.net>
Sent: Monday, November 11, 2024 12:26 PM
To: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp?

Hi everyone-

First of all, please don't laugh, but I do have an older test = cell that runs kauth instead of krb5. This is at home, not for anythi= ng production, so don't worry.

That being said, is kauth currently broken? A colleague = of mine tried it on Linux and gets a segfault when running klog, and I get = the same behavior on AIX:

$ dbx /usr/afs/bin/klog core

Type 'help' for help.

[using memory image in core]

reading symbolic information ...

Segmentation fault in unnamed block in IOMGR at line 362 in file "iomg= r.c"

362 FD_ZERO(&IOMGR_writefds);=

(dbx) where

unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c"

(dbx)

And here's a blurb from around that line in src/lwp/iomgr.c:

...

/* These are not declared in IOMGR so that they don't use up 6K of stack. *= /

static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds;

static int IOMGR_nfds =3D 0;

static void *IOMGR(void *dummy)

{

for (;;) {

int code;

struct TM_Elem *earliest;

struct timeval timeout, junk;

bool woke_someone;

FD_ZERO(&IOMGR_readfds);

FD_ZERO(&IOMGR_writefds);

FD_ZERO(&IOMGR_exceptfds);

IOMGR_nfds =3D 0;

...

Thank you!

-Ben

--_000_BYAPR07MB587991B3CF7CF2A90C1D452CA7592BYAPR07MB5879namp_-- From kaduk@mit.edu Tue Nov 12 04:21:44 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 11 Nov 2024 20:21:44 -0800 Subject: [OpenAFS-devel] Re: kauth broken - problem with IOMGR in lwp? In-Reply-To: References: Message-ID: That makes it sound like someone put some code with side effects inside an assertion statement, so that it gets compiled out in non-debug builds. In the, um, more maintained parts of the tree we are using opr_Assert() vs opr_Verify() to indicate things that do not or do always need to be executed, but it looks like kauth has not gotten such treatment. Which does make one wonder just how long it's been broken in this way... -Ben On Tue, Nov 12, 2024 at 01:58:51AM +0000, Ben Huntsman wrote: > In continuing to research this, I see there's a lot of interesting code in lwp that can be enabled by defining DEBUG. So just to give it a whirl, I added a line to lwp.h: > > #define DEBUG 1 > > And recompiled just lwp and kauth. Now the resulting klog works. Very bizarre... I'm not sure what to make of it yet. > > -Ben > > ________________________________ > From: openafs-devel-admin@openafs.org on behalf of Ben Huntsman > Sent: Monday, November 11, 2024 12:26 PM > To: openafs-devel@openafs.org > Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? > > Hi everyone- > First of all, please don't laugh, but I do have an older test cell that runs kauth instead of krb5. This is at home, not for anything production, so don't worry. > > That being said, is kauth currently broken? A colleague of mine tried it on Linux and gets a segfault when running klog, and I get the same behavior on AIX: > > $ dbx /usr/afs/bin/klog core > Type 'help' for help. > [using memory image in core] > reading symbolic information ... > > Segmentation fault in unnamed block in IOMGR at line 362 in file "iomgr.c" > 362 FD_ZERO(&IOMGR_writefds); > (dbx) where > libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)" failed at line 1418 in file ../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_FrameProgress.C > unnamed block in IOMGR(dummy = (nil)), line 362 in "iomgr.c" > (dbx) > > And here's a blurb from around that line in src/lwp/iomgr.c: > ... > /* These are not declared in IOMGR so that they don't use up 6K of stack. */ > static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds; > static int IOMGR_nfds = 0; > > static void *IOMGR(void *dummy) > { > for (;;) { > int code; > struct TM_Elem *earliest; > struct timeval timeout, junk; > bool woke_someone; > > FD_ZERO(&IOMGR_readfds); > FD_ZERO(&IOMGR_writefds); > FD_ZERO(&IOMGR_exceptfds); > IOMGR_nfds = 0; > ... > > > I did the compile with the ./configure --enable-debug and -enable-debug-lwp options specified. Can someone help explain how this code works, and what might done to fix it? I'm a little fuzzy on the *IOMGR piece and I don't see that anyone calls IOMGR() directly in the code... > > Thank you! > > -Ben > From ben@huntsmans.net Tue Nov 12 19:01:50 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 12 Nov 2024 19:01:50 +0000 Subject: [OpenAFS-devel] ticket contained unknown key version number Message-ID: --_000_BYAPR07MB587984C05E556BC11CBB0FB4A7592BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! One more issue I'm having with the kauth infrastructure on the latest bu= ild is that while I can get a ticket and browse the /afs space, if I try to= run authenticated commands against the local system, I get the following e= rror: $ bos create fs fs /usr/afs/bin/fileserver \ > /usr/afs/bin/volserver /usr/afs/bin/salvager \ > -cell bos: failed to create new server instance fs of type 'fs' (ticket contained= unknown key version number) The DB server is a Linux system running an older version of OpenAFS with= the kauth stuff. Looks to me like that message comes from src/rxkad. It = would seem that the local bossserver doesn't know that it's supposed to be = doing kauth, not krb5. Yes, I know this is bad, I'd never do it in a real = production system... Is there any way to see what the key version number is in the current ti= cket, and update the local system to recognize it? Thank you! -Ben --_000_BYAPR07MB587984C05E556BC11CBB0FB4A7592BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

One more issue I'm having with the kauth infrastructure on the= latest build is that while I can get a ticket and browse the /afs space, i= f I try to run authenticated commands against the local system, I get the f= ollowing error:

$ bos create <myhost> fs fs /usr/afs/bin/fileserver \

> /usr/afs/bin/volserver /usr/afs/bin/salvager \

> -cell <my cell>

bos: failed to create new server instance fs of type 'fs' (ticket contained= unknown key version number)

The DB server is a Linux system running an older version of Op= enAFS with the kauth stuff. Looks to me like that message comes from = src/rxkad. It would seem that the local bossserver doesn't know that = it's supposed to be doing kauth, not krb5. Yes, I know this is bad, I'd never do it in a real production system...

Is there any way to see what the key version number is in the = current ticket, and update the local system to recognize it?

Thank you!

-Ben

--_000_BYAPR07MB587984C05E556BC11CBB0FB4A7592BYAPR07MB5879namp_-- From kaduk@mit.edu Tue Nov 12 20:28:49 2024 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 12 Nov 2024 12:28:49 -0800 Subject: [OpenAFS-devel] OpenAFS Security Releases 1.8.13, 1.6.25 available Message-ID: --+h+P0yYjzIWOWv75 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The OpenAFS maintainers are happy to announce the availability of Security Releases OpenAFS 1.8.13 and OpenAFS 1.6.25. Source files can be accessed via the web at: https://www.openafs.org/release/openafs-1.8.13.html https://www.openafs.org/release/openafs-1.6.25.html or via AFS at: UNIX: /afs/grand.central.org/software/openafs/1.8.13/ UNC: \\afs\grand.central.org\software\openafs\1.8.13\ UNIX: /afs/grand.central.org/software/openafs/1.6.25/ UNC: \\afs\grand.central.org\software\openafs\1.6.25\ These releases include fixes for three security advisories: http://openafs.org/pages/security/OPENAFS-SA-2024-001.txt http://openafs.org/pages/security/OPENAFS-SA-2024-002.txt http://openafs.org/pages/security/OPENAFS-SA-2024-003.txt OPENAFS-SA-2024-001 affects cache managers where PAGs are in use; an attacker with access to a multi-user system could retrieve and use credentials from a preexisting PAG they are not authorized to access. OPENAFS-SA-2024-002 affects fileservers, with denial of service and potential information disclosure from uninitialized memory access being possible due to improper string handling in processing the RXAFS_StoreACL RPC. Analogous impact to clients is possible due to improper string handling in processing the results of the RXAFS_FetchACL RPC. OPENAFS-SA-2024-003 is a buffer overflow affecting certain RPC clients (notably, cache manager and command-line client utilities). Errors and denial of service (crashes) are the most common failure modes, though for this class of memory-safety issue there is some potential that heap manipulation could allow remote code execution. Bug reports should be filed to openafs-bugs@openafs.org. Benjamin Kaduk for the OpenAFS maintainers --+h+P0yYjzIWOWv75 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAmczunwACgkQKNmm82Tr dRL5iQwdFzeEE0C1CPJ8oXsJRPATKbBX8//RxZVBHfklLcG0IvKWcqq7+FHaWqLx OXSbX/LpR//vI8l5Y5TyfwA+FsWipbpLNtj7BX+XrleRo0xleJt/iOvWFNxWdgpg vSyLs3pTTR05b9yr7RAuxsJFsyeGuMseTOhIVH5zBOCgVgJWdrPNUv25byUVODmj dKipGKAVym6lnkuyjqPsWqcYPxFDXoZTZYlf7d52nXHjG5CU0aKUKVeXd+QgR4iw CbD7m79jE+WkJLifQv2tWHnfpYE7tRNk4sdzgLLwE22r7VlG5g7IpnZIPfiuf+bJ FApDRTi3L9TstpWXV6oo4SugEFF5wOJGwVYZ9sIal73LffbF3Lf5X5nAGOiR+fgi Z8OFcQnLD7u8BOjh1mfxVVV/OIgkJfq6l6c3mdTd9y1Mvk1aAt7NKphpn7EyJqyt 9ntCynYwfA4yyLRj6zoYuXcZaLOPLrqXL0KR2XyagK0QH9z/imCNuLB18/Sik0cR Oi7x50Nk7Y7xoQ== =5AQs -----END PGP SIGNATURE----- --+h+P0yYjzIWOWv75-- From ben@huntsmans.net Thu Nov 14 00:11:47 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Thu, 14 Nov 2024 00:11:47 +0000 Subject: [OpenAFS-devel] Re: ticket contained unknown key version number In-Reply-To: References: Message-ID: --_000_BYAPR07MB58790E2803DA308E66CB84C7A75B2BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was able to resolve this. This was me being stupid while setting up a cl= ient and I didn't have the KeyFile in place. This makes me wonder though, does every server in the cell need a unique Ke= yFile, or should it be the same on all the members? Thank you! --_000_BYAPR07MB58790E2803DA308E66CB84C7A75B2BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I was able to resolve this. This was me being stupid while setting up= a client and I didn't have the KeyFile in place.

This makes me wonder though, does every server in the cell need a unique Ke= yFile, or should it be the same on all the members?

Thank you!

--_000_BYAPR07MB58790E2803DA308E66CB84C7A75B2BYAPR07MB5879namp_-- From ben@huntsmans.net Thu Nov 14 00:19:45 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Thu, 14 Nov 2024 00:19:45 +0000 Subject: [OpenAFS-devel] Re: kauth broken - problem with IOMGR in lwp? In-Reply-To: References: Message-ID: --_000_BYAPR07MB587902A276B8312871245D4DA75B2BYAPR07MB5879namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there! I've been looking through the commit logs for the files in src/lwp to se= e if there is any indication as to what introduced this issue, but there's = not very much. The old Linux server I have participating in the old kauth = cell is running OpenAFS 1.6.13, so that's ~circa July 2015. Therefore the = changes would have to be between then and now. While I'm building this on = AIX, another person I know had the same problem on Linux, so it is not a pl= atform-specific issue. Any idea how to track it down? This is made more difficult by the limit= ed debugger output. Thank you! -Ben ________________________________ From: Benjamin Kaduk Sent: Monday, November 11, 2024 8:21 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Re: kauth broken - problem with IOMGR in lwp? That makes it sound like someone put some code with side effects inside an assertion statement, so that it gets compiled out in non-debug builds. In the, um, more maintained parts of the tree we are using opr_Assert() vs opr_Verify() to indicate things that do not or do always need to be executed, but it looks like kauth has not gotten such treatment. Which does make one wonder just how long it's been broken in this way... -Ben On Tue, Nov 12, 2024 at 01:58:51AM +0000, Ben Huntsman wrote: > In continuing to research this, I see there's a lot of interesting code i= n lwp that can be enabled by defining DEBUG. So just to give it a whirl, I= added a line to lwp.h: > > #define DEBUG 1 > > And recompiled just lwp and kauth. Now the resulting klog works. Very b= izarre... I'm not sure what to make of it yet. > > -Ben > > ________________________________ > From: openafs-devel-admin@openafs.org o= n behalf of Ben Huntsman > Sent: Monday, November 11, 2024 12:26 PM > To: openafs-devel@openafs.org > Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? > > Hi everyone- > First of all, please don't laugh, but I do have an older test cell tha= t runs kauth instead of krb5. This is at home, not for anything production= , so don't worry. > > That being said, is kauth currently broken? A colleague of mine tried= it on Linux and gets a segfault when running klog, and I get the same beha= vior on AIX: > > $ dbx /usr/afs/bin/klog core > Type 'help' for help. > [using memory image in core] > reading symbolic information ... > > Segmentation fault in unnamed block in IOMGR at line 362 in file "iomgr.c= " > 362 FD_ZERO(&IOMGR_writefds); > (dbx) where > libdebug assertion "(framep->getGpr(STKP, &addr) =3D=3D DB_SUCCESS && *ne= xtStkpp =3D=3D addr)" failed at line 1418 in file ../../../../../../../../.= ./../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackd= b_FrameProgress.C > unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c" > (dbx) > > And here's a blurb from around that line in src/lwp/iomgr.c: > ... > /* These are not declared in IOMGR so that they don't use up 6K of stack.= */ > static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds; > static int IOMGR_nfds =3D 0; > > static void *IOMGR(void *dummy) > { > for (;;) { > int code; > struct TM_Elem *earliest; > struct timeval timeout, junk; > bool woke_someone; > > FD_ZERO(&IOMGR_readfds); > FD_ZERO(&IOMGR_writefds); > FD_ZERO(&IOMGR_exceptfds); > IOMGR_nfds =3D 0; > ... > > > I did the compile with the ./configure --enable-debug and -enable-debu= g-lwp options specified. Can someone help explain how this code works, and= what might done to fix it? I'm a little fuzzy on the *IOMGR piece and I d= on't see that anyone calls IOMGR() directly in the code... > > Thank you! > > -Ben > --_000_BYAPR07MB587902A276B8312871245D4DA75B2BYAPR07MB5879namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

I've been looking through the commit logs for the files in src= /lwp to see if there is any indication as to what introduced this issue, bu= t there's not very much. The old Linux server I have participating in= the old kauth cell is running OpenAFS 1.6.13, so that's ~circa July 2015. Therefore the changes would have to be b= etween then and now. While I'm building this on AIX, another person I= know had the same problem on Linux, so it is not a platform-specific issue= .

Any idea how to track it down? This is made more difficu= lt by the limited debugger output.

Thank you!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Monday, November 11, 2024 8:21 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Re: kauth broken - problem with IOMGR i= n lwp?

That makes it sound like someone put some code wit= h side effects inside an
assertion statement, so that it gets compiled out in non-debug builds.
In the, um, more maintained parts of the tree we are using opr_Assert()
vs opr_Verify() to indicate things that do not or do always need to be
executed, but it looks like kauth has not gotten such treatment.
Which does make one wonder just how long it's been broken in this way...
-Ben

On Tue, Nov 12, 2024 at 01:58:51AM +0000, Ben Huntsman wrote:
> In continuing to research this, I see there's a lot of interesting cod= e in lwp that can be enabled by defining DEBUG. So just to give it a = whirl, I added a line to lwp.h:
>
> #define DEBUG 1
>
> And recompiled just lwp and kauth. Now the resulting klog works.= Very bizarre... I'm not sure what to make of it yet.
>
> -Ben
>
> ________________________________
> From: openafs-devel-admin@openafs.org <openafs-devel-admin@openafs.= org> on behalf of Ben Huntsman <ben@huntsmans.net>
> Sent: Monday, November 11, 2024 12:26 PM
> To: openafs-devel@openafs.org <openafs-devel@openafs.org>
> Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp?
>
> Hi everyone-
>    First of all, please don't laugh, but I do have an o= lder test cell that runs kauth instead of krb5. This is at home, not = for anything production, so don't worry.
>
>    That being said, is kauth currently broken? A = colleague of mine tried it on Linux and gets a segfault when running klog, = and I get the same behavior on AIX:
>
> $ dbx /usr/afs/bin/klog core
> Type 'help' for help.
> [using memory image in core]
> reading symbolic information ...
>
> Segmentation fault in unnamed block in IOMGR at line 362 in file "= ;iomgr.c"
>   362         &= nbsp; FD_ZERO(&IOMGR_writefds);
> (dbx) where
> libdebug assertion "(framep->getGpr(STKP, &addr) =3D=3D DB= _SUCCESS && *nextStkpp =3D=3D addr)" failed at line 1418 in fi= le ../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/mod= ules/stackdebug/POWER/stackdb_FrameProgress.C
> unnamed block in IOMGR(dummy =3D (nil)), line 362 in "iomgr.c&quo= t;
> (dbx)
>
> And here's a blurb from around that line in src/lwp/iomgr.c:
> ...
> /* These are not declared in IOMGR so that they don't use up 6K of sta= ck. */
> static fd_set IOMGR_readfds, IOMGR_writefds, IOMGR_exceptfds;
> static int IOMGR_nfds =3D 0;
>
> static void *IOMGR(void *dummy)
> {
>     for (;;) {
>         int code;
>         struct TM_Elem *earlie= st;
>         struct timeval timeout= , junk;
>         bool woke_someone;
>
>         FD_ZERO(&IOMGR_rea= dfds);
>         FD_ZERO(&IOMGR_wri= tefds);
>         FD_ZERO(&IOMGR_exc= eptfds);
>         IOMGR_nfds =3D 0;
> ...
>
>
>    I did the compile with the ./configure --enable-debu= g and -enable-debug-lwp options specified. Can someone help explain h= ow this code works, and what might done to fix it? I'm a little fuzzy= on the *IOMGR piece and I don't see that anyone calls IOMGR() directly in the code...
>
> Thank you!
>
> -Ben
>

--_000_BYAPR07MB587902A276B8312871245D4DA75B2BYAPR07MB5879namp_-- From jaltman@auristor.com Thu Nov 14 01:02:23 2024 From: jaltman@auristor.com (Jeffrey Altman) Date: Wed, 13 Nov 2024 20:02:23 -0500 Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? In-Reply-To: References: Message-ID: --Apple-Mail=_1305BDEC-4477-4ABA-87C1-0A2A12C03ED2 Content-Type: multipart/alternative; boundary="Apple-Mail=_DD29048A-5FEB-44C2-A4B6-C04D458FF45A" --Apple-Mail=_DD29048A-5FEB-44C2-A4B6-C04D458FF45A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2024, at 7:19=E2=80=AFPM, Ben Huntsman = wrote: >=20 > Any idea how to track it down? This is made more difficult by the = limited debugger output. >=20 git bisect from a known working version to a known broken version. --Apple-Mail=_DD29048A-5FEB-44C2-A4B6-C04D458FF45A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 13, = 2024, at 7:19=E2=80=AFPM, Ben Huntsman <ben@huntsmans.net> = wrote:

Any idea how to track it down? This is made = more difficult by the limited debugger output.

git bisect from a = known working version to a known broken = version.

= --Apple-Mail=_DD29048A-5FEB-44C2-A4B6-C04D458FF45A-- --Apple-Mail=_1305BDEC-4477-4ABA-87C1-0A2A12C03ED2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDHEw ggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJBgNVBAYT AlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMB4XDTIyMDgw NDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0EwMTQxMEQwMDAwMDE4 MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRtYW4xFTATBgNVBAoTDEF1 cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCk C7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3xHZRtv179LHKAOcsY2jIctzieMxf 82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyNfO/wJ0rX7G+ges22Dd7goZul8rPaTJBI xbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kIEEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq 4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6 W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjGIcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAw gYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2Nl cnRzL3RydXN0aWRjYWExMy5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYD VR0TBAIwADCCASsGA1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIB Fj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5k ZXguaHRtbDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJl ZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmlj YXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRh dGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQYMBaBFGphbHRt YW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2sgjAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwVeycprp8Ox1npiTyfwc5Q aVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4cWLeQfaMrnyNeEuvHx/2CT44c dLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYqutYF4Chkxu4KzIpq90eDMw5ajkex w+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJoQle4wDxrdXdnIhCP7g87InXKefWgZBF4 VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXta8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRk gIGb319a7FjslV8wggaXMIIEf6ADAgECAhBAAXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBD b21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6i xaNP0JKSjTd+SG5LwqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6i qgB63OdHxBN/15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxl g+m1Vjgno1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi 2un03bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkGCCsG AQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3Qu Y29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2Nv bW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djCCASQG A1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlk ZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG6BggrBgEFBQcC AjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0 IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20v Y3JsL2NvbW1lcmNpYWxyb290Y2ExLmNybDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX 6Nl4a03cDHt7TLdPxCzFvDF2bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN 95jUXLdLPRToNxyaoB5s0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24 GBqqVudvPRLyMJ7u6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azN BkfnbRq+0e88QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8Hvgn LCBFK2s4Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXF C9budb9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4dUsZy Tk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJnp/BscizY dNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eAMDGCAqYwggKi AgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCgggEpMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI0MTExNDAxMDIyNFowLwYJKoZIhvcNAQkE MSIEIHM+1gyhnaFcGNOwkBMPFSPiKseR0lLwnkIocBIWh03hMF0GCSsGAQQBgjcQBDFQME4wOjEL MAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMC EEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzM MA0GCSqGSIb3DQEBCwUABIIBABJrVnJHylc0nWVYU+isc3VeDqvBSb4Jdylj/u2hXPZ7KsFgRKDM um8lZjD6purW+/V14OWZ9W05nUrKA4zIj656OT0Dpp43FdOtJ/XH06OXOy0oGZBEDbbS3gUTEqBC MTQkciOIsmafU4PJ+9uAEoO+rjiwjmdOsLn8v66ayTjZTCIy8xW8qO+lXEOMNmsYbdo7R4MxRytR Mmw+hldS7sYN4wFzP1CDNMnZy84CytrPcBvd7Ky/TZ3CeRCpK5KZdWTDpnVJyHgUC2wKOMdIaxVd NmxyVsS3zGRuNytD2oYgwrOEE9lpduqhtKB1LFNbr2rhShvzbz5ENOqxJiplMgEAAAAAAAA= --Apple-Mail=_1305BDEC-4477-4ABA-87C1-0A2A12C03ED2-- From jaltman@auristor.com Thu Nov 14 02:45:45 2024 From: jaltman@auristor.com (Jeffrey Altman) Date: Wed, 13 Nov 2024 21:45:45 -0500 Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? In-Reply-To: References:

Message-ID: <58200A1C-5665-4F3F-A6CC-95A8919F2474@auristor.com> --Apple-Mail=_74022820-1F2B-4D05-B964-641182CF32E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_C4952796-AA36-4516-9C66-6ED2F2D17CD6" --Apple-Mail=_C4952796-AA36-4516-9C66-6ED2F2D17CD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2024, at 8:02=E2=80=AFPM, Jeffrey Altman = wrote: >=20 >=20 >> On Nov 13, 2024, at 7:19=E2=80=AFPM, Ben Huntsman = wrote: >>=20 >> Any idea how to track it down? This is made more difficult by the = limited debugger output. >>=20 >=20 > git bisect from a known working version to a known broken version. Git bisect is going to be the best option because there was five years = of significant development between when the 1.6 series was cut from = master and when the 1.8 series was cut from master. =20 I think the first question to answer is whether or not the failure case = was present at the point where the openafs-stable-1_8_x branch forked = from master. =20 commit e739eaa650ee30dcce54d05908b062839eafbf73 (tag: = BP-openafs-stable-1_8_x) If it was working there, then bisect along the openafs-stable_1_8_x = branch to find the commit where things break for the first time. If it was not working there, then bisect the master branch from the = point where the openafs-stable-1_6_x branch forked. =20 commit c89bc695707f62e64f64b3abb15470b291f613a1 (tag: = BP-openafs-stable-1_6_x) LWP is hard to debug because it is a custom cooperative threading model = which is not going to be understood by debuggers. In OpenAFS 1.8.x the commonly used command line tools although built for = both LWP and pthreads are going to be distributed as the pthreads = version. There is no pthreads build of klog. It=E2=80=99s quite = possible the breakage is to all LWP clients and not specific to kauth. = One thought that comes to mind is whether the difference is in how = OpenAFS is being built. For example, was the 1.6.13 build that = succeeded 32-bit vs the 1.8 build being 64-bit? --Apple-Mail=_C4952796-AA36-4516-9C66-6ED2F2D17CD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 13, = 2024, at 8:02=E2=80=AFPM, Jeffrey Altman <jaltman@auristor.com> = wrote:

On= Nov 13, 2024, at 7:19=E2=80=AFPM, Ben Huntsman = <ben@huntsmans.net> wrote:

Any idea how to track it = down? This is made more difficult by the limited debugger = output.

git bisect from a = known working version to a known broken = version.

Git bisect is = going to be the best option because there was five years of significant = development between when the 1.6 series was cut from master and when the = 1.8 series was cut from master.

I = think the first question to answer is whether or not the failure case = was present at the point where the openafs-stable-1_8_x branch forked = from master.

commit = e739eaa650ee30dcce54d05908b062839eafbf73 (tag: = BP-openafs-stable-1_8_x)

If it was working = there, then bisect along the openafs-stable_1_8_x branch to find the = commit where things break for the first time.

If it was not = working there, then bisect the master branch from the point where the = openafs-stable-1_6_x branch forked. =

commit = c89bc695707f62e64f64b3abb15470b291f613a1 (tag: = BP-openafs-stable-1_6_x)

LWP is hard to debug = because it is a custom cooperative threading model which is not going to = be understood by debuggers.

In OpenAFS 1.8.x = the commonly used command line tools although built for both LWP and = pthreads are going to be distributed as the pthreads version. = There is no pthreads build of klog. It=E2=80=99s quite = possible the breakage is to all LWP clients and not specific to kauth. = One thought that comes to mind is whether the difference is in how = OpenAFS is being built. For example, was the 1.6.13 build that = succeeded 32-bit vs the 1.8 build being = 64-bit?

= --Apple-Mail=_C4952796-AA36-4516-9C66-6ED2F2D17CD6-- --Apple-Mail=_74022820-1F2B-4D05-B964-641182CF32E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDHEw ggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJBgNVBAYT AlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMB4XDTIyMDgw NDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0EwMTQxMEQwMDAwMDE4 MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRtYW4xFTATBgNVBAoTDEF1 cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCk C7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3xHZRtv179LHKAOcsY2jIctzieMxf 82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyNfO/wJ0rX7G+ges22Dd7goZul8rPaTJBI xbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kIEEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq 4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6 W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjGIcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAw gYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2Nl cnRzL3RydXN0aWRjYWExMy5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYD VR0TBAIwADCCASsGA1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIB Fj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5k ZXguaHRtbDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJl ZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmlj YXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRh dGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQYMBaBFGphbHRt YW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2sgjAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwVeycprp8Ox1npiTyfwc5Q aVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4cWLeQfaMrnyNeEuvHx/2CT44c dLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYqutYF4Chkxu4KzIpq90eDMw5ajkex w+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJoQle4wDxrdXdnIhCP7g87InXKefWgZBF4 VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXta8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRk gIGb319a7FjslV8wggaXMIIEf6ADAgECAhBAAXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBD b21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6i xaNP0JKSjTd+SG5LwqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6i qgB63OdHxBN/15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxl g+m1Vjgno1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi 2un03bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkGCCsG AQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3Qu Y29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2Nv bW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djCCASQG A1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlk ZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG6BggrBgEFBQcC AjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0 IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20v Y3JsL2NvbW1lcmNpYWxyb290Y2ExLmNybDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX 6Nl4a03cDHt7TLdPxCzFvDF2bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN 95jUXLdLPRToNxyaoB5s0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24 GBqqVudvPRLyMJ7u6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azN BkfnbRq+0e88QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8Hvgn LCBFK2s4Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXF C9budb9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4dUsZy Tk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJnp/BscizY dNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eAMDGCAqYwggKi AgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCgggEpMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI0MTExNDAyNDU0NVowLwYJKoZIhvcNAQkE MSIEIL4QiWQUKs7SKtKL9gUpP/z4/FuUs2hPxmNapQ5vM890MF0GCSsGAQQBgjcQBDFQME4wOjEL MAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMC EEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzM MA0GCSqGSIb3DQEBCwUABIIBAEjaRcPL6tEhXFMWawiti68wt+9bnsk7PYMzO5pgY1hj1dyGX4cX 6vPufvwO+9BD484YHLaGlD3HIR/1X90XuqyjqTQbehkA6MZOzgNzAd21yHikNdhBr83ZCOI47uX/ BKxJqMSXyyFneMwpPqADOjEzq1noXRDMduZySULoqhWe7/GJ7VMGsv7j6yiWHWUEXAAdMBqpe3lt e1tKlaHfdl1v71tZTedD+r2XvqLmT5tkCEmKbPZZEklBd75VnYfQ52yopVRnQ25L5i9HLNyHR9BZ e6+0s117qgHqaw6ulBtRZej28uK4E0wv2IqAOJCiObH1337kElgxVZ0gHIFKZ5kAAAAAAAA= --Apple-Mail=_74022820-1F2B-4D05-B964-641182CF32E7-- From ben@huntsmans.net Thu Nov 14 02:50:04 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Thu, 14 Nov 2024 02:50:04 +0000 Subject: [OpenAFS-devel] kauth broken - problem with IOMGR in lwp? In-Reply-To: <58200A1C-5665-4F3F-A6CC-95A8919F2474@auristor.com> References:

<58200A1C-5665-4F3F-A6CC-95A8919F2474@auristor.com> Message-ID: --_000_C79ABF2A5C894B88A251C888EA49CD1Ahuntsmansnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgdGhlcmUhDQogICBUaGFua3MgZm9yIHRoYXQgYXdlc29tZSB0aXAhISAgSeKAmXZlIG5ldmVy IGhlYXJkIG9mIGdpdCBiaXNlY3QgYmVmb3JlIGFuZCBJ4oCZbSBleGNpdGVkIHRvIGdpdmUgaXQg YSB0cnkhDQoNCiAgIFRoZSBidWcgaXMgcHJlc2VudCBpbiBhbGwgdGhlIGthdXRoIHRvb2xzLCBu b3QganVzdCBrbG9nLiAgS2xvZyB3YXMganVzdCB0aGUgbW9zdCBjb252ZW5pZW50IGJlY2F1c2Ug aXTigJlzIHRoZSBvbmx5IG9uZSBJIG5lZWQsIGJ1dCB0aGUgb3RoZXIgcGVyc29uIEkgd2FzIHdv cmtpbmcgd2l0aCBzYXcgaXQgaW4gYWxsIG9mIHRoZW0uDQoNCiAgIEkgd2lsbCBnaXZlIGl0IGEg dHJ5IG92ZXIgdGhlIG5leHQgY291cGxlIG9mIGRheXMhDQoNClRoYW5rcyBhZ2FpbiEhDQoNCi1C ZW4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBOb3YgMTMsIDIwMjQsIGF0IDY6NDYgUE0s IEplZmZyZXkgQWx0bWFuIDxqYWx0bWFuQGF1cmlzdG9yLmNvbT4gd3JvdGU6DQoNCu+7vw0KT24g Tm92IDEzLCAyMDI0LCBhdCA4OjAy4oCvUE0sIEplZmZyZXkgQWx0bWFuIDxqYWx0bWFuQGF1cmlz dG9yLmNvbT4gd3JvdGU6DQoNCg0KT24gTm92IDEzLCAyMDI0LCBhdCA3OjE54oCvUE0sIEJlbiBI dW50c21hbiA8YmVuQGh1bnRzbWFucy5uZXQ+IHdyb3RlOg0KDQogICBBbnkgaWRlYSBob3cgdG8g dHJhY2sgaXQgZG93bj8gIFRoaXMgaXMgbWFkZSBtb3JlIGRpZmZpY3VsdCBieSB0aGUgbGltaXRl ZCBkZWJ1Z2dlciBvdXRwdXQuDQoNCg0KZ2l0IGJpc2VjdCBmcm9tIGEga25vd24gd29ya2luZyB2 ZXJzaW9uIHRvIGEga25vd24gYnJva2VuIHZlcnNpb24uDQoNCkdpdCBiaXNlY3QgaXMgZ29pbmcg dG8gYmUgdGhlIGJlc3Qgb3B0aW9uIGJlY2F1c2UgdGhlcmUgd2FzIGZpdmUgeWVhcnMgb2Ygc2ln bmlmaWNhbnQgZGV2ZWxvcG1lbnQgYmV0d2VlbiB3aGVuIHRoZSAxLjYgc2VyaWVzIHdhcyBjdXQg ZnJvbSBtYXN0ZXIgYW5kIHdoZW4gdGhlIDEuOCBzZXJpZXMgd2FzIGN1dCBmcm9tIG1hc3Rlci4N Cg0KSSB0aGluayB0aGUgZmlyc3QgcXVlc3Rpb24gdG8gYW5zd2VyIGlzIHdoZXRoZXIgb3Igbm90 IHRoZSBmYWlsdXJlIGNhc2Ugd2FzIHByZXNlbnQgYXQgdGhlIHBvaW50IHdoZXJlIHRoZSBvcGVu YWZzLXN0YWJsZS0xXzhfeCBicmFuY2ggZm9ya2VkIGZyb20gbWFzdGVyLg0KDQogIGNvbW1pdCBl NzM5ZWFhNjUwZWUzMGRjY2U1NGQwNTkwOGIwNjI4MzllYWZiZjczICh0YWc6IEJQLW9wZW5hZnMt c3RhYmxlLTFfOF94KQ0KDQpJZiBpdCB3YXMgd29ya2luZyB0aGVyZSwgdGhlbiBiaXNlY3QgYWxv bmcgdGhlIG9wZW5hZnMtc3RhYmxlXzFfOF94IGJyYW5jaCB0byBmaW5kIHRoZSBjb21taXQgd2hl cmUgdGhpbmdzIGJyZWFrIGZvciB0aGUgZmlyc3QgdGltZS4NCklmIGl0IHdhcyBub3Qgd29ya2lu ZyB0aGVyZSwgdGhlbiBiaXNlY3QgdGhlIG1hc3RlciBicmFuY2ggZnJvbSB0aGUgcG9pbnQgd2hl cmUgdGhlIG9wZW5hZnMtc3RhYmxlLTFfNl94IGJyYW5jaCBmb3JrZWQuDQoNCiAgY29tbWl0IGM4 OWJjNjk1NzA3ZjYyZTY0ZjY0YjNhYmIxNTQ3MGIyOTFmNjEzYTEgKHRhZzogQlAtb3BlbmFmcy1z dGFibGUtMV82X3gpDQoNCkxXUCBpcyBoYXJkIHRvIGRlYnVnIGJlY2F1c2UgaXQgaXMgYSBjdXN0 b20gY29vcGVyYXRpdmUgdGhyZWFkaW5nIG1vZGVsIHdoaWNoIGlzIG5vdCBnb2luZyB0byBiZSB1 bmRlcnN0b29kIGJ5IGRlYnVnZ2Vycy4NCg0KSW4gT3BlbkFGUyAxLjgueCB0aGUgY29tbW9ubHkg dXNlZCBjb21tYW5kIGxpbmUgdG9vbHMgYWx0aG91Z2ggYnVpbHQgZm9yIGJvdGggTFdQIGFuZCBw dGhyZWFkcyBhcmUgZ29pbmcgdG8gYmUgZGlzdHJpYnV0ZWQgYXMgdGhlIHB0aHJlYWRzIHZlcnNp b24uICBUaGVyZSBpcyBubyBwdGhyZWFkcyBidWlsZCBvZiBrbG9nLiAgIEl04oCZcyBxdWl0ZSBw b3NzaWJsZSB0aGUgYnJlYWthZ2UgaXMgdG8gYWxsIExXUCBjbGllbnRzIGFuZCBub3Qgc3BlY2lm aWMgdG8ga2F1dGguICBPbmUgdGhvdWdodCB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgd2hldGhlciB0 aGUgZGlmZmVyZW5jZSBpcyBpbiBob3cgT3BlbkFGUyBpcyBiZWluZyBidWlsdC4gIEZvciBleGFt cGxlLCB3YXMgdGhlIDEuNi4xMyBidWlsZCB0aGF0IHN1Y2NlZWRlZCAzMi1iaXQgdnMgdGhlIDEu OCBidWlsZCBiZWluZyA2NC1iaXQ/DQoNCg0K --_000_C79ABF2A5C894B88A251C888EA49CD1Ahuntsmansnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI aSB0aGVyZSENCjxkaXY+Jm5ic3A7ICZuYnNwO1RoYW5rcyBmb3IgdGhhdCBhd2Vzb21lIHRpcCEh ICZuYnNwO0nigJl2ZSBuZXZlciBoZWFyZCBvZiBnaXQgYmlzZWN0IGJlZm9yZSBhbmQgSeKAmW0g ZXhjaXRlZCB0byBnaXZlIGl0IGEgdHJ5ITwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7ICZuYnNwO1RoZSBidWcgaXMgcHJlc2VudCBpbiBhbGwgdGhlIGthdXRoIHRvb2xzLCBu b3QganVzdCBrbG9nLiAmbmJzcDtLbG9nIHdhcyBqdXN0IHRoZSBtb3N0IGNvbnZlbmllbnQgYmVj YXVzZSBpdOKAmXMgdGhlIG9ubHkgb25lIEkgbmVlZCwgYnV0IHRoZSBvdGhlciBwZXJzb24gSSB3 YXMgd29ya2luZyB3aXRoIHNhdyBpdCBpbiBhbGwgb2YgdGhlbS4gJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7SSB3aWxsIGdpdmUgaXQgYSB0cnkgb3Zl ciB0aGUgbmV4dCBjb3VwbGUgb2YgZGF5cyE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoYW5rcyBhZ2FpbiEhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tQmVuPGJyPg0K PGJyPg0KPGRpdiBkaXI9Imx0ciI+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gTm92IDEzLCAyMDI0LCBhdCA2 OjQ2IFBNLCBKZWZmcmV5IEFsdG1hbiAmbHQ7amFsdG1hbkBhdXJpc3Rvci5jb20mZ3Q7IHdyb3Rl Ojxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu788YnI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2Pk9uIE5vdiAxMywgMjAyNCwgYXQgODowMuKAr1BNLCBKZWZmcmV5IEFsdG1hbiAm bHQ7amFsdG1hbkBhdXJpc3Rvci5jb20mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyI+DQo8YnI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2Pk9uIE5vdiAxMywgMjAyNCwgYXQgNzoxOeKAr1BNLCBCZW4gSHVudHNtYW4gJmx0O2JlbkBo dW50c21hbnMubmV0Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJlbGVtZW50 VG9Qcm9vZiIgc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBBcHRvcywgQXB0b3Nf RW1iZWRkZWRGb250LCBBcHRvc19NU0ZvbnRTZXJ2aWNlLCBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJl bGVtZW50VG9Qcm9vZiIgc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBBcHRvcywg QXB0b3NfRW1iZWRkZWRGb250LCBBcHRvc19NU0ZvbnRTZXJ2aWNlLCBDYWxpYnJpLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7ICZuYnNwO0FueSBpZGVh IGhvdyB0byB0cmFjayBpdCBkb3duPyZuYnNwOyBUaGlzIGlzIG1hZGUgbW9yZSBkaWZmaWN1bHQg YnkgdGhlIGxpbWl0ZWQgZGVidWdnZXIgb3V0cHV0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iZWxlbWVu dFRvUHJvb2YiIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogQXB0b3MsIEFwdG9z X0VtYmVkZGVkRm9udCwgQXB0b3NfTVNGb250U2VydmljZSwgQ2FsaWJyaSwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+Z2l0IGJpc2VjdCBmcm9tIGEga25vd24gd29y a2luZyB2ZXJzaW9uIHRvIGEga25vd24gYnJva2VuIHZlcnNpb24uPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8ZGl2PkdpdCBiaXNlY3QgaXMgZ29p bmcgdG8gYmUgdGhlIGJlc3Qgb3B0aW9uIGJlY2F1c2UgdGhlcmUgd2FzIGZpdmUgeWVhcnMgb2Yg c2lnbmlmaWNhbnQgZGV2ZWxvcG1lbnQgYmV0d2VlbiB3aGVuIHRoZSAxLjYgc2VyaWVzIHdhcyBj dXQgZnJvbSBtYXN0ZXIgYW5kIHdoZW4gdGhlIDEuOCBzZXJpZXMgd2FzIGN1dCBmcm9tIG1hc3Rl ci4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRo ZSBmaXJzdCBxdWVzdGlvbiB0byBhbnN3ZXIgaXMgd2hldGhlciBvciBub3QgdGhlIGZhaWx1cmUg Y2FzZSB3YXMgcHJlc2VudCBhdCB0aGUgcG9pbnQgd2hlcmUgdGhlIG9wZW5hZnMtc3RhYmxlLTFf OF94IGJyYW5jaCBmb3JrZWQgZnJvbSBtYXN0ZXIuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Y29tbWl0IGU3MzllYWE2NTBlZTMwZGNjZTU0ZDA1OTA4 YjA2MjgzOWVhZmJmNzMgKHRhZzogQlAtb3BlbmFmcy1zdGFibGUtMV84X3gpPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBpdCB3YXMgd29ya2luZyB0aGVyZSwgdGhlbiBiaXNlY3Qg YWxvbmcgdGhlIG9wZW5hZnMtc3RhYmxlXzFfOF94IGJyYW5jaCB0byBmaW5kIHRoZSBjb21taXQg d2hlcmUgdGhpbmdzIGJyZWFrIGZvciB0aGUgZmlyc3QgdGltZS48L2Rpdj4NCjxkaXY+SWYgaXQg d2FzIG5vdCB3b3JraW5nIHRoZXJlLCB0aGVuIGJpc2VjdCB0aGUgbWFzdGVyIGJyYW5jaCBmcm9t IHRoZSBwb2ludCB3aGVyZSB0aGUgb3BlbmFmcy1zdGFibGUtMV82X3ggYnJhbmNoIGZvcmtlZC4g Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgY29tbWl0IGM4OWJj Njk1NzA3ZjYyZTY0ZjY0YjNhYmIxNTQ3MGIyOTFmNjEzYTEgKHRhZzogQlAtb3BlbmFmcy1zdGFi bGUtMV82X3gpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5MV1AgaXMgaGFyZCB0byBk ZWJ1ZyBiZWNhdXNlIGl0IGlzIGEgY3VzdG9tIGNvb3BlcmF0aXZlIHRocmVhZGluZyBtb2RlbCB3 aGljaCBpcyBub3QgZ29pbmcgdG8gYmUgdW5kZXJzdG9vZCBieSBkZWJ1Z2dlcnMuPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBPcGVuQUZTIDEuOC54IHRoZSBjb21tb25seSB1c2Vk IGNvbW1hbmQgbGluZSB0b29scyBhbHRob3VnaCBidWlsdCBmb3IgYm90aCBMV1AgYW5kIHB0aHJl YWRzIGFyZSBnb2luZyB0byBiZSBkaXN0cmlidXRlZCBhcyB0aGUgcHRocmVhZHMgdmVyc2lvbi4g Jm5ic3A7VGhlcmUgaXMgbm8gcHRocmVhZHMgYnVpbGQgb2Yga2xvZy4gJm5ic3A7IEl04oCZcyBx dWl0ZSBwb3NzaWJsZSB0aGUgYnJlYWthZ2UgaXMgdG8gYWxsIExXUCBjbGllbnRzIGFuZCBub3Qg c3BlY2lmaWMNCiB0byBrYXV0aC4gJm5ic3A7T25lIHRob3VnaHQgdGhhdCBjb21lcyB0byBtaW5k IGlzIHdoZXRoZXIgdGhlIGRpZmZlcmVuY2UgaXMgaW4gaG93IE9wZW5BRlMgaXMgYmVpbmcgYnVp bHQuICZuYnNwO0ZvciBleGFtcGxlLCB3YXMgdGhlIDEuNi4xMyBidWlsZCB0aGF0IHN1Y2NlZWRl ZCAzMi1iaXQgdnMgdGhlIDEuOCBidWlsZCBiZWluZyA2NC1iaXQ/PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C79ABF2A5C894B88A251C888EA49CD1Ahuntsmansnet_-- From mvitale@sinenomine.net Thu Nov 14 20:43:57 2024 From: mvitale@sinenomine.net (MS Vitale) Date: Thu, 14 Nov 2024 15:43:57 -0500 Subject: [OpenAFS-devel] ticket contained unknown key version number In-Reply-To: References: Message-ID: <0FB99673-D558-4C3A-AE93-B5CF0B3914B6@sinenomine.net> --Apple-Mail=_A681DB7C-1290-4E91-B42B-88B4D8066A37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ben, > On Nov 13, 2024, at 7:11 PM, Ben Huntsman wrote: >=20 > I was able to resolve this. This was me being stupid while setting up = a client and I didn't have the KeyFile in place. >=20 > This makes me wonder though, does every server in the cell need a = unique KeyFile, or should it be the same on all the members? The KeyFile (and/or KeyFileExt) should be the same on all OpenAFS = servers. Regards, -- Mark Vitale Sine Nomine Associates --Apple-Mail=_A681DB7C-1290-4E91-B42B-88B4D8066A37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEJ5FuPE2qwhz7OesakXti0Cxwc2YFAmc2YQ0ACgkQkXti0Cxw c2aC3xAAwm+lf2z2YaEJbUizGzCVLtwIgdPZb78jvQp0U5HgfeI5f1+ri8xXI2g3 DbcZZzTFORXlSrWLPT7tyLGdgj4xB7cVsQuho7rH2cvcqdhsQZVTDUnZWuB694ra 303toInHvYTgqGyRkEgOC+nvAlHMVxGWDyt2cEvy5HzPjSG1nYDjSgEfhJyO7Xc/ VWzZK+55WqSyPTVgjclMc4GDAUSX7DdPNAqhmX1lLd+Uu78MfNuAfcCQ2FEfXbrl GATEuD7sWLueok0nAdJx2IIehT+iFVZiISrbWu4DtASgTRqPWiCDBfkVAJOkC7SH x4OC1Z1maWZAEpmGsPB4aqC3H88kgg8o7JQhLuYTwR6ovR78MYeRy/3j3wyYiMh0 yrdQNfvm6cJVYRU4D7foqjkXaFd2QnpBOnl5RGcCC97INvaBNohaanKshNtWVOn7 tEySNO87Ox/b69BtliTUW6vxzg2vA1Yf4e5QgFUVo16S9fUbhbNbrV+lWp12CH6V 8Dt0hXsi/fRzRzpIhfXbiMToHAZMDsE5HrF0R9GHmUlNXXEcj7cDG6CWApzbhkCW /fBwOmrHYMTXGvYwWJemCvDD8aROTCpMYJ67+nZqJbmAs/Fofg5VLYo+dIhwNz7p NhD5S31Q4Nn+TfT8A+TedX11cNEGmHodnXTaxpcv9Rtpwt+n8Do= =MTf4 -----END PGP SIGNATURE----- --Apple-Mail=_A681DB7C-1290-4E91-B42B-88B4D8066A37-- From mmeffie@sinenomine.net Thu Nov 21 18:19:29 2024 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 21 Nov 2024 13:19:29 -0500 Subject: [OpenAFS-devel] OpenAFS Release Team weekly meeting Message-ID: <20241121131929.c0fdf0c1fd37ba90c8229dd1@sinenomine.net> OpenAFS Release Team weekly meeting Date: November 21, 2024 Participants: - Stephan Wiesand, OpenAFS Release Manager - Ben Kaduk - Cheyenne Wills - Michael Meffie - Mark Vitale The OpenAFS Release Team meetings are held each Thursday at 12:00pm Eastern, 9:00am Pacific on Libera.Chat IRC channel #openafs-releaseteam. Release team working status is maintained at: https://wiki.openafs.org/devel/Whiteboard/ Discussion ========== Changes for 1.8.13.1 have been submitted and reviewed on gerrit: * Support for Linux 6.12 * Build fix for AIX Various changes have been merged to master and are in review. No meeting next week, in observance of the Thanksgiving holiday in the US. Recent Changes ============== Merged onto 'openafs-stable-1_8_x' branch since 2024-10-24: 15955 ptserver: Add xdr_namelist to liboafs_prot.la.sym 15949 Make OpenAFS 1.8.13 15948 Update NEWS for OpenAFS 1.8.13 15947 OPENAFS-SA-2024-003: xdr: Initialize memory for INOUT args 15946 OPENAFS-SA-2024-003: sys: Don't over-copy RMTSYS_Pioctl output data 15945 OPENAFS-SA-2024-003: Run xdr_free for retried RPCs 15944 OPENAFS-SA-2024-003: xdr: Ensure correct string length in xdr_string 15943 OPENAFS-SA-2024-003: Check sanity on lengths of RPC returned arrays 15942 OPENAFS-SA-2024-003: xdr: Prevent XDR_DECODE buffer overruns 15941 OPENAFS-SA-2024-003: xdr: Set _len for prealloc'd opaque/array OUT args 15940 OPENAFS-SA-2024-003: xdr: Avoid prealloc'd string OUT args 15939 xdr: Avoid xdr_string maxsize check when freeing 15938 OPENAFS-SA-2024-002: Avoid uninitialized memory when parsing ACLs 15937 OPENAFS-SA-2024-002: make VIOCGETAL consumers stay within string bounds 15936 OPENAFS-SA-2024-002: verify FetchACL returned only a string 15935 OPENAFS-SA-2024-002: verify FetchACL returned a valid string 15934 OPENAFS-SA-2024-002: viced: Avoid unchecked ACL in StoreACL audit log 15933 OPENAFS-SA-2024-002: viced: Introduce 'rawACL' in StoreACL 15932 OPENAFS-SA-2024-002: acl: Error on missing newlines when parsing ACL 15931 OPENAFS-SA-2024-002: acl: Do not parse beyond end of ACL 15930 OPENAFS-SA-2024-002: viced: Free ACL on acl_Internalize_pr error 15929 OPENAFS-SA-2024-002: viced: Refuse ACLs without '\0' in SRXAFS_StoreACL 15928 OPENAFS-SA-2024-001: afs: Throttle PAG creation in afs_genpag() 15927 OPENAFS-SA-2024-001: afs: Introduce afs_genpag() Updated for 'openafs-stable-1_8_x' branch since 2024-10-24: 15965 Linux: Refactor afs_linux_write_begin() variants 15964 Linux: Define Clear/Set PageError macros as NOPs 15968 Update NEWS for OpenAFS 1.8.13.1 15969 Make OpenAFS 1.8.13.1 15966 Linux: Use folios for aops->write_begin/end Merged onto 'master' branch since 2024-10-24: 15962 DARWIN: Set workIPArray to nil in commitModify 15902 FBSD: Ignore src/libafs/kconf-GENERIC 15901 FBSD: Build support for FreeBSD 14.0 and 14.1 15904 Link LWP binaries with libafshcrypto_lwp.a 13305 Remove some dead assignment/increment operations 14681 comerr: Fix problems found by static analysis 14685 gtx: Fix problems found by static analysis 14679 butc: Fix problems found by static analysis 14680 cmd: Assert that *alloc() returns success 14677 bucoord: Fix problems found by static analysis 14713 libafscp: Avoid use of memory after freed 15903 FBSD: Fix typo in .gitignore for FreeBSD built products directory 14683 libacl: Fix problems found by static analysis 15044 afs: Flush vcaches sooner if cache is stressed 14961 afs: Prioritize removal of unlinked vcaches 15898 Linux: Use folios for aops->write_begin/end 15897 Linux: Refactor afs_linux_write_begin() variants 15876 Linux: Define Clear/Set PageError macros as NOPs 15954 ptserver: Add xdr_namelist to liboafs_prot.la.sym 15926 Make OpenAFS 1.9.2 15925 OPENAFS-SA-2024-003: xdr: Initialize memory for INOUT args 15924 OPENAFS-SA-2024-003: sys: Don't over-copy RMTSYS_Pioctl output data 15923 OPENAFS-SA-2024-003: Run xdr_free for retried RPCs 15922 OPENAFS-SA-2024-003: xdr: Ensure correct string length in xdr_string 15921 OPENAFS-SA-2024-003: Check sanity on lengths of RPC returned arrays 15920 OPENAFS-SA-2024-003: xdr: Prevent XDR_DECODE buffer overruns 15919 OPENAFS-SA-2024-003: xdr: Set _len for prealloc'd opaque/array OUT args 15918 OPENAFS-SA-2024-003: xdr: Avoid prealloc'd string OUT args 15917 OPENAFS-SA-2024-002: Avoid uninitialized memory when parsing ACLs 15916 OPENAFS-SA-2024-002: make VIOCGETAL consumers stay within string bounds 15915 OPENAFS-SA-2024-002: verify FetchACL returned only a string 15914 OPENAFS-SA-2024-002: verify FetchACL returned a valid string 15913 OPENAFS-SA-2024-002: viced: Avoid unchecked ACL in StoreACL audit log 15912 OPENAFS-SA-2024-002: viced: Introduce 'rawACL' in StoreACL 15911 OPENAFS-SA-2024-002: acl: Error on missing newlines when parsing ACL 15910 OPENAFS-SA-2024-002: acl: Do not parse beyond end of ACL 15907 OPENAFS-SA-2024-001: afs: Throttle PAG creation in afs_genpag() 14090 OPENAFS-SA-2024-001: afs: Introduce afs_genpag() 15909 OPENAFS-SA-2024-002: viced: Free ACL on acl_Internalize_pr error 15908 OPENAFS-SA-2024-002: viced: Refuse ACLs without '\0' in SRXAFS_StoreACL 15874 Restore max() macro for Heimdal 15328 libtool: Make libfoo.krb depend on libfoo 15875 bozo: Remove unused conditional OPBOS from 'bos' 14897 SOLARIS: Support 64-bit SPARC userspace builds 15027 afs: Make FlushReclaimedVcaches() Darwin specific 14949 afs: Convert afs_vhashT to use struct afs_q 15489 WINNT: Use safer string functions in DumpAfsLog 15871 WINNT: Remove commented out code in DumpAfsLog 15669 Linux: style cleanup in osi_groups.c 14671 afsd: Fix problems found by static analysis Updated for 'master' branch since 2024-10-24: 15959 DARWIN: Convert prefpane backup ops to privhelper 15960 DARWIN: Convert prefpane write ops to privhelper 15961 DARWIN: Use NSUInteger for indexGreaterThanIndex return value 15956 DARWIN: Add 'privhelper' tool for PrefPane 13135 fix fprintf conversion specifiers 15958 DARWIN: Convert prefpane start/stop to privhelper 15957 DARWIN: Convert prefpane startup ops to privhelper 15865 macos: Add support for MacOS 15.X (Sequoia) 15866 macOS: Resolve build errors on Apple Silicon-based macOS Sequoia 15878 rx: Lock rx_packets_mutex for rx_TSFPQ* globals 15967 rx: Consolidate common code in rx_TSFPQ* transfer functions 15885 rx: Convert RX_TS_FPQ_* macros to static functions 15884 rx: Move TSFPQ materials out of rx_globals.h 15883 rx: Move rx_ts_info_init to rx_packet.c 15882 rx: Refactor rx_SendAck to isolate RX_TS_GET_INFO 15881 rx: Reset rx statistics before recording has begun 15880 rx: Remove redundant include of rx_pthread.h from rx_pthread.c 15888 rx: Update lock order and coverage comments 15879 rx: Remove several unused locks 15887 rx: Remove superfluous locking in rxi_MorePackets* 15886 rx: Restrict global rx_mallocedP to RXDEBUG_PACKET only 14712 libafscp: Fix problems found by static analysis 15906 rx: Don't send packets to localhost if -rxbind set 15905 rx: Introduce 'rx_host' internal global 14717 afs: Convert lock macros to functions 15899 Linux CM: Fix leak of group_info on setpag() 15900 rx/rxdebug: protect against wrong sized rx_debugStats reply 15492 Add function comment for afs_SetParent() 14719 afs: Assert harder in kernel lock functions 14718 afs: AFS_ASSERT_GLOCK earlier in kernel lock functions -- Michael Meffie From ben@huntsmans.net Mon Nov 25 21:32:30 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 25 Nov 2024 21:32:30 +0000 Subject: [OpenAFS-devel] Changing libtool defaults causes inconsistent results Message-ID: SGkgdGhlcmUhDQogICBBbnlvbmUga25vdyBtdWNoIGFib3V0IGxpYnRvb2wgZGVmYXVsdHM/DQoN CiAgIE9uIEFJWCwgaWYgd2UgYnVpbGQgd2l0aG91dCBzZWxlY3Rpbmcg4oCUZGlzYWJsZS1zaGFy ZWQgb3Ig4oCUZGlzYWJsZS1zdGF0aWMgYXQgY29uZmlndXJlIHRpbWUgY2F1c2VzIGEgY29uZmxp Y3Qgd2hlcmUgYm90aCB2ZXJzaW9ucyBvZiB0aGUgbGlicmFyeSBhcmUgbmFtZWQgbGlid2hhdGV2 ZXIuYSwgYW5kIHRoZW4gdGhlIHNoYXJlZCB2ZXJzaW9uIGdldHMgb3ZlcndyaXR0ZW4gYXQgaW5z dGFsbCB0aW1lLiAgRm9yIHRoaXMgcmVhc29uIEkgdGhpbmsgdGhhdCBzZXR0aW5nIHRoZSBkZWZh dWx0IHRvIHN2cjQtc3R5bGUgbGlicmFyaWVzIHdvdWxkIGJlIG1vcmUgY29uc2lzdGVudCB3aXRo IGhvdyBkaXN0cmlidXRpb25zIHdlcmUgZG9uZSBpbiB0aGUgcGFzdC4NCg0KICAgVGhpcyBjYW4g YmUgZG9uZSBieSB1c2luZyB0aGUgY29uZmlndXJlIG9wdGlvbiDigJR3aXRoLWFpeC1zb25hbWU9 c3ZyNC4gIEJ1dCBhY2NvcmRpbmcgdG8gdGhlIGxpYnRvb2wgZG9jdW1lbnRhdGlvbiwgd2Ugc2hv dWxkIGJlIGFibGUgdG8gc3BlY2lmeSB0aGlzIGluIHRoZSBjb25maWd1cmUgbWFjcm9zIHdoZW4g d2UgY2FsbCBMVF9JTklULiAgVGhpcyBpcyBkb25lIGluIHNyYy9jZi9hZnMtbGlidG9vbC5tNC4g IElmIHdlIGNoYW5nZSB0aGUgY2FsbCB0bw0KDQogICBMVF9JTklUKFthaXgtc29uYW1lPXN2cjRd KQ0KDQpBbmQgdGhlbiBydW4gLi9jb25maWd1cmUgd2l0aG91dCBhbnkgb3B0aW9ucywgdGhhdCBz aG91bGQgYmUgaWRlbnRpY2FsIHRvIOKAlHdpdGgtYWl4LXNvbmFtZT1zdnI0LCB5ZXQgaXQgZG9l c27igJl0LiAgU3BlY2lmeWluZyBpdCBhcyBhbiBhcmd1bWVudCB3b3JrcywgYnV0IG1vZGlmeWlu ZyB0aGUgbTQgc291cmNlIGRvZXNu4oCZdC4gIA0KDQogICBJIGNhbiBwb3N0IGEgZGlmZiBidXQg dGhlcmXigJlzIHF1aXRlIGEgYml0IG9mIGRpZmZlcmVuY2VzLiAgQW55b25lIGtub3cgZW5vdWdo IGFib3V0IGxpYnRvb2wgdG8gdW5kZXJzdGFuZCB3aHkgdGhlc2UgdHdvIHRoaW5ncyB3b3VsZG7i gJl0IGdpdmUgaWRlbnRpY2FsIHJlc3VsdHM/DQoNCiAgIE1hbnkgdGhhbmtzIGluIGFkdmFuY2Uh IQ0KDQotQmVuDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ== From ben@huntsmans.net Sat Nov 30 22:52:56 2024 From: ben@huntsmans.net (Ben Huntsman) Date: Sat, 30 Nov 2024 22:52:56 +0000 Subject: [OpenAFS-devel] Clang (Open XL C 17.1+) on AIX Message-ID: --_000_BYAPR07MB58798A94CE1C7BA4B74BC003A72B2BYAPR07MB5879namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone- The latest few versions of the XL C compiler on AIX are clang-based. Th= ere are quite a few changes that need to be made in order for the kernel mo= dule to compile. I made a few updates to the Makefiles to compensate for s= ome command line argument differences. The first error we encounter is thi= s: In file included from /home/build/openafs/src/external/heimdal/hcrypto/sha2= 56.c:34: In file included from /home/build/openafs/src/crypto/hcrypto/kernel/config.= h:30: In file included from /home/build/openafs/src/afs/sysincludes.h:276: ../sys/socketvar.h:158:57: error: array has incomplete element type 'struct= free_sock_hash_bucket' extern struct free_sock_hash_bucket free_sock_hash_table[]; ^ ../sys/socketvar.h:158:15: note: forward declaration of 'struct free_sock_h= ash_bucket' extern struct free_sock_hash_bucket free_sock_hash_table[]; ^ Unfortunately sys/socketvar.h is an AIX-supplied header file, so we can'= t change it. I could open a bug report with IBM but even if they fix it in= the future we still need to deal with this situation for this version. Any ideas for how to deal with this? My initial thought is to use some = macros to not include the header, and just copy over the bits from the syst= em headers we need, for just the case of AIX 7.2+ with XLC 17.1+. Does tha= t sound like a reasonable approach? And if so, is there a preference as to= where the copied bits from the headers should go? Or is there a better wa= y to handle this situation? Thank you very much! -Ben --_000_BYAPR07MB58798A94CE1C7BA4B74BC003A72B2BYAPR07MB5879namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone-

The latest few versions of the XL C compiler on AIX are clang-= based. There are quite a few changes that need to be made in order fo= r the kernel module to compile. I made a few updates to the Makefiles= to compensate for some command line argument differences. The first error we encounter is this:

In file included from /home/build/openafs/src/external/heimdal/hcrypto/sha2= 56.c:34:

In file included from /home/build/openafs/src/crypto/hcrypto/kernel/config.= h:30:

In file included from /home/build/openafs/src/afs/sysincludes.h:276:

../sys/socketvar.h:158:57: error: array has incomplete element type 'struct= free_sock_hash_bucket'

extern struct free_sock_hash_bucket free_sock_hash_table[];

= ; &nb= sp; ^

../sys/socketvar.h:158:15: note: forward declaration of 'struct free_sock_h= ash_bucket'

extern struct free_sock_hash_bucket free_sock_hash_table[];

Unfortunately sys/socketvar.h is an AIX-supplied header file, = so we can't change it. I could open a bug report with IBM but even if= they fix it in the future we still need to deal with this situation for th= is version.

Any ideas for how to deal with this? My initial thought = is to use some macros to not include the header, and just copy over the bit= s from the system headers we need, for just the case of AIX 7.2+ with XLC 1= 7.1+. Does that sound like a reasonable approach? And if so, is there a preference as to where the copied bits from the head= ers should go? Or is there a better way to handle this situation?

Thank you very much!

-Ben

--_000_BYAPR07MB58798A94CE1C7BA4B74BC003A72B2BYAPR07MB5879namp_--