Details

    • Technical task
    • Resolution: Fixed
    • Blocker
    • Lustre 2.5.0
    • Lustre 2.4.1
    • All
    • 8774

    Attachments

      Issue Links

        Activity

          [LU-3490] GSSAPI support not tested by Gerritt

          Here's the specific failure for SLES11SP1:
          cc1: warnings being treated as errors
          context_lucid.c: In function 'derive_key_lucid':
          context_lucid.c:354: error: call to function 'krb5_derive_key' without a real prototype
          context.h:46: note: 'krb5_derive_key' was declared here

          A bit of looking at the source for SLES11SP2 and CentOS vs SLES11SP1 shows that function is defined in SLES11SP2 and CentOS, but it's not found in SLES11SP1.
          It looks like the patch here which put functionality for deriving kerberos keys in to the kernel isn't in SLES11SP1.
          That patch is here:
          http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html

          So I don't think there's an easy solution here if we actually want this to work on SLES11SP1, especially not if it's supposed to work on patchless clients.

          Ken,

          It looks like you're right. Still, that function is found in lgssglue in SLES11SP1 and CentOS, so we're OK there.

          paf Patrick Farrell (Inactive) added a comment - - edited Here's the specific failure for SLES11SP1: cc1: warnings being treated as errors context_lucid.c: In function 'derive_key_lucid': context_lucid.c:354: error: call to function 'krb5_derive_key' without a real prototype context.h:46: note: 'krb5_derive_key' was declared here A bit of looking at the source for SLES11SP2 and CentOS vs SLES11SP1 shows that function is defined in SLES11SP2 and CentOS, but it's not found in SLES11SP1. It looks like the patch here which put functionality for deriving kerberos keys in to the kernel isn't in SLES11SP1. That patch is here: http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html So I don't think there's an easy solution here if we actually want this to work on SLES11SP1, especially not if it's supposed to work on patchless clients. — Ken, It looks like you're right. Still, that function is found in lgssglue in SLES11SP1 and CentOS, so we're OK there.

          Some versions of the GSS library don't provide gss_export_lucid_sec_context(), depending on the vintage. I'm actually in that situation, for a long, complicated, and stupid reason.

          I suspect that -lgssapi (typically provided by a Kerberos implementation) shipped with SLES11SP1 is one of those vintages.

          kenh Ken Hornstein added a comment - Some versions of the GSS library don't provide gss_export_lucid_sec_context(), depending on the vintage. I'm actually in that situation, for a long, complicated, and stupid reason. I suspect that -lgssapi (typically provided by a Kerberos implementation) shipped with SLES11SP1 is one of those vintages.

          Minh,

          Not in general. This is the output for el6 inkernel from the same build (http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull):
          checking for gss_export_lucid_sec_context in -lgssapi... no
          checking for gss_export_lucid_sec_context in -lgssglue... yes

          So that same situation works for el6.
          One of lgssapi or lgssglue seems to be sufficient.

          Maybe that's not true for sles11sp1.

          paf Patrick Farrell (Inactive) added a comment - Minh, Not in general. This is the output for el6 inkernel from the same build ( http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull): checking for gss_export_lucid_sec_context in -lgssapi... no checking for gss_export_lucid_sec_context in -lgssglue... yes So that same situation works for el6. One of lgssapi or lgssglue seems to be sufficient. Maybe that's not true for sles11sp1.
          mdiep Minh Diep added a comment -

          The reason it failed in sles11sp1 but not sles11sp2 is

          sles11sp1:
          checking for gss_export_lucid_sec_context in -lgssapi... no
          checking for gss_export_lucid_sec_context in -lgssglue... yes <<<<

          sles11sp2:
          checking for gss_export_lucid_sec_context in -lgssapi... no
          checking for gss_export_lucid_sec_context in -lgssglue... no

          I believe the logic in the patch

          AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
          [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi";
          gss_conf_test='success'],
          [AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
          [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue";
          gss_conf_test='success'],
          [if test x$enable_gss == xyes; then
          AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
          else
          AC_MSG_WARN([libgssapi or libgssglue is not found, which is required by GSS.])
          fi])],)

          do we need both libgssapi and libgssglue to be yes or both to be no?

          mdiep Minh Diep added a comment - The reason it failed in sles11sp1 but not sles11sp2 is sles11sp1: checking for gss_export_lucid_sec_context in -lgssapi... no checking for gss_export_lucid_sec_context in -lgssglue... yes <<<< sles11sp2: checking for gss_export_lucid_sec_context in -lgssapi... no checking for gss_export_lucid_sec_context in -lgssglue... no I believe the logic in the patch AC_CHECK_LIB( [gssapi] , [gss_export_lucid_sec_context] , [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi"; gss_conf_test='success'], [AC_CHECK_LIB( [gssglue] , [gss_export_lucid_sec_context] , [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue"; gss_conf_test='success'], [if test x$enable_gss == xyes; then AC_MSG_ERROR( [libgssapi or libgssglue is not found, which is required by GSS.] ) else AC_MSG_WARN( [libgssapi or libgssglue is not found, which is required by GSS.] ) fi])],) do we need both libgssapi and libgssglue to be yes or both to be no?

          Nice catch, Minh, that does fix most of the build failures. The remaining ones are unusual issues unique to SLES11 and Ubuntu 10.04. I'll leave those to you.

          paf Patrick Farrell (Inactive) added a comment - Nice catch, Minh, that does fix most of the build failures. The remaining ones are unusual issues unique to SLES11 and Ubuntu 10.04. I'll leave those to you.
          mdiep Minh Diep added a comment -

          I updated the patch and now it only failed on sles http://build.whamcloud.com/job/lustre-reviews/18238/

          mdiep Minh Diep added a comment - I updated the patch and now it only failed on sles http://build.whamcloud.com/job/lustre-reviews/18238/
          mdiep Minh Diep added a comment -

          just a notice

          checking whether to enable gss/krb5 support... auto
          checking whether to enable gss keyring backend... auto
          checking if Linux was built with CONFIG_KEYS in or as module... yes
          checking for keyctl_search in -lkeyutils... yes
          checking if Linux was built with CONFIG_SUNRPC in or as module... yes
          checking if Linux was built with CONFIG_CRYPTO_MD5 in or as module... yes
          checking if Linux was built with CONFIG_CRYPTO_SHA1 in or as module... yes
          checking if Linux was built with CONFIG_CRYPTO_SHA256 in or as module... yes
          checking if Linux was built with CONFIG_CRYPTO_SHA512 in or as module... yes
          checking for Kerberos v5...
          The current KRBDIR is

          If we leave gss and gss keyring on auto and have keyutils..., but not Kerberos, should we issue a warning?

          mdiep Minh Diep added a comment - just a notice checking whether to enable gss/krb5 support... auto checking whether to enable gss keyring backend... auto checking if Linux was built with CONFIG_KEYS in or as module... yes checking for keyctl_search in -lkeyutils... yes checking if Linux was built with CONFIG_SUNRPC in or as module... yes checking if Linux was built with CONFIG_CRYPTO_MD5 in or as module... yes checking if Linux was built with CONFIG_CRYPTO_SHA1 in or as module... yes checking if Linux was built with CONFIG_CRYPTO_SHA256 in or as module... yes checking if Linux was built with CONFIG_CRYPTO_SHA512 in or as module... yes checking for Kerberos v5... The current KRBDIR is If we leave gss and gss keyring on auto and have keyutils..., but not Kerberos, should we issue a warning?

          As expected, with that patch, the tests for GSS keyring are passing and it is failing to build:
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink':
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          cc1: warnings being treated as errors
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:665: error: passing argument 1 of 'key_get' makes pointer from integer without a cast
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/reused/usr/src/kernels/2.6.32-358.18.1.el6_lustre.gd8b4950.i686/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate':
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring'
          /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring'
          make[7]: *** [/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1

          paf Patrick Farrell (Inactive) added a comment - As expected, with that patch, the tests for GSS keyring are passing and it is failing to build: /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink': /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' cc1: warnings being treated as errors /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:665: error: passing argument 1 of 'key_get' makes pointer from integer without a cast /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/reused/usr/src/kernels/2.6.32-358.18.1.el6_lustre.gd8b4950.i686/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate': /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring' /var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring' make [7] : *** [/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1
          paf Patrick Farrell (Inactive) added a comment - Patch up at http://review.whamcloud.com/#/c/7622/

          OK, a bit of further information. I've been unable to build GSS with GSS_KEYRING enabled. I originally thought that was because of a problem with my kernel source, but I've now re-downloaded and rebuilt that twice now. The tests for building GSS_KEYRING are passing, but the code itself is not building; I'm getting errors indicating that some of the definitions it depends on aren't available. In particular, these appear to be those things which are defined if CONFIG_KEYS is set in the kernel.

          I've looked at the .config file being used to build the kernel, and I've confirmed CONFIG_KEYS is definitely set (It's the Lustre provided .config file.). (I'm following the WC build instructions from here: https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=8126821)

          Since the 'auto' setting wasn't actually causing GSS to be built, I suspect that GSS_KEYRING actually hasn't been built lately and is linked incorrectly. I suspect if you tried to build it (--enable-gss is sufficient with current master) you'd find these same failures:

          make[5]: Entering directory `/home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink':
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          cc1: warnings being treated as errors
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: passing argument 1 of 'key_get' makes pointer from integer without a cast
          /home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate':
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring'
          /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring'
          make[9]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1

          I will put up a patch to fix the autoconf behavior, but I don't currently see how to fix the problem with building GSS_KEYRING. That means build systems without libkeyutils installed will gracefully choose not to build GSS_KEYRING, but those with libkeyutils installed will pass the autoconf tests and then fail to compile.

          paf Patrick Farrell (Inactive) added a comment - - edited OK, a bit of further information. I've been unable to build GSS with GSS_KEYRING enabled. I originally thought that was because of a problem with my kernel source, but I've now re-downloaded and rebuilt that twice now. The tests for building GSS_KEYRING are passing, but the code itself is not building; I'm getting errors indicating that some of the definitions it depends on aren't available. In particular, these appear to be those things which are defined if CONFIG_KEYS is set in the kernel. I've looked at the .config file being used to build the kernel, and I've confirmed CONFIG_KEYS is definitely set (It's the Lustre provided .config file.). (I'm following the WC build instructions from here: https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=8126821 ) Since the 'auto' setting wasn't actually causing GSS to be built, I suspect that GSS_KEYRING actually hasn't been built lately and is linked incorrectly. I suspect if you tried to build it (--enable-gss is sufficient with current master) you'd find these same failures: — make [5] : Entering directory `/home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink': /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' cc1: warnings being treated as errors /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: passing argument 1 of 'key_get' makes pointer from integer without a cast /home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate': /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring' /home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring' make [9] : *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1 — I will put up a patch to fix the autoconf behavior, but I don't currently see how to fix the problem with building GSS_KEYRING. That means build systems without libkeyutils installed will gracefully choose not to build GSS_KEYRING, but those with libkeyutils installed will pass the autoconf tests and then fail to compile.

          Sorry about the delay on this, I ran in to some unexpected issues on my build system.

          It turns out the 'auto' from the original patch is causing the GSS dependencies to be checked, but it's not actually causing GSS to be built. I figured that out because my build system couldn't actually build GSS [A separate issue with my kernel source], and I couldn't understand why make rpms succeeded with gss not enabled or disabled (So, using 'auto'), but failed with gss enabled.

          This is because enable_gss is used like this in the 'configure' file that autoconf generates:
          if test x$enable_gss = xyes; then
          GSS_TRUE=
          GSS_FALSE='#'
          else
          GSS_TRUE='#'
          GSS_FALSE=
          fi
          ^-- So when it's set to auto, GSS_TRUE is not set as expected. This (GSS_TRUE) is the macro actually used by the make files.

          The simple solution is to start with enable_gss to auto as we do now, then if the various tests pass, set it to 'yes' before leaving the function. I've tested doing this and it causes gss to be built by default.

          Once I've sorted out my other build issues and can completely build GSS without errors, I'll be able to test to my satisfaction and put up a patch for this and the earlier problem.

          Andrew:
          About spuriously setting HAVE_GSS. HAVE_GSS is defined before the code block below. Consider the 'auto' case where the libraries are not found - HAVE_GSS will remain defined, but it's not correct.

          In any case, you're right that it shouldn't cause a problem - HAVE_GSS isn't actually used anywhere else, as far as I can tell. (Though I'm hardly an autoconf expert.)

          if test x$KRBDIR != x; then
          AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
          [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi"],
          [AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
          [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue"],
          [if test x$enable_gss == xyes;
          AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
          fi])],)

          paf Patrick Farrell (Inactive) added a comment - Sorry about the delay on this, I ran in to some unexpected issues on my build system. It turns out the 'auto' from the original patch is causing the GSS dependencies to be checked, but it's not actually causing GSS to be built. I figured that out because my build system couldn't actually build GSS [A separate issue with my kernel source] , and I couldn't understand why make rpms succeeded with gss not enabled or disabled (So, using 'auto'), but failed with gss enabled. This is because enable_gss is used like this in the 'configure' file that autoconf generates: if test x$enable_gss = xyes; then GSS_TRUE= GSS_FALSE='#' else GSS_TRUE='#' GSS_FALSE= fi ^-- So when it's set to auto, GSS_TRUE is not set as expected. This (GSS_TRUE) is the macro actually used by the make files. The simple solution is to start with enable_gss to auto as we do now, then if the various tests pass, set it to 'yes' before leaving the function. I've tested doing this and it causes gss to be built by default. Once I've sorted out my other build issues and can completely build GSS without errors, I'll be able to test to my satisfaction and put up a patch for this and the earlier problem. — Andrew: About spuriously setting HAVE_GSS. HAVE_GSS is defined before the code block below. Consider the 'auto' case where the libraries are not found - HAVE_GSS will remain defined, but it's not correct. In any case, you're right that it shouldn't cause a problem - HAVE_GSS isn't actually used anywhere else, as far as I can tell. (Though I'm hardly an autoconf expert.) if test x$KRBDIR != x; then AC_CHECK_LIB( [gssapi] , [gss_export_lucid_sec_context] , [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi"] , [AC_CHECK_LIB( [gssglue] , [gss_export_lucid_sec_context] , [GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue"] , [if test x$enable_gss == xyes; AC_MSG_ERROR( [libgssapi or libgssglue is not found, which is required by GSS.] ) fi])],)

          People

            mdiep Minh Diep
            ajk Andrew Korty (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: