This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: More on SIGINT, longjmp, and getaddrinfo
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Hal Murray <hmurray at megapathdsl dot net>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Mon, 22 Feb 2016 12:03:18 -0500
- Subject: Re: More on SIGINT, longjmp, and getaddrinfo
- Authentication-results: sourceware.org; auth=none
- References: <20160222014052 dot CACDF406060 at ip-64-139-1-69 dot sjc dot megapath dot net>
On Sun, Feb 21, 2016 at 8:40 PM, Hal Murray <hmurray@megapathdsl.net> wrote:
> I'm still scheming for a good solution.
>
> I think the basic problem is that getaddrinfo can take a long time on a human
> scale. Many/most other routines that might take a while return EINTR when
> interrupted by a signal rather than continue waiting.
This depends on SA_RESTART.
> Are there routines in libc and/or POSIX other than DNS lookup that don't
> return promptly when interrupted by a signal? How widespread is this problem?
It's not a problem. The function getaddrinfo is not defined as
explicitly setting EINTR so it won't be interrupted by signals.
Particularly in the UDP and TCP sending functions the implementation
consciously retries in the face of interrupting signals using
TEMP_FAILURE_RETRY (glibc specific helper macro).
> What is the worst cast time for getaddrinfo or getnameinfo to return? I
> assume the really nasty case would involve several retransmissions on each of
> several different steps so the worst case could be horribly long. How about
> an estimate for a simple dead-server case? Is there a limit on the number of
> steps? ...
There is a limit.
The worse case time for getaddrinfo and family of functions has to do
with the number of retries (RES_DFLRETRY), timeouts (RES_TIMEOUT), and
number of servers. It could be quite long.
So it could be 5 x 5 x 3 = 15 seconds (not verified).
> Are there any test case names or addresses that are guaranteed to timeout?
I don't quite follow, could you expand on this?
Are you asking if there are tests that verify the maximum? Not
presently, but someone could add one given the new test framework
we're putting in place for validating CVE-2015-7547.
https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
> That seems like something that would be handy for regression testing so there
> might be an RFC describing a reserved name.
We don't need to do that in glibc, we just use whitebox testing to
override /etc/resolv.conf settings to whatever we need.
In the case of the internal tests we have threads being DNS servers,
and threads being DNS clients and test the glibc stub resolver in the
middle by sending expected queries and returning expected answers and
observing the results on the client side.
Cheers,
Carlos.