(Cc'ing Jamal)
On Tue, Aug 25, 2015 at 12:18 AM, Akshat Kakkar <akshat.1...@gmail.com> wrote:
> Well if that is the case, then just an additional information (which I
> have initially mentioned though), if hashtable is 800, then behaviour
> is correct i.e. deleting only a single filter but for hash tables
> other than 800, the bug (if any) gets triggered.
>
Hmm, I didn't read your initial email before my previous reply.
But I bet you deleted the 800: filter _after_ deleting the 15: one?
u32 hashtables are stateful, try the reverse order, I don't see
any reason why 800: could be any special here, expect it is the
default handle picked by kernel.
The attached patch works for me, let me know if it works for you..
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index cab9e9b..ac5e0ad 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -495,6 +495,20 @@ static bool u32_destroy(struct tcf_proto *tp, bool force)
if (root_ht && --root_ht->refcnt == 0)
u32_destroy_hnode(tp, root_ht);
+ if (!force) {
+ struct tc_u_hnode *ht;
+
+ if (tp_c->refcnt > 1)
+ return false;
+ if (tp_c->refcnt == 1) {
+ for (ht = rtnl_dereference(tp_c->hlist);
+ ht;
+ ht = rtnl_dereference(ht->next))
+ if (!ht_empty(ht))
+ return false;
+ }
+ }
+
if (--tp_c->refcnt == 0) {
struct tc_u_hnode *ht;
