CBQ destroys its classes by traversing the hashtable and thus classes
are not destroyed from root to leafs which means that class Y being
a subclass of class X may be destroyed before X. This is a problem
if a filter is attached to class X (parent) classifying into class Y
(result). In case Y gets deleted before X the filter references an
already deleted class while trying to unbind (cbq_unbind_filter).
Therefore all filters must be destroyed before destroying classes. An
additional BUG_TRAP has been added to document this not so obvious case.

The BUG can be triggered with the following commands:
 qdisc add dev  root handle 10:0 cbq bandwidth 100Mbit avpkt 1400 mpu 64
 class add dev  parent 10:0  classid 10:12 cbq bandwidth 100mbit        rate 100mbit allot 1514 prio 3 maxburst 1 avpkt  500 bounded
 class add dev  parent 10:12  classid 10:13 cbq bandwidth 100mbit        rate 100mbit allot 1514 prio 3 maxburst 1 avpkt  500 bounded
 filter add dev  parent 10:12 protocol ip prio 10 u32 match ip protocol 6 0xff flowid 10:13
 qdisc del dev  root

The deletion ordering in the above case is: 10:0 -> 10:13 -> 10:12
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>