[Click] Race Condition in Master::run_selects_poll (?)

[José María González]

Hi, 

I think I found a race condition in Click's poll master. Let's assume one
of the elements being polled is a FromDevice. Click ioctl's the pcap fd 
using BIOCIMMEDIATE, so read()'s will return as soon as there is one 
packet. 

Now, let's assume that, before poll() is called on the pollfd vector, 
more than 1 packet is received at the kernel buffer. poll() returns by
setting the corresponding revent field to POLLIN (readable data 
available). FromDevice calls pcap_dispatch() with the cnt to 1, and 
therefore the first packet is processed.

The second one is stored in pcap's userland buffer. The fd is empty now, 
so poll()'ing the fd returns revent=0. The packet will only be processed
once a new, 3rd packet arrives to the device, which will force poll() to
set the corresponding revent again to POLLIN. It doesn't matter Click is
idle or busy. It won't process the second packet until a third one arrives 
to the kernel. 


It's not clear how to solve the problem, though. The only way to know
whether the userland buffer is not empty is by checking the value of cc
(struct pcap). This field is not exported by pcap, and just importing
pcap-int.h (which you're not supposed to do anyway) only works if your
pcap-int.h header is the right one (note that installing pcap does
*not* install pcap-int.h). 

Any ideas on a solution? 
-Chema