On Wed, 2006-11-01 at 01:54 -0800, Amnon Aaronsohn wrote:
> > > So it is an optimization - not a bug then,
> > correct?
>
> It's a bug fix that happens to be an optimization :)
>
>
> > No matter what you set skb->priority to, that gets
> > translated
> > by prio2band[] which should only point to actually
> > initialized
> > queues.
>
> That's not correct. If prio_classify() sees that
> TC_H_MAJ(skb->priority) equals the qdisc's handle, it
> uses
> TC_H_MIN(skb->priority)-1 as the band number. No
> prio2band[]
> involved.
Are you are refering to this code?
u32 band = skb->priority;
...
...
band = TC_H_MIN(band) - 1;
if (band > q->bands)
return q->queues[q->prio2band[0]];
return q->queues[band];
You will always point to correctly initialized queues with any
value of skb->priority.
That doesnt mean your code should be setting it to some outrageous
value - that would be a bug on your part.
> That's how the CLASSIFY iptables target (for
> example) can set the band number.
>
> I take that to be a feature of PRIO -- that you can
> set the band directly.
>
yes, but where is the bug?
> > If your netfilter module is accessing the PRIO qdisc
> > data
> > structures directly, you're not really supposed to
> > do that.
>
> I'm only setting skb->priority. It can even be done
> (indirectly) from user space using setsockopt()
> SO_PRIORITY option.
>
not just that, it can also be derived from a packet
being forwarded, vlan 8012p outbound etc; but thats besides
the point.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
