On Tue, 26 Nov 2002 05:28:52 -0500 (EST),
"Albert D. Cahalan" <acahalan@xxxxxxxxxx> wrote:
>Interesting thread I found on a web archive...
>I'm making some libproc changes, so it's not a
>bad time to consider what the API should look like.
>Please Cc: me on any response.
>
>> The copyout problem ... I think there remains a systemic Linux issue
>> with any /proc "file" that is longer than your page size du jour ...
>> if the underlying data is subject to change, there is no way a user
>> space app (cat(1) is the simplest example) is guaranteed to see a
>> consistent view ... you may miss whole lines, you may see some lines
>> more than once.
>>
>> If this assertion is not correct, I'd like to understand why.
>
>You're 1/3 right. The app won't get a perfect snapshot of the
>data, but it won't get missing or duplicate lines either.
>Reading X bytes moves the file pointer by Y and Y>=X.
>For example, the file pointer may be encoded as:
>
>5 bits character-within-a-field (the least significant bits)
>3 bits field number
>9 bits line number
>
>Plus any part of the data (one field, one line, etc.) could
>be kept for the reader so that 9999 changing to 10000 doesn't
>ever look like 99000 to the reader.
I disagree, any /proc file that reflects a kernel list structure and
requires more than one read to get the data from /proc is subject to
missing and/or duplicate entries.
The problem is the lack of space in the "file pointer". On 64 bit
machines, there is not enough room to store an actual kernel address in
the file pointer. Even on 32 bit machines, there is no easy way to
validate any kernel address passed out to user space and back in again.
Even worse, you cannot guarantee that the list entry address stored in
the "file pointer" is not deleted between reads. And it is guaranteed
that storing addresses will result in a file pointer that does not go
in ascending order.
Instead of using addresses, people store an index in the file pointer
and use the index to reposition in the kernel list for the next read.
To guarantee no duplicate or missing lines, the second and subsequent
reads must pick up where the previous read left off.
What happens when an entry is deleted from the list between read calls?
The next read will try to restablish position by counting through the
list until it reaches the index position. But the list now contains
one less entry, if the deletion is prior to the index entry then one
extra entry will be skipped during repositioning and will be missing
from the /proc output.
What happens when an entry is added to the list between read calls? If
the underlying kernel structure supports insertions anywhere in the
list then the repositioning count can see the extra list entry and will
reposition one entry short of where it should be. This results in
duplicate lines in the /proc output.
Unless all deletes and inserts are at the end of the list,
repositioning a /proc file via a counter will always be dubious.
|