Re: potential bug in David Brownell's zcip code

I'll post the latest code a bit later, but for now:

On Wednesday 22 December 2004 3:37 am, Michael Schmidt wrote:
> 
> There are two problems with this:
> 
> a)
> When the code is in the 'packet has arrived' branch, the timeout cannot have 
> elapsed by definition of 'poll()'. Exceeding of the timeout leads into 
> the 'timeout' branch.

Call the "timeout elapsed" branch of that just paranoia,
then.  In fact it _might_ have elapsed by the time that
code executes; the zcip task might have been preempted.


> b)
> This code may erroneously assume that the timeout has elapsed, if an 
> unexpected ARP packet arrives within the regular, finite timeout (still in 
> the protocol negotiation phase), and the OS preempts the zcip code between 
> the return of 'poll()' and the timeout recalculation above. When the code is 
> reactivated by the scheduler, the timeout may indeed have elapsed, and 
> 'timercmp(&tv1, &tv2, <)' will hold true. In this case, the code will 
> erroneously assume that the protocol negotiation phase is finished, and will 
> set the subsequent timeout to -1 (infinite). zcip will seem to hang.

Eventually that should be fixed by implementing the relevant
SO_ATTACH_FILTER logic, so that only relevant ARP packets can
ever get past the poll() logic.  I'd be interested in a fix
for that; its certainly not something I'll have time to do,
but it'll be very important on networks that have more than
a handful of machines.

(In fact, if someone wants to take over this code from now
on, I'd be happy.)


> I have fixed the problem by replacing 'poll()' with 'select()' and by 
> simplifying the timeout recalculation (which is an obvious consequence of 
> using 'select()'. 'select()# returns with the timeout parameter containing 
> the remaining timeout value when it is woken up by a packet before the 
> timeout has elapsed. This value can directly be used for re-invoking 
> 'select()'. Please note that this behavior is only implemented in Linux, but 
> not in other Unices, so that my patch is not compatible with other Unices.

Which is why I don't much like that solution!

- Dave


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/