lkml.org 
[lkml]   [2018]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun
>> >    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.

\
 
 \ /
  Last update: 2018-04-04 23:46    [W:0.072 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site