From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-05 23:33:05
Several cls_u32 patches: fixing refcounting, preventing
links to and deletion of root hnodes, validating divisor. Plus
cleanups - removal of some useless fields and saner handling of
tc_u_common hashtable. The first 3 in series are fixes (and
-stable fodder), the rest - cleanups. Branch can be found in
vfs.git#misc.cls_u32; individual patches will go in followups.
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-05 19:04:08
From: Al Viro <viro@zeniv.linux.org.uk>
cls_u32.c misuses refcounts for struct tc_u_hnode - it counts references via
->hlist and via ->tp_root together. u32_destroy() drops the former and, in
case when there had been links, leaves the sucker on the list. As the result,
there's nothing to protect it from getting freed once links are dropped.
That also makes the "is it busy" check incapable of catching the root hnode -
it *is* busy (there's a reference from tp), but we don't see it as something
separate. "Is it our root?" check partially covers that, but the problem
exists for others' roots as well.
AFAICS, the minimal fix preserving the existing behaviour (where it doesn't
include oopsen, that is) would be this:
* count tp->root and tp_c->hlist as separate references. I.e.
have u32_init() set refcount to 2, not 1.
* in u32_destroy() we always drop the former; in u32_destroy_hnode() -
the latter.
That way we have *all* references contributing to refcount. List
removal happens in u32_destroy_hnode() (called only when ->refcnt is 1)
an in u32_destroy() in case of tc_u_common going away, along with everything
reachable from it. IOW, that way we know that u32_destroy_key() won't
free something still on the list (or pointed to by someone's ->root).
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
net/sched/cls_u32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-05 23:35:45
From: Al Viro <viro@zeniv.linux.org.uk>
... and disallow deleting or linking to such
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
net/sched/cls_u32.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
@@ -693,7 +696,7 @@ static int u32_delete(struct tcf_proto *tp, void *arg, bool *last,gotoout;}-if(root_ht==ht){+if(ht->flags&TCA_CLS_FLAGS_U32_ROOT){NL_SET_ERR_MSG_MOD(extack,"Not allowed to delete root node");return-EINVAL;}
@@ -795,6 +798,10 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp,NL_SET_ERR_MSG_MOD(extack,"Link hash table not found");return-EINVAL;}+if(ht_down->flags&TCA_CLS_FLAGS_U32_ROOT){+NL_SET_ERR_MSG_MOD(extack,"Not linke to root node");+return-EINVAL;+}ht_down->refcnt++;}
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-05 23:35:45
From: Al Viro <viro@zeniv.linux.org.uk>
* calculate key *once*, not for each hash chain element
* let tc_u_hash() return the pointer to chain head rather than index -
callers are cleaner that way.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
net/sched/cls_u32.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
@@ -995,7 +995,11 @@ static int u32_change(struct net *net, struct sk_buff *in_skb,if(tb[TCA_U32_DIVISOR]){unsignedintdivisor=nla_get_u32(tb[TCA_U32_DIVISOR]);-if(--divisor>0x100){+if(!is_power_of_2(divisor)){+NL_SET_ERR_MSG_MOD(extack,"Divisor is not a power of 2");+return-EINVAL;+}+if(divisor-->0x100){NL_SET_ERR_MSG_MOD(extack,"Exceeded maximum 256 hash buckets");return-EINVAL;}
@@ -68,7 +68,6 @@ struct tc_u_knode {u32mask;u32__percpu*pcpu_success;#endif-structtcf_proto*tp;structrcu_workrwork;/* The 'sel' field MUST be the last field in structure to allow for*tc_u32_keysallocatedatendofstructure.
@@ -897,7 +896,6 @@ static struct tc_u_knode *u32_init_knode(struct tcf_proto *tp,/* Similarly success statistics must be moved as pointers */new->pcpu_success=n->pcpu_success;#endif-new->tp=tp;memcpy(&new->sel,s,sizeof(*s)+s->nkeys*sizeof(structtc_u32_key));if(tcf_exts_init(&new->exts,TCA_U32_ACT,TCA_U32_POLICE)){
@@ -1113,7 +1111,6 @@ static int u32_change(struct net *net, struct sk_buff *in_skb,n->handle=handle;n->fshift=s->hmask?ffs(ntohl(s->hmask))-1:0;n->flags=flags;-n->tp=tp;err=tcf_exts_init(&n->exts,TCA_U32_ACT,TCA_U32_POLICE);if(err<0)
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-06 10:21:09
On 2018-09-05 3:04 p.m., Al Viro wrote:
From: Al Viro <viro@zeniv.linux.org.uk>
cls_u32.c misuses refcounts for struct tc_u_hnode - it counts references via
->hlist and via ->tp_root together. u32_destroy() drops the former and, in
case when there had been links, leaves the sucker on the list. As the result,
there's nothing to protect it from getting freed once links are dropped.
That also makes the "is it busy" check incapable of catching the root hnode -
it *is* busy (there's a reference from tp), but we don't see it as something
separate. "Is it our root?" check partially covers that, but the problem
exists for others' roots as well.
AFAICS, the minimal fix preserving the existing behaviour (where it doesn't
include oopsen, that is) would be this:
* count tp->root and tp_c->hlist as separate references. I.e.
have u32_init() set refcount to 2, not 1.
* in u32_destroy() we always drop the former; in u32_destroy_hnode() -
the latter.
That way we have *all* references contributing to refcount. List
removal happens in u32_destroy_hnode() (called only when ->refcnt is 1)
an in u32_destroy() in case of tc_u_common going away, along with everything
reachable from it. IOW, that way we know that u32_destroy_key() won't
free something still on the list (or pointed to by someone's ->root).
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
For networking patches, subject should be reflective of tree and
subsystem. Example for this one:
"[PATCH net 1/7]:net: sched: cls_u32: fix hnode refcounting"
Also useful to have a cover letter summarizing the patchset
in 0/7. Otherwise
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-06 15:03:15
On 2018-09-05 3:04 p.m., Al Viro wrote:
From: Al Viro <viro@zeniv.linux.org.uk>
... and disallow deleting or linking to such
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Same comment as other one in regards to subject
Since the flag space is coming from htnode which is
exposed via uapi it makes sense to keep this one here
because it is for private use; but a comment in
include/uapi/linux/pkt_cls.h that this flag or
maybe a set of bits is reserved for internal use.
Otherwise:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-06 15:08:51
On 2018-09-06 6:28 a.m., Jamal Hadi Salim wrote:
On 2018-09-05 3:04 p.m., Al Viro wrote:
quoted
From: Al Viro <viro@zeniv.linux.org.uk>
... and disallow deleting or linking to such
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Same comment as other one in regards to subject
Since the flag space is coming from htnode which is
exposed via uapi it makes sense to keep this one here
because it is for private use; but a comment in
include/uapi/linux/pkt_cls.h that this flag or
maybe a set of bits is reserved for internal use.
Otherwise:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Sorry, additional comment:
It makes sense to reject user space attempt to
set TCA_CLS_FLAGS_U32_ROOT
So my suggestion is to update tc_flags_valid() to
check for this.
cheers,
jamal
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-06 15:11:29
On 2018-09-05 3:04 p.m., Al Viro wrote:
From: Al Viro <viro@zeniv.linux.org.uk>
* calculate key *once*, not for each hash chain element
* let tc_u_hash() return the pointer to chain head rather than index -
callers are cleaner that way.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-06 15:34:29
On Thu, Sep 06, 2018 at 06:34:00AM -0400, Jamal Hadi Salim wrote:
On 2018-09-06 6:28 a.m., Jamal Hadi Salim wrote:
quoted
On 2018-09-05 3:04 p.m., Al Viro wrote:
quoted
From: Al Viro <viro@zeniv.linux.org.uk>
... and disallow deleting or linking to such
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Same comment as other one in regards to subject
Since the flag space is coming from htnode which is
exposed via uapi it makes sense to keep this one here
because it is for private use; but a comment in
include/uapi/linux/pkt_cls.h that this flag or
maybe a set of bits is reserved for internal use.
Otherwise:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Sorry, additional comment:
It makes sense to reject user space attempt to
set TCA_CLS_FLAGS_U32_ROOT
Point, and that one is IMO enough to give up on using ->flags for
that. How about simply
@@ -84,6 +84,7 @@ struct tc_u_hnode {intrefcnt;unsignedintdivisor;structidrhandle_idr;+boolis_root;structrcu_headrcu;u32flags;/* The 'ht' field MUST be the last field in structure to allow for
@@ -377,6 +378,7 @@ static int u32_init(struct tcf_proto *tp)root_ht->refcnt++;root_ht->handle=tp_c?gen_new_htid(tp_c,root_ht):0x80000000;root_ht->prio=tp->prio;+root_ht->is_root=true;idr_init(&root_ht->handle_idr);if(tp_c==NULL){
@@ -693,7 +695,7 @@ static int u32_delete(struct tcf_proto *tp, void *arg, bool *last,gotoout;}-if(root_ht==ht){+if(ht->is_root){NL_SET_ERR_MSG_MOD(extack,"Not allowed to delete root node");return-EINVAL;}
@@ -795,6 +797,10 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp,NL_SET_ERR_MSG_MOD(extack,"Link hash table not found");return-EINVAL;}+if(ht_down->is_root){+NL_SET_ERR_MSG_MOD(extack,"Not linking to root node");+return-EINVAL;+}ht_down->refcnt++;}
@@ -84,6 +84,7 @@ struct tc_u_hnode {intrefcnt;unsignedintdivisor;structidrhandle_idr;+boolis_root;structrcu_headrcu;u32flags;/* The 'ht' field MUST be the last field in structure to allow for
@@ -377,6 +378,7 @@ static int u32_init(struct tcf_proto *tp)root_ht->refcnt++;root_ht->handle=tp_c?gen_new_htid(tp_c,root_ht):0x80000000;root_ht->prio=tp->prio;+root_ht->is_root=true;idr_init(&root_ht->handle_idr);if(tp_c==NULL){
@@ -693,7 +695,7 @@ static int u32_delete(struct tcf_proto *tp, void *arg, bool *last,gotoout;}-if(root_ht==ht){+if(ht->is_root){NL_SET_ERR_MSG_MOD(extack,"Not allowed to delete root node");return-EINVAL;}
@@ -795,6 +797,10 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp,NL_SET_ERR_MSG_MOD(extack,"Link hash table not found");return-EINVAL;}+if(ht_down->is_root){+NL_SET_ERR_MSG_MOD(extack,"Not linking to root node");+return-EINVAL;+}ht_down->refcnt++;
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-07 07:14:03
On Thu, Sep 06, 2018 at 06:21:09AM -0400, Jamal Hadi Salim wrote:
For networking patches, subject should be reflective of tree and
subsystem. Example for this one:
"[PATCH net 1/7]:net: sched: cls_u32: fix hnode refcounting"
Also useful to have a cover letter summarizing the patchset
in 0/7. Otherwise
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Argh... Unfortunately, there's this: in u32_delete() we have
if (root_ht) {
if (root_ht->refcnt > 1) {
*last = false;
goto ret;
}
if (root_ht->refcnt == 1) {
if (!ht_empty(root_ht)) {
*last = false;
goto ret;
}
}
}
and that would need to be updated. However, that logics is bloody odd
to start with. First of all, root_ht has come from
struct tc_u_hnode *root_ht = rtnl_dereference(tp->root);
and the only place where it's ever modified is
rcu_assign_pointer(tp->root, root_ht);
in u32_init(), where we'd bloody well checked that root_ht is non-NULL
(see
if (root_ht == NULL)
return -ENOBUFS;
upstream of that place) and where that assignment is inevitable on the
way to returning 0. No matter what, if tp has passed u32_init() it
will have non-NULL ->root, forever. And there is no way for tcf_proto
to be seen outside of tcf_proto_create() without ->init() having returned
0 - it gets freed before anyone sees it.
So this 'if (root_ht)' can't be false. What's more, what the hell is the
whole thing checking? We are in u32_delete(). It's called (as ->delete())
from tfilter_del_notify(), which is called from tc_del_tfilter(). If we
return 0 with *last true, we follow up calling tcf_proto_destroy().
OK, let's look at the logics in there:
* if there are links to root hnode => false
* if there's no links to root hnode and it has knodes => false
(BTW, if we ever get there with root_ht->refcnt < 1, we are obviously screwed)
* if there is a tcf_proto sharing tp->data => false (i.e. any filters
with different prio - don't bother)
* if tp is the only one with reference to tp->data and there are *any*
knodes => false.
Any extra links can come only from knodes in a non-empty hnode. And it's not
a common case. Shouldn't thIe whole thing be
* shared tp->data => false
* any non-empty hnode => false
instead? Perhaps even with the knode counter in tp->data, avoiding any loops
in there, as well as the entire ht_empty()...
Now, in the very beginning of u32_delete() we have this:
struct tc_u_hnode *ht = arg;
if (ht == NULL)
goto out;
OK, but the call of ->delete() is
err = tp->ops->delete(tp, fh, last, extack);
and arg == NULL seen in u32_delete() means fh == NULL in tfilter_del_notify().
Which is called in
if (!fh) {
...
} else {
bool last;
err = tfilter_del_notify(net, skb, n, tp, block,
q, parent, fh, false, &last,
extack);
How can we ever get there with NULL fh?
The whole thing makes very little sense; looks like it used to live in
u32_destroy() prior to commit 763dbf6328e41 ("net_sched: move the empty tp
check from ->destroy() to ->delete()"), but looking at the rationale in
that commit... I don't see how it fixes anything - sure, now we remove
tcf_proto from the list before calling ->destroy(). Without any RCU delays
in between. How could it possibly solve any issues with ->classify()
called in parallel with ->destroy()? cls_u32 (at least these days)
does try to survive u32_destroy() in parallel with u32_classify();
if any other classifiers do not, they are still broken and that commit
has not done anything for them.
Anyway, adjusting 1/7 for that is trivial, but I would really like to
understand what that code is doing... Comments?
@@ -84,6 +84,7 @@ struct tc_u_hnode {intrefcnt;unsignedintdivisor;structidrhandle_idr;+boolis_root;structrcu_headrcu;u32flags;/* The 'ht' field MUST be the last field in structure to allow for
@@ -377,6 +378,7 @@ static int u32_init(struct tcf_proto *tp)root_ht->refcnt++;root_ht->handle=tp_c?gen_new_htid(tp_c,root_ht):0x80000000;root_ht->prio=tp->prio;+root_ht->is_root=true;idr_init(&root_ht->handle_idr);if(tp_c==NULL){
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-07 07:43:19
On Thu, Sep 06, 2018 at 07:57:25PM -0700, Cong Wang wrote:
quoted
- if (root_ht == ht) {
+ if (ht->is_root) {
What's wrong with comparing pointers with root ht?
The fact that there may be more than one tcf_proto sharing tp->data.
quoted
NL_SET_ERR_MSG_MOD(extack, "Not allowed to delete root node");
return -EINVAL;
}
@@ -795,6 +797,10 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp, NL_SET_ERR_MSG_MOD(extack, "Link hash table not found"); return -EINVAL; }+ if (ht_down->is_root) {
root ht is saved in tp->root, so you can compare ht_down with it too,
if you want.
If this check is all what you need, you don't need an extra flag.
Again, *which* tp? We can trivially check that we are not linking to/deleting
our own root, sure. But there's nothing to stop doing the same via another
tcf_proto...
From: Cong Wang <hidden> Date: 2018-09-07 08:02:31
On Thu, Sep 6, 2018 at 8:04 PM Al Viro [off-list ref] wrote:
On Thu, Sep 06, 2018 at 07:57:25PM -0700, Cong Wang wrote:
quoted
quoted
- if (root_ht == ht) {
+ if (ht->is_root) {
What's wrong with comparing pointers with root ht?
The fact that there may be more than one tcf_proto sharing tp->data.
Hmm? root ht is from tp->root, not tp->data.
Also, this very important information is missing in your one-line changelog...
quoted
quoted
NL_SET_ERR_MSG_MOD(extack, "Not allowed to delete root node");
return -EINVAL;
}
@@ -795,6 +797,10 @@ static int u32_set_parms(struct net *net, struct tcf_proto *tp, NL_SET_ERR_MSG_MOD(extack, "Link hash table not found"); return -EINVAL; }+ if (ht_down->is_root) {
root ht is saved in tp->root, so you can compare ht_down with it too,
if you want.
If this check is all what you need, you don't need an extra flag.
Again, *which* tp? We can trivially check that we are not linking to/deleting
Pretty sure there is a 'tp' in u32_set_parms() parameter list.
Are you saying it is not what you want? If so, why?
More importantly, why this information is again missing in your
changelog? This patch is definitely not trivial, it deserves a detailed
changelog.
our own root, sure. But there's nothing to stop doing the same via another
tcf_proto...
To my best knowledge, the place where you set ->is_root=true
is precisely same with where we set tp->root=root_ht, and it doesn't
change after set. What am I missing here?
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-07 08:28:56
On Thu, Sep 06, 2018 at 08:23:36PM -0700, Cong Wang wrote:
Pretty sure there is a 'tp' in u32_set_parms() parameter list.
Are you saying it is not what you want? If so, why?
More importantly, why this information is again missing in your
changelog? This patch is definitely not trivial, it deserves a detailed
changelog.
quoted
our own root, sure. But there's nothing to stop doing the same via another
tcf_proto...
To my best knowledge, the place where you set ->is_root=true
is precisely same with where we set tp->root=root_ht, and it doesn't
change after set. What am I missing here?
The fact that there can be two (or more) different tcf_proto instances sharing
->data, but not ->root. And since ->data is shared, u32_get() on one tp
will be able to return you ->root of *ANOTHER* one. So comparison with
tp->root doesn't protect you. Try this on mainline:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 100 handle 1: u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 200 handle 2: u32 divisor 1
tc filter delete dev eth0 parent ffff: protocol ip prio 100 handle 801: u32
and watch the fun as soon as you get an incoming packet on eth0. That panic
is fixed by 1/7, but you get "Not allowed to delete root node" for removing
_your_ root, with "Can not delete in-use filter" for other's root (as in the
last line of the reproducer).
From: Cong Wang <hidden> Date: 2018-09-07 08:53:16
On Thu, Sep 6, 2018 at 8:50 PM Al Viro [off-list ref] wrote:
On Thu, Sep 06, 2018 at 08:23:36PM -0700, Cong Wang wrote:
quoted
Pretty sure there is a 'tp' in u32_set_parms() parameter list.
Are you saying it is not what you want? If so, why?
More importantly, why this information is again missing in your
changelog? This patch is definitely not trivial, it deserves a detailed
changelog.
quoted
our own root, sure. But there's nothing to stop doing the same via another
tcf_proto...
To my best knowledge, the place where you set ->is_root=true
is precisely same with where we set tp->root=root_ht, and it doesn't
change after set. What am I missing here?
The fact that there can be two (or more) different tcf_proto instances sharing
->data, but not ->root. And since ->data is shared, u32_get() on one tp
They have to share tp->data, that is how we link hashtables together.
will be able to return you ->root of *ANOTHER* one. So comparison with
tp->root doesn't protect you. Try this on mainline:
Hmm, it is not u32_get(), it is u32_lookup_ht() which could get another
root ht... I see.
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 100 handle 1: u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 200 handle 2: u32 divisor 1
tc filter delete dev eth0 parent ffff: protocol ip prio 100 handle 801: u32
and watch the fun as soon as you get an incoming packet on eth0. That panic
is fixed by 1/7, but you get "Not allowed to delete root node" for removing
_your_ root, with "Can not delete in-use filter" for other's root (as in the
last line of the reproducer).
Sure, please consider:
1. adding such a test case to tools/testing/selftests/tc-testing/
2. adding it in your changelog
This would save a lot of time for both of us. I don't need to ask you for
this if it is in the changelog, you don't have to explain it again.
This is a win-win.
Just FYI:
This was added when RCU was introduced to u32 fast path,
it looks like on fast path we never touch tc_u_common, we
only use tp->root, all the rest are slow paths with RTNL lock,
so it is probably fine to just remove it rather than converting
that kfree() to kfree_rcu().
Just FYI:
This was added when RCU was introduced to u32 fast path,
it looks like on fast path we never touch tc_u_common, we
only use tp->root, all the rest are slow paths with RTNL lock,
so it is probably fine to just remove it rather than converting
that kfree() to kfree_rcu().
*nod*
In any case, if u32_classify() grows that dereference, we can always
re-add ->rcu at the same time.
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-07 16:54:40
On 2018-09-06 10:35 p.m., Al Viro wrote:
On Thu, Sep 06, 2018 at 06:21:09AM -0400, Jamal Hadi Salim wrote:
[..]
Argh... Unfortunately, there's this: in u32_delete() we have
if (root_ht) {
if (root_ht->refcnt > 1) {
*last = false;
goto ret;
}
if (root_ht->refcnt == 1) {
if (!ht_empty(root_ht)) {
*last = false;
goto ret;
}
}
}
and that would need to be updated.
It is not detrimental as you have it right now but
you are right an adjustment is needed...
Deleting of a root directly should not be allowed. But
you can flush a whole tp. Consider this:
--
sudo tc qdisc add dev $P ingress
sudo tc filter add dev $P parent ffff: protocol ip prio 10 \
u32 match ip protocol 1 0xff
Which creates root ht 800
You shouldnt be allowed to do this:
--
tc filter delete dev $P parent ffff: protocol ip prio 10 handle 800: u32
---
But you can delete the tp entirely as such:
---
tc filter delete dev $P parent ffff: protocol ip prio 10 u32
--
The later will go via the destroy() path and flush all filters.
You should also be able to delete individual filters. ex:
$tc filter del dev $P parent ffff: prio 10 handle 800:0:800 u32
Where that code you are referring to is important is when
the last filter deleted - we need the caller to know
and it destroys root.
i.e you should return last=true when the last filter is
deleted so root gets auto deleted (just like it was autocreated)
However, that logics is bloody odd
to start with. First of all, root_ht has come from
struct tc_u_hnode *root_ht = rtnl_dereference(tp->root);
and the only place where it's ever modified is
rcu_assign_pointer(tp->root, root_ht);
in u32_init(), where we'd bloody well checked that root_ht is non-NULL
(see
if (root_ht == NULL)
return -ENOBUFS;
upstream of that place) and where that assignment is inevitable on the
way to returning 0. No matter what, if tp has passed u32_init() it
will have non-NULL ->root, forever. And there is no way for tcf_proto
to be seen outside of tcf_proto_create() without ->init() having returned
0 - it gets freed before anyone sees it.
Yes, the check for root_ht is not necessary - but the check for the
last filter (and testing for last) is needed.
So this 'if (root_ht)' can't be false. What's more, what the hell is the
whole thing checking? We are in u32_delete(). It's called (as ->delete())
from tfilter_del_notify(), which is called from tc_del_tfilter(). If we
return 0 with *last true, we follow up calling tcf_proto_destroy().
OK, let's look at the logics in there:
* if there are links to root hnode => false
* if there's no links to root hnode and it has knodes => false
(BTW, if we ever get there with root_ht->refcnt < 1, we are obviously screwed)
* if there is a tcf_proto sharing tp->data => false (i.e. any filters
with different prio - don't bother)
* if tp is the only one with reference to tp->data and there are *any*
knodes => false.
Any extra links can come only from knodes in a non-empty hnode. And it's not
a common case. Shouldn't thIe whole thing be
* shared tp->data => false
* any non-empty hnode => false
instead? Perhaps even with the knode counter in tp->data, avoiding any loops
in there, as well as the entire ht_empty()...
Now, in the very beginning of u32_delete() we have this:
struct tc_u_hnode *ht = arg;
if (ht == NULL)
goto out;
OK, but the call of ->delete() is
err = tp->ops->delete(tp, fh, last, extack);
and arg == NULL seen in u32_delete() means fh == NULL in tfilter_del_notify().
Which is called in
if (!fh) {
...
} else {
bool last;
err = tfilter_del_notify(net, skb, n, tp, block,
q, parent, fh, false, &last,
extack);
How can we ever get there with NULL fh?
Try:
tc filter delete dev $P parent ffff: protocol ip prio 10 u32
tcm handle is 0, so will hit that code path.
The whole thing makes very little sense; looks like it used to live in
u32_destroy() prior to commit 763dbf6328e41 ("net_sched: move the empty tp
check from ->destroy() to ->delete()"), but looking at the rationale in
that commit... I don't see how it fixes anything - sure, now we remove
tcf_proto from the list before calling ->destroy(). Without any RCU delays
in between. How could it possibly solve any issues with ->classify()
called in parallel with ->destroy()? cls_u32 (at least these days)
does try to survive u32_destroy() in parallel with u32_classify();
if any other classifiers do not, they are still broken and that commit
has not done anything for them.
Anyway, adjusting 1/7 for that is trivial, but I would really like to
understand what that code is doing... Comments?
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-09-07 17:14:39
To clarify with an example i used to test
your patches:
#0 add ingress filter
$TC qdisc add dev $P ingress
#1 add filter
$TC filter add dev $P parent ffff: protocol ip prio 10 \
u32 match ip protocol 1 0xff
#2 display
$TC filter ls dev $P parent ffff:
#3 try to delete root
$TC filter delete dev $P parent ffff: protocol ip prio 10 \
handle 800: u32
#4 nothing changes..
$TC filter ls dev $P parent ffff:
#5 delete filter
$TC filter delete dev $P parent ffff: protocol ip prio 10 \
handle 800:0:800 u32
#6 filter gone but hash table still there..
$TC filter ls dev $P parent ffff:
#7 delete tp
$TC filter delete dev $P parent ffff: protocol ip prio 10 \
u32
#8 now it is gone..
$TC filter ls dev $P parent ffff:
your patches show #6 filter as still active.
We want it to look like #8
Hope this helps.
cheers,
jamal
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-09-08 19:49:48
On Fri, Sep 07, 2018 at 08:13:56AM -0400, Jamal Hadi Salim wrote:
quoted
} else {
bool last;
err = tfilter_del_notify(net, skb, n, tp, block,
q, parent, fh, false, &last,
extack);
How can we ever get there with NULL fh?
Try:
tc filter delete dev $P parent ffff: protocol ip prio 10 u32
tcm handle is 0, so will hit that code path.
Huh? It will hit tcf_proto_destroy() (and thus u32_destroy()), but where will
it hit u32_delete()? Sure, we have fh == NULL there; what happens next is
if (t->tcm_handle == 0) {
tcf_chain_tp_remove(chain, &chain_info, tp);
tfilter_notify(net, skb, n, tp, block, q, parent, fh,
RTM_DELTFILTER, false);
tcf_proto_destroy(tp, extack);
and that's it. IDGI... Direct experiment shows that on e.g.
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match ip protocol 1 0xff
tc filter delete dev eth0 parent ffff: protocol ip prio 10 u32
we get u32_destroy() called, with u32_destroy_hnode() called by it,
but no u32_delete() is called at all, let alone with ht == NULL...