Don't increase master refcount on expectations

As it's been discussed [1][2]. We shouldn't increase the master conntrack refcount for non-fulfilled conntracks. During the conntrack destruction, the expectations are always killed before the conntrack itself, this guarantees that there won't be any orphan expectation.

Signed-off-by Pablo Neira Ayuso <[email protected]>

Index: netfilter-2.6.14/net/ipv4/netfilter/ip_conntrack_core.c
===================================================================
--- netfilter-2.6.14.orig/net/ipv4/netfilter/ip_conntrack_core.c

+++ netfilter-2.6.14/net/ipv4/netfilter/ip_conntrack_core.c 2005-08-20

net/ipv4/netfilter/ip_conntrack_core.c +1 -4

 {
  struct ip_conntrack_expect *new;

@@ -944,17 +947,14 @@
  return NULL;
  }
  new->master = me;
- atomic_inc(&new->master->ct_general.use);
  atomic_set(&new->use, 1);
  return new;
 }
 
 void ip_conntrack_expect_put(struct ip_conntrack_expect *exp)
 {
- if (atomic_dec_and_test(&exp->use)) {
- ip_conntrack_put(exp->master);
+ if (atomic_dec_and_test(&exp->use))
  kmem_cache_free(ip_conntrack_expect_cachep, exp);
- }
 }
 
 static void ip_conntrack_expect_insert(struct ip_conntrack_expect *exp)

As it's been discussed [1][2]. We shouldn't increase the master conntrack refcount for non-fulfilled conntracks. During the conntrack destruction, the expectations are always killed before the conntrack itself, this guarantees that there won't be any orphan expectation.

Quoted 4 lines · Pablo Neira

As it's been discussed [1][2]. We shouldn't increase the master conntrack refcount for non-fulfilled conntracks. During the conntrack destruction, the expectations are always killed before the conntrack itself, this guarantees that there won't be any orphan expectation.

Applied, thanks. Is it correct that this also fixes the untriggerable deadlock Yasuyuki noticed?

The scenario is that then I had a custom solution which takes advantage on helper-expectation framewrok.According to this scenario,a master will expect many children simultaniously.And not only each child's first packet which fullfill the expect relies on its master for nat decision,but also the scenario relies on the master for decision made on itself while one of its children's replying packet reaches.And each children's replying packet will not only put itself but also remove its conntrack.So the scenarion raises 2 problems:
1.Then without responsing from netfilter,All I can do is but doing some custimized work to ip_conntrack_put the master to prevent the master from hanging forever.(After quite a period, they patched the context.) 2.After All expects being fullfilled,it is still nacessary that the master be referenced.So it looks reserving a refcount on the master after the fullfillment doesn't push things too far.

So,my opinion is if it is necessary to keep refcount after fullfillment?And,I suggest that my past suggestion be referrenced.

Well, it's questionable that I correctly understand your scenario, but I think there is no problem. 1. As Pablo said, expectations in list are destroyed by its master before master is destroyed, so ip_conntrack_put() doesn't cause problem. And because the refcount of master conntrack is incremented when the expected packets arrived, master conntrack can be

after that. See init_conntrack() in detail.