Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

From: Willem de Bruijn
Date: Wed Apr 04 2018 - 17:45:37 EST

>> > One issue with the above proposed change to use TP_STATUS_IN_PROGRESS
>> > is that the documentation of the tp_status field is somewhat
>> > inconsistent. In some places it's described as TP_STATUS_KERNEL(0)
>> > meaning the entry is owned by the kernel and !TP_STATUS_KERNEL(0)
>> > meaning the entry is owned by user space. In other places ownership
>> > by user space is defined by the TP_STATUS_USER(1) bit being set.
>> But indeed this example in packet_mmap.txt is problematic
>> if (status == TP_STATUS_KERNEL)
>> retval = poll(&pfd, 1, timeout);
>> It does not really matter whether the docs are possibly inconsistent and
>> which one is authoritative. Examples like the above make it likely that
>> some user code expects such code to work.
> Yes, that's exactly my concern. Yet another troubling example seems to be
> lipbcap which also is looking specifically for status to be anything other than
> TP_STATUS_KERNEL(0) to indicate a frame is available in user space.

Good catch. If pcap-linux.c relies on this then the status field
cannot be changed. Other fields can be modified freely while tp_status
remains 0, perhaps that's an option.