Re: [RFC] tcf_bind_filter failure handling

[Patrick McHardy <kaber@trash.net>]

Thomas Graf wrote:

>The handling of a failure in tcf_bind_filter is inconsistent.
>
>u32: ignore
>fw: ignore
>route: ignore
>rsvp: ignore
>tcindex: error
>
>It might be a good idea to make this consistent. So in order to validate
>the classid before making any changes we could simply lock it via get
>(see patch below), return an error if it fails  and put it back in case
>of an error further in the path or after binding the filter.
>
>Bindings not only locks the class from removal while a filter is
>pointing to it. It speeds up classyfing by saving a lookup for every
>tc_classify call. It's not really a problem if the class is not locked,
>the qdisc will look it up and falls back to a default class if it
>doesn't exists so it's rather a cosmetic/policy thing.
>
You should just fix tcindex not to care about errors in tcf_bind_filter.
bind_tcf already locks the class. Some qdiscs (like prio) map bind_filter
to get, but others (HTB, HFSC, CBQ) use a seperate counter because it is
legal to end up with a refcnt > 0 after delete. When a class with filters
pointing to it is tried to destroy they return -EBUSY, which can't be done
by looking at the refcnt.

Regards
Patrick