This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More on SIGINT, longjmp, and getaddrinfo


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]