linux-toradex.git/net/sched/cls_basic.c, branch v4.4.5

net_sched: destroy proto tp when all filters are gone

2015-03-09T19:35:55+00:00

Kernel automatically creates a tp for each
(kind, protocol, priority) tuple, which has handle 0,
when we add a new filter, but it still is left there
after we remove our own, unless we don't specify the
handle (literally means all the filters under
the tuple). For example this one is left:

  # tc filter show dev eth0
  filter parent 8001: protocol arp pref 49152 basic

The user-space is hard to clean up these for kernel
because filters like u32 are organized in a complex way.
So kernel is responsible to remove it after all filters
are gone.  Each type of filter has its own way to
store the filters, so each type has to provide its
way to check if all filters are gone.

Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Acked-by: Jamal Hadi Salim
Signed-off-by: David S. Miller

net: cls_basic: return from walking on match in basic_get

2015-01-27T00:08:55+00:00

As soon as we've found a matching handle in basic_get(), we can
return it. There's no need to continue walking until the end of
a filter chain, since they are unique anyway.

Signed-off-by: Daniel Borkmann 
Acked-by: Jiri Pirko 
Cc: Thomas Graf 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller

net: sched: cls_basic: fix error path in basic_change()

2014-12-09T20:41:56+00:00

Signed-off-by: Jiri Pirko 
Reviewed-by: John Fastabend 
Signed-off-by: David S. Miller

net: sched: cls: remove unused op put from tcf_proto_ops

2014-12-09T19:49:02+00:00

It is never called and implementations are void. So just remove it.

Signed-off-by: Jiri Pirko 
Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller

net_sched: cls_basic: remove unnecessary iteration and use passed arg

2014-12-09T01:53:40+00:00

Signed-off-by: Jiri Pirko 
Acked-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller

net: sched: do not use tcf_proto 'tp' argument from call_rcu

2014-10-06T22:02:33+00:00

Using the tcf_proto pointer 'tp' from inside the classifiers callback
is not valid because it may have been cleaned up by another call_rcu
occuring on another CPU.

'tp' is currently being used by tcf_unbind_filter() in this patch we
move instances of tcf_unbind_filter outside of the call_rcu() context.
This is safe to do because any running schedulers will either read the
valid class field or it will be zeroed.

And all schedulers today when the class is 0 do a lookup using the
same call used by the tcf_exts_bind(). So even if we have a running
classifier hit the null class pointer it will do a lookup and get
to the same result. This is particularly fragile at the moment because
the only way to verify this is to audit the schedulers call sites.

Reported-by: Cong Wang 
Signed-off-by: John Fastabend 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller

net: sched: remove tcf_proto from ematch calls

2014-10-06T22:02:32+00:00

This removes the tcf_proto argument from the ematch code paths that
only need it to reference the net namespace. This allows simplifying
qdisc code paths especially when we need to tear down the ematch
from an RCU callback. In this case we can not guarentee that the
tcf_proto structure is still valid.

Signed-off-by: John Fastabend 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller

net_sched: remove the first parameter from tcf_exts_destroy()

2014-09-28T21:29:01+00:00

Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 
Acked-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller

net: sched: cls_basic use RCU

2014-09-13T16:30:25+00:00

Enable basic classifier for RCU.

Dereferencing tp->root may look a bit strange here but it is needed
by my accounting because it is allocated at init time and needs to
be kfree'd at destroy time. However because it may be referenced in
the classify() path we must wait an RCU grace period before free'ing
it. We use kfree_rcu() and rcu_ APIs to enforce this. This pattern
is used in all the classifiers.

Also the hgenerator can be incremented without concern because it
is always incremented under RTNL.

Signed-off-by: John Fastabend 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

sched, cls: check if we could overwrite actions when changing a filter

2014-04-28T03:42:39+00:00

When actions are attached to a filter, they are a part of the filter
itself, so when changing a filter we should allow to overwrite the actions
inside as well.

In my specific case, when I tried to _append_ a new action to an existing
filter which already has an action, I got EEXIST since kernel refused
to overwrite the existing one in kernel.

This patch checks if we are changing the filter checking NLM_F_CREATE flag
(Sigh, filters don't use NLM_F_REPLACE...) and then passes the boolean down
to actions. This fixes the problem above.

Cc: Jamal Hadi Salim 
Cc: David S. Miller 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller