Re: [RFC] tcf_bind_filter failure handling

[Patrick McHardy <kaber@trash.net>]

Thomas Graf wrote:

>* Patrick McHardy <41BDDB5A.9000907@trash.net> 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