[radvd-devel-l] localtime() call problem

[Pekka Savola]

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 
capabilities.

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 
select() loop.

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