Re: [RFC] tcf_bind_filter failure handling

[Patrick McHardy <kaber@xxxxxxxxx>]

Thomas Graf wrote:

> * Patrick McHardy <41BDDB5A.9000907@xxxxxxxxx> 2004-12-13 19:11
>  
>
> > 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.
> >    
> Little misunderstanding here. I'm not aiming at replacing tcf_bind_filter
> with get.  My question is rather whether to regard tcf_bind_filter not setting
> tcf_result->class as an error or ignore it. 
>
> I'm all for ignoring it in tcindex, it requires some changes because
> it checks tcf_result.class field to see if hash bucket is non-empty if
> perfect hash is used but is not a problem at all.
>
> The tcf_class_get/put would be required to ensure proper locking during
> validation of parameters if validating the classid being last before
> changing things doesn't make sense due to the need to undo expensive
> operations required before binding.
>
> I will fix tcindex, since you also agree on simply ignoring it and regard
> the binding as an ptional locking and performance increase possibility
> given to userspace.
Yes, it should be ignored, otherwise you can't point a filter to a class
you will add later.

Regards
Patrick