Albert D. Cahalan wrote:
>Keith Owens wrote:
>> 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
>
> The kernel has a per-fd struct that can hold a bit more data.
> Results certainly may depend on implementation details of the
> proc file being read. It's been a damn long time since procps
> was commonly hurt by this problem when reading files.
Most /proc code that generates more than a page of data uses seq_file.
That implementation saves a position index which is passed to the
seq_operations->start() routine on the next read. Every such routine
in 2.4.19 uses the index as a counter into a list, i.e. all the
seq_file code is vulnerable to this race.
You will only see the race when the kernel list is modifified between
two reads from user space _and_ that modification is earlier in the
list than the current "position" in the /proc file. Even then, the
missing or duplicate entry is transient, close and reopen the /proc
file and the entries will be normal (assuming there are no more kernel
changes). The race is a low probability and only appears as noise in
the /proc output, but the race is there.
|