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

[Eddie Kohler]

Chema,

Thanks for figuring this out.  Libpcap is quite an irritant!

The "right" way is probably for FromDevice to set up a "task", and only go to 
sleep once pcap returns a null packet.  Many pcaps will not support this since, 
in their infinite wisdom, pcap_dispatch() blocks.  But I guess recent pcaps 
support pcap_setnonblock().

Eddie


José María González wrote:
> 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
> 
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click