Re: [RFC] tcf_bind_filter failure handling

[Patrick McHardy <kaber@xxxxxxxxx>]

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