[radvd-devel-l] localtime() call problem
pekkas at netcore.fi
Fri Aug 28 06:35:00 EDT 2009
On Fri, 28 Aug 2009, LiKai wrote:
> I have a rough understanding about this call: it is not a reentrant call, which means it is not supposed to be used in
> signal handling context.
> vlog() call is used to print log in different methods, and localtime() is called to format time stamp in log. It can be
> called in both normal application context and signal handling context, which maybe will cause deadlock.
> Is this a problem? Please help to point it out, if I have any misunderstanding here.
I fear you're correct. Luckily enough, only a few calls to vlog are
active unless you run radvd in debug mode. I don't recall seeing this
problem in practise.
The use of logging is most pervasive in timer_handler which in turn
calls send_ra_forall(). The latter really needs some printing
You could avoid these problems by using select() as Reuben Hawkins did
with a patched version, but select has its own complications.
Reuben's implementation for example uses usleep() in one place as a
replacement for mdelay and rescheduling timers. AFAIK this would
block radvd from serving other interfaces or requests for the time its
sleeping. In the end, in a select() implementation you would probably
need to manipulate iface->expiration from various places in a bit
similar manner that timers currently do, to take into account all the
complications that the RFC requires such as:
1) if you've just sent a periodic RA, and get an RS, you may need to
a) skip the next scheduled RA if they're too close together, or
b) reschedule the next scheduled RA to be sooner,
2) add various random delays to RS solicited RAs,
3) send more tightly paced RAs when radvd is starting up, and
4) send an additional customized RA sent when radvd is shutting down
I think these would likely be solvable but would result in a bit more
complicated implementation expiration timer implementation in a
Having had to fight and debug the timer code just recently, moving to
select like approach might have some appeal though :-)
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
More information about the radvd-devel-l