[ntp:hackers] Correctly detecting interfaces
brian.utterback at oracle.com
Fri Jul 12 17:51:32 UTC 2013
On 7/12/2013 12:48 PM, Danny Mayer wrote:
> On 7/12/2013 11:54 AM, Danny Mayer wrote:
>> On 7/12/2013 10:54 AM, Brian Utterback wrote:
>>> Speaking of which, is there any process to get the changes I made to fix
>>> bug 1485 pushed upstream to the ISC bind people for inclusion in
>>> subsequent release of BIND? Anyone have a contact?
> I noticed that you have not verified the bug as being fixed. I would
> also need details of the bug and the code that fixed it.
Okay, no problem.
The issue is that the ifiter_ioctl.c file has a bunch of places where
the ioctl call is used to query the system about the network interfaces.
However the code assumes that the ioctl call cannot be interrupted,
i.e., never returns EINTR. As a practical matter, this is probably
mostly true, but it is certainly not guaranteed.
Reading the kernel structures may (and in Solaris, does) involve
acquiring some locks on the structures. If there is a delay obtaining
the locks the kernel may temporarily cause the thread to sleep while
waiting for the lock. If the SIGALRM signal fires at this point the
thread will be interrupted and will return EINTR instead of the correct
data. Since the EINTR return is not accounted for in the library code,
it treats this like any other error return. This means that in some
cases the error is noted and the program aborts or the incorrect data
induces a program error and the program again aborts.
As is the case with most syscalls that can return EINTR, the correct way
of handling it is to simply try again. Of course we don't necessarily
want to keep trying indefinitely.
Rather than rewrite every instance of calling ioctl to include a test
for EINTR and loop to try again, I wrote a new function (isc_ioctl)
which is simply a wrapper function around the regular ioctl call. This
wrapper function incorporates such a test and loop. I used a "three
strikes and you're out" rule, but any number could be used. Probably two
tries is really enough, since the interrupt could come anytime after the
ioctl is called the first time, but a second failure would imply that
the call is taking more than one second to complete and it might never
complete without an interrupt if that state is persistent.
That's all there is to it.
More information about the hackers