We are looking chain N.
If we cannot atomic_inc() refcount, we got some deleted entry.
If we could atomic_inc, we can meet an entry that just moved to another chain X
When hitting its end, we continue the search to the N+1 chain so we only
skip the end of previous chain (N). We can 'forget' some entries, we can print
several time one given entry.
We could solve this by :
1) Checking hash value : if not one expected ->
Going back to head of chain N, (potentially re-printing already handled entries)
So it is not a *perfect* solution.
2) Use a locking to forbid writers (as done in UDP/TCP), but it is expensive and
wont solve other problem :
We wont avoid emitting same entry several time anyway (this is a flaw of
current seq_file handling, since we 'count' entries to be skiped, and this is
wrong if some entries were deleted or inserted meanwhile)
We have same problem on /proc/net/udp & /proc/net/tcp, I am not sure we should care...
Also, current resizing code can give to a /proc/net/ip_conntrack reader a problem, since
hash table can switch while its doing its dumping : many entries might be lost or regiven...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html