Hi,
I'm not sure if it's still time to include this change in 1.7 since we froze the strings yesterday, but if not, feel free to postpone to 1.8.
[PATCH 1/3] Resolver: Introduce a per-request timeout In addition to passing a timeout to c-ares (which controls how long would c-ares talk to an individual name server), also set up a tevent timeout for the whole request.
The rationale is that the user of the async interface does not know or case how many name servers there are and would like to just limit how long the whole request could take. This should help in situations where the DNS server is very slow or drops packets.
[PATCH 2/3] Do not touch resolve_service_state in fo_resolve_service_done In the fail over code, we correctly used the "server->common" pointer as memory context for the resolving but then passed a service resolving state as a private context.
If the service resolving request was canceled before the resolving request finished, fo_resolve_service_done would access freed memory.
This was a long-standing bug in the fail over code we never hit because the service resolve request could end only when the resolve request ended. I hit the bug when I introduced the timeouts in the later patch.
[PATCH 3/3] Failover: Introduce a per-service timeout Changes the semantics of dns_resolver_timeout to be "how long a service resolution can take" from "how long a name resolution can take". I think it is better from the point of view of the fail over user.
Also introduces a new option dns_resolver_op_timeout which controls the resolver timeout (which is what dns_resolver_timeout used to do). It is intentionally undocumented.
On Tue, 2011-12-20 at 16:49 +0100, Jakub Hrozek wrote:
Hi,
I'm not sure if it's still time to include this change in 1.7 since we froze the strings yesterday, but if not, feel free to postpone to 1.8.
[PATCH 1/3] Resolver: Introduce a per-request timeout In addition to passing a timeout to c-ares (which controls how long would c-ares talk to an individual name server), also set up a tevent timeout for the whole request.
The rationale is that the user of the async interface does not know or case how many name servers there are and would like to just limit how long the whole request could take. This should help in situations where the DNS server is very slow or drops packets.
[PATCH 2/3] Do not touch resolve_service_state in fo_resolve_service_done In the fail over code, we correctly used the "server->common" pointer as memory context for the resolving but then passed a service resolving state as a private context.
If the service resolving request was canceled before the resolving request finished, fo_resolve_service_done would access freed memory.
This was a long-standing bug in the fail over code we never hit because the service resolve request could end only when the resolve request ended. I hit the bug when I introduced the timeouts in the later patch.
[PATCH 3/3] Failover: Introduce a per-service timeout Changes the semantics of dns_resolver_timeout to be "how long a service resolution can take" from "how long a name resolution can take". I think it is better from the point of view of the fail over user.
Also introduces a new option dns_resolver_op_timeout which controls the resolver timeout (which is what dns_resolver_timeout used to do). It is intentionally undocumented.
Ack to all three.
On Tue, 2011-12-20 at 12:02 -0500, Stephen Gallagher wrote:
On Tue, 2011-12-20 at 16:49 +0100, Jakub Hrozek wrote:
Hi,
I'm not sure if it's still time to include this change in 1.7 since we froze the strings yesterday, but if not, feel free to postpone to 1.8.
[PATCH 1/3] Resolver: Introduce a per-request timeout In addition to passing a timeout to c-ares (which controls how long would c-ares talk to an individual name server), also set up a tevent timeout for the whole request.
The rationale is that the user of the async interface does not know or case how many name servers there are and would like to just limit how long the whole request could take. This should help in situations where the DNS server is very slow or drops packets.
[PATCH 2/3] Do not touch resolve_service_state in fo_resolve_service_done In the fail over code, we correctly used the "server->common" pointer as memory context for the resolving but then passed a service resolving state as a private context.
If the service resolving request was canceled before the resolving request finished, fo_resolve_service_done would access freed memory.
This was a long-standing bug in the fail over code we never hit because the service resolve request could end only when the resolve request ended. I hit the bug when I introduced the timeouts in the later patch.
[PATCH 3/3] Failover: Introduce a per-service timeout Changes the semantics of dns_resolver_timeout to be "how long a service resolution can take" from "how long a name resolution can take". I think it is better from the point of view of the fail over user.
Also introduces a new option dns_resolver_op_timeout which controls the resolver timeout (which is what dns_resolver_timeout used to do). It is intentionally undocumented.
Ack to all three.
Pushed to master.
sssd-devel@lists.fedorahosted.org