> On Sep 19, 2016, at 09:10, Frank Sorenson <sorenson@xxxxxxxxxx> wrote:
>
>
> ----- Original Message -----
>> From: "Trond Myklebust" <trondmy@xxxxxxxxxxxxxxx>
>> To: "Frank Sorenson" <sorenson@xxxxxxxxxx>
>> Cc: "List Linux NFS Mailing" <linux-nfs@xxxxxxxxxxxxxxx>
>> Sent: Friday, September 16, 2016 4:37:39 PM
>> Subject: Re: [PATCH] sunrpc: include gid in the rpc_cred_cache hash
>
>>> +rpcauth_hash_acred(struct auth_cred *acred, unsigned int hashbits)
>>> +{
>>> + return hash_64(from_kgid(&init_user_ns, acred->gid) |
>>> + (from_kuid(&init_user_ns, acred->uid) << (sizeof(gid_t) * 8)),
>>> + hashbits);
>>> +}
>>> +
>
>> NACK. The choice of only using the uid when hashing was deliberate;
>> RPCSEC_GSS is keyed only on the uid…
>> If you want to do this in order to accelerate AUTH_SYS lookups, then you need
>> to push the hashing down to the auth flavour ops.
>
> I recognize that RPCSEC_GSS only uses the uid as a key. However, RPCSEC_GSS
> calls rpcauth_lookup_credcache with an auth_cred, just like AUTH_SYS, only with
> the gid set to 0. Including the gid in the hash has no effect on RPCSEC_GSS;
> if the function is flipped to shift the gid instead of the uid, it even hashes
> to the same result as it did previously.
>
AFAIK, both generic_bind_cred() and rpcauth_lookupcred() can make indirect calls to gss_lookup_cred() with a bog standard credential (acred->gid == current_cred()->fsgid). Am I missing something?
> Adding a shift and bitwise OR to the hash is more straightforward and
> efficient than adding the logic to provide a per-auth flavour hash op that
> differs only in that it doesn't shift and OR a 0 value.
>
> Or are there additional benefits to be gained from each having its own hash
> function?
>
>
> Thanks,
>
> Frank
> --
> Frank Sorenson
> sorenson@xxxxxxxxxx
> Senior Software Maintenance Engineer
> Global Support Services - filesystems
> Red Hat
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
