Re: [PATCH nf-next] netfilter: allow early drop of assured conntracks

Hi Florian, On Sun, 16 Apr 2017, Florian Westphal wrote: > If insertion of a new conntrack fails because the table is full, the > kernel searches the next buckets of the hash slot where the new > connection was supposed to be inserted at for an entry that hasn't seen > traffic in reply

Re: [PATCH v2] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

On Tue, Mar 21, 2017 at 04:32:45PM -0700, Stephen Hemminger wrote: > On Tue, 21 Mar 2017 23:28:45 +0100 > Linus Lüssing wrote: > > > However, the IP code drops it in the beginning of ip_input.c/ip_rcv() > > as the dnat target did not update the skb->pkt_type. If after >

[PATCH nf 2/4] netfilter: ctnetlink: fix deadlock due to acquire _expect_lock twice

From: Liping Zhang Currently, ctnetlink_change_conntrack is always protected by _expect_lock, but this will cause a deadlock when deleting the helper from a conntrack, as the _expect_lock will be acquired again by nf_ct_remove_expectations: CPU0

[PATCH nf 3/4] netfilter: ctnetlink: make it safer when updating ct->status

From: Liping Zhang After converting to use rcu for conntrack hash, one CPU may update the ct->status via ctnetlink, while another CPU may process the packets and update the ct->status. So the non-atomic operation "ct->status |= status;" via ctnetlink becomes unsafe, and

[PATCH nf 4/4] netfilter: ctnetlink: acquire ct->lock before operating nf_ct_seqadj

From: Liping Zhang We should acquire the ct->lock before accessing or modifying the nf_ct_seqadj, as another CPU may modify the nf_ct_seqadj at the same time during its packet proccessing. Signed-off-by: Liping Zhang ---

[PATCH nf 0/4] netfilter: ctnetlink: fix some bugs related to ct update

From: Liping Zhang This patch set aims to fix some bugs related to ctnetlink_change_conntrack. First, we may invoke request_module with rcu_read_lock held, this is wrong, as the request_module invocation may sleep. Fixed by PATCH #1. Second, the unnecessary

[PATCH nf 1/4] netfilter: ctnetlink: drop the incorrect cthelper module request

From: Liping Zhang First, when creating a new ct, we will invoke request_module to try to load the related inkernel cthelper. So there's no need to call the request_module again when updating the ct helpinfo. Second, ctnetlink_change_helper may be called with rcu_read_lock

Doubt about CTA_EXPECT_* values passed to ctnetlink_parse_tuple()

Hi, While working on clang support for kernel builds I came across at what at first sight looks like an enum mismatch in the netfilter conntrack code: In multiple occasions CTA_EXPECT_* values (of type enum ctattr_expect) are passed to ctnetlink_parse_tuple(), which expects an 'enum ctattr_type'