[PATCH 09/28] rpc: gss: Add oid values to the gss_api mechanism structures

[Chuck Lever]

On Mar 31, 2008, at 12:20 PM, Kevin Coffman wrote:
> On Mon, Mar 31, 2008 at 11:21 AM, Chuck Lever  
> <chuck.lever at oracle.com> wrote:
>>
>> On Mar 31, 2008, at 10:31 AM, Kevin Coffman wrote:
>>> From: Usha Ketineni <uketinen at us.ibm.com>
>>>
>>> On NFSV4 server side, these are required as part of the security
>>> triple(oid,qop,service) information being sent in the response of  
>>> the
>>> SECINFO operation.
>>>
>>> Signed-off-by: Usha Ketineni <uketinen at us.ibm.com>
>>> Signed-off-by: J. Bruce Fields <bfields at citi.umich.edu>
>>> ---
>>>
>>>  fs/nfsd/nfs4xdr.c                    |    6 +++---
>>>  include/linux/sunrpc/gss_api.h       |    2 +-
>>>  include/linux/sunrpc/gss_krb5.h      |    2 ++
>>>  net/sunrpc/auth_gss/gss_krb5_mech.c  |    4 +++-
>>>  net/sunrpc/auth_gss/gss_spkm3_mech.c |    4 +++-
>>>  5 files changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
>>> index 0e6a179..7e13c78 100644
>>> --- a/fs/nfsd/nfs4xdr.c
>>> +++ b/fs/nfsd/nfs4xdr.c
>>> @@ -2519,9 +2519,9 @@ nfsd4_encode_secinfo(struct nfsd4_compoundres
>>> *resp, __be32 nfserr,
>>>                       RESERVE_SPACE(4);
>>>                       WRITE32(RPC_AUTH_GSS);
>>>                       ADJUST_ARGS();
>>> -                     RESERVE_SPACE(4 + gm->gm_oid.len);
>>> -                     WRITE32(gm->gm_oid.len);
>>> -                     WRITEMEM(gm->gm_oid.data, gm->gm_oid.len);
>>> +                     RESERVE_SPACE(4 + gm->gm_oid->len);
>>> +                     WRITE32(gm->gm_oid->len);
>>> +                     WRITEMEM(gm->gm_oid->data, gm->gm_oid->len);
>>>                       ADJUST_ARGS();
>>>                       RESERVE_SPACE(4);
>>>                       WRITE32(0); /* qop */
>>> diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/
>>> gss_api.h
>>> index 459c5fc..ed0b80c 100644
>>> --- a/include/linux/sunrpc/gss_api.h
>>> +++ b/include/linux/sunrpc/gss_api.h
>>> @@ -76,7 +76,7 @@ struct pf_desc {
>>>  struct gss_api_mech {
>>>       struct list_head        gm_list;
>>>       struct module           *gm_owner;
>>> -     struct xdr_netobj       gm_oid;
>>> +     struct xdr_netobj       *gm_oid;
>>>       char                    *gm_name;
>>>       const struct gss_api_ops *gm_ops;
>>>       /* pseudoflavors supported by this mechanism: */
>>> diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/
>>> gss_krb5.h
>>> index a10f1fb..0d55934 100644
>>> --- a/include/linux/sunrpc/gss_krb5.h
>>> +++ b/include/linux/sunrpc/gss_krb5.h
>>> @@ -70,6 +70,8 @@ enum seal_alg {
>>>       SEAL_ALG_DES3KD = 0x0002
>>>  };
>>>
>>> +extern struct xdr_netobj krb5_oid;
>>> +
>>
>>  Why "extern"?  Should this be "static" ?
>
> In the non-kernel world, a definition like this in a header file
> without "extern" causes storage for the structure to be allocated in
> each .c file that includes the header.  Are the rules different for
> kernel code?

No, I just missed the fact that this was a header file definition.

>>>  #define CKSUMTYPE_CRC32                      0x0001
>>>  #define CKSUMTYPE_RSA_MD4            0x0002
>>>  #define CKSUMTYPE_RSA_MD4_DES                0x0003
>>> diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/
>>> auth_gss/gss_krb5_mech.c
>>> index 60c3dba..3c070d0 100644
>>> --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
>>> +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
>>> @@ -232,10 +232,12 @@ static struct pf_desc gss_kerberos_pfs[] = {
>>>       },
>>>  };
>>>
>>> +struct xdr_netobj krb5_oid = {9, "\x2a\x86\x48\x86\xf7\x12\x01\x02
>>> \x02"};
>>> +
>>
>>  No "extern" here, but again, should this be declared "static"?
>>
>>
>>>  static struct gss_api_mech gss_kerberos_mech = {
>>>       .gm_name        = "krb5",
>>>       .gm_owner       = THIS_MODULE,
>>> -     .gm_oid         = {9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01 
>>> \x02\x02"},
>>> +     .gm_oid         = &krb5_oid,
>>>       .gm_ops         = &gss_kerberos_ops,
>>>       .gm_pf_num      = ARRAY_SIZE(gss_kerberos_pfs),
>>>       .gm_pfs         = gss_kerberos_pfs,
>>> diff --git a/net/sunrpc/auth_gss/gss_spkm3_mech.c b/net/sunrpc/
>>> auth_gss/gss_spkm3_mech.c
>>> index 5deb4b6..210b23b 100644
>>> --- a/net/sunrpc/auth_gss/gss_spkm3_mech.c
>>> +++ b/net/sunrpc/auth_gss/gss_spkm3_mech.c
>>> @@ -214,10 +214,12 @@ static struct pf_desc gss_spkm3_pfs[] = {
>>>       {RPC_AUTH_GSS_SPKMI, RPC_GSS_SVC_INTEGRITY, "spkm3i"},
>>>  };
>>>
>>> +struct xdr_netobj spkm3_oid = {7, "\053\006\001\005\005\001\003"};
>>> +
>>
>>  Likewise?
>>
>>
>>
>>>  static struct gss_api_mech gss_spkm3_mech = {
>>>       .gm_name        = "spkm3",
>>>       .gm_owner       = THIS_MODULE,
>>> -     .gm_oid         = {7, "\053\006\001\005\005\001\003"},
>>> +     .gm_oid         = &spkm3_oid,
>>>       .gm_ops         = &gss_spkm3_ops,
>>>       .gm_pf_num      = ARRAY_SIZE(gss_spkm3_pfs),
>>>       .gm_pfs         = gss_spkm3_pfs,
>>
>>  --
>>  Chuck Lever
>>  chuck[dot]lever[at]oracle[dot]com
>>
>>

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com