We are using 2.3-stable. Given that most of our testing has been done
it's a bit difficult for us to move to 2.5 now but we can take fixes
from 2.5.
I put a similar fix (to the existing one in 2.5) but I am running into
another issue around the ticket renew time. Operations are failing on
the client with auth check failed error -13 (Permission denied). I see
this after every ticket renewal :
27510445:442377371:Mar 10 08:37:21 atsqa8c43 kernel: RPC: 60114 gss_validate
27510447:442377373:Mar 10 08:37:21 atsqa8c43 kernel: RPC: 60114
gss_validate: gss_verify_mic returned error 0x000c0000
27510448:442377374:Mar 10 08:37:21 atsqa8c43 kernel: RPC: 60114
gss_validate failed ret -13.
27510449:442377375:Mar 10 08:37:21 atsqa8c43 kernel: RPC: 60114
rpc_verify_header: auth check failed with -13
27510450:442377376:Mar 10 08:37:21 atsqa8c43 kernel: RPC: 60114
rpc_verify_header: retrying
gss_verify_mic failed on client with error code set to GSS_S_CONTEXT_EXPIRED.
Either the server or the client is using the wrong context while
wrapping/unwrapping.
Do you remember fixing bug like that ?
Thanks,
Satya.
On Sat, Mar 11, 2017 at 5:55 PM, Malahal Naineni <mala...@gmail.com> wrote:
> gd->gen is not used in the latest code. If I remember, there was a bug
> removing recent cached entries resulting in permission errors. What
> version are you using? Try using V2.5.
>
> Regards, Malahal.
>
> On Sat, Mar 11, 2017 at 12:54 AM, Satya Prakash GS
> <g.satyaprak...@gmail.com> wrote:
>> On Sat, Mar 11, 2017 at 12:37 AM, William Allen Simpson
>> <william.allen.simp...@gmail.com> wrote:
>>> I'm not familiar with this code, so not likely to be much help.
>>> Looks mostly written by Matt, but Malahal made the most recent
>>> changes in July 2016.
>>>
>>> On 3/10/17 9:35 AM, Satya Prakash GS wrote:
>>>>
>>>> Is this a possibility :
>>>>
>>>> Server first rejects a client op with CREDPROBLEM/REJECTEDCRED,
>>>> Client does an upcall and gssd initializes the context with the server.
>>>> However the server recycles it immediately before the operation was
>>>> retried (looks like there is a bug in the LRU implementation on
>>>> Ganesha. To make things worse, I enabled the server debugs and it
>>>> slowed down the client operations making the eviction of the entry
>>>> easier). This happens thrice failing the client op.
>>>>
>>> Problem is not obvious.
>>>
>>> axp->gen is initialized to zero with the rest of *axp -- mem_zalloc().
>>>
>>> gd->gen is initialized to zero by alloc_svc_rpc_gss_data().
>>>
>>> axp->gen is bumped by one (++) each time it is handled by LRU code in
>>> authgss_ctx_hash_get().
>>>
>>
>> If a node gen isn't getting incremented it means that node is not
>> being looked up often.
>>
>>> atomic_inc_uint32_t(&gd->gen) is immediately after that.
>>>
>>> You think gd->gen also needs to be set to axp->gen in _set()?
>>>
>>
>>> I'm not sure they are related. There are many gd per axp, so
>>> axp->gen could be much higher than gd->gen.
>>>
>>
>> >From authgss_ctx_gc_idle ->
>>
>> if (abs(axp->gen - gd->gen) > __svc_params->gss.max_idle_gen) {
>> Remove the entry from the tree; //gd is no more in the cache after this
>> }
>>
>> Translates to - gd wasn't looked up in quite sometime let's clean it up.
>>
>> //gss.max_idle_gen -> by default set to 1024
>>
>> If tree's gen is 5000 and a new node gets inserted into the tree, node
>> gen shouldn't start at 0 or it might pass the above condition in the
>> next authgss_ctx_gc_idle call.
>>
>>> Both _get and _set are only called in svc_auth_gss.c _svcauth_gss().
>>>
>>> Admittedly, it is hard to track that there are 2 fields both called gen.
>>>
>>>> Thanks,
>>>> Satya.
>>>>
>>>> On Thu, Mar 9, 2017 at 8:07 PM, Satya Prakash GS
>>>> <g.satyaprak...@gmail.com> wrote:
>>>>>
>>>>> Looks like the gen field in svc_rpc_gss_data is used to check the
>>>>> freshness of a context. However it is not initialized to axp->gen in
>>>>> authgss_ctx_hash_set.
>>>>> Will this not result in evicting the entries out early or am I missing
>>>>> something ?
>>>>>
>>>>> Thanks,
>>>>> Satya.
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Announcing the Oxford Dictionaries API! The API offers world-renowned
>>>> dictionary content that is easy and intuitive to access. Sign up for an
>>>> account today to start using our lexical data to power your apps and
>>>> projects. Get started today and enter our developer competition.
>>>> http://sdm.link/oxford
>>>> _______________________________________________
>>>> Nfs-ganesha-devel mailing list
>>>> Nfs-ganesha-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>>
>>>
>>
>> Thanks,
>> Satya.
>>
>> ------------------------------------------------------------------------------
>> Announcing the Oxford Dictionaries API! The API offers world-renowned
>> dictionary content that is easy and intuitive to access. Sign up for an
>> account today to start using our lexical data to power your apps and
>> projects. Get started today and enter our developer competition.
>> http://sdm.link/oxford
>> _______________________________________________
>> Nfs-ganesha-devel mailing list
>> Nfs-ganesha-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
