| Message ID | CAGCkEt0rwo0+qT1BHXggHN3946yCCSEkhDrEaucqpAxVVF1s5w@mail.gmail.com |
|---|---|
| State | Deferred |
| Headers | show |
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 08870b8..e162ab0 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -219,7 +219,7 @@ dump_counters(struct sk_buff *skb, struct nf_conn_acct *acct, struct nlattr *nest_count; u64 pkts, bytes; - if (type == IPCTNL_MSG_CT_GET_CTRZERO) { + if (type == IPCTNL_MSG_CT_GET_CTRZERO || type == IPCTNL_MSG_CT_DELETE) { pkts = atomic64_xchg(&counter[dir].packets, 0); bytes = atomic64_xchg(&counter[dir].bytes, 0);
Hello Pablo, all Could we clear counter at IPCTNL_MSG_CT_DELETE? Assume we call netlink_dump() twice from netlink_poll() by mmaped socket. A ct entry which will be dumped at the second time is deleted just after the first dump, before the second dump. The delete event makes report its counter and mark it deleting. It seems that we can read the deleting entry at the second time and will dump counter value again because it loops in kernel context, Is it right? thanks, --- net/netfilter/nf_conntrack_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) } else { -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html