Pavel Shilovsky piastr...@gmail.com wrote:
It seems that dns_resolver sets expiry timeout to zero here
(http://lxr.free-electrons.com/source/security/keys/key.c#L310) and
doesn't change it - so, it always returns cached value.
That's not the DNS resolver you've provided a pointer to - that's
2011/6/27 David Howells dhowe...@redhat.com:
Pavel Shilovsky piastr...@gmail.com wrote:
It seems that dns_resolver sets expiry timeout to zero here
(http://lxr.free-electrons.com/source/security/keys/key.c#L310) and
doesn't change it - so, it always returns cached value.
That's not the DNS
Pavel Shilovsky piastr...@gmail.com wrote:
Yes, I meant, that dns_query calls request_key - request_key_and_link
- construct_key_and_link - construct_alloc_key - key_alloc and
there expiry timeout is set to zero. I don't noticed any other places
where this value changes while request_key is
Set linux-cifs-client nomail
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't think you should need to set max_pending below 9 (I am trying
to determine
if 10 is ok, or whether XP reserves one for async oplock breaks) since this is
a per-socket limit. We had a long discussion about this at MS Friday
but the questions were about whether it was a number of requests
