From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 19:55:22 +0400
> Hello!
>
> Remove artificial limitation for sfq queue limit.
>
> This is followup to Patrick's patch. A little optimization to enqueue
> routine allows to remove artificial limitation on queue length.
>
> Plus, t
Hello!
Remove artificial limitation for sfq queue limit.
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 19 Sep 2007 15:08:22 +0200
> Alexey Kuznetsov wrote:
> > Hello!
> >
> >>CCed Alexey just to be safe, but I think the patch should be fine.
> >
> >
> > Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> > not nice to h
Alexey Kuznetsov wrote:
> Hello!
>
>>CCed Alexey just to be safe, but I think the patch should be fine.
>
>
> Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> not nice to have the bug in kernel. Plus, code remains creepy, the check
>
> + if (++sch->q.qlen < q->lim
Hello!
> OK the off-by-one prevents an out-of-bounds array access,
Yes, this is not off-by-one (off-by-two, to be more exact :-)).
Maximal queue length is really limited by SFQ_DEPTH-2, because:
1. SFQ keeps list of queue lengths in array of length SFQ_DEPTH.
This means length of queue must
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 21:15:28 +0200
> OK the off-by-one prevents an out-of-bounds array access, which
> would cause a crash itself. Despite what I said above, sfq does
> try to handle dequeues while empty, but forgets to update q->tail
> when dropping th
Patrick McHardy wrote:
> Never mind, I found the reason. When enqueuing the packet, sfq_enqueue
> contains an off-by-one in the limit check (which IIRC is there for a
> reason, but I can't remember right now) and drops the packet again.
> dev_queue_xmit() calls qdisc_run() anyway and the empty qdis
Patrick McHardy wrote:
> Chuck Ebbert wrote:
>
>>Limit of 1 is forbidden, crashes with 2, works with 3:
>>
>>>From disassembling sch_sfq.ko it seems that it is on line 360 of sch_sfq.c:
>>sch->qstats.backlog -= skb->len;
>>where "skb" is an invalid pointer:
>
>
>
> Is it a NULL pointer or s
Chuck Ebbert wrote:
> Limit of 1 is forbidden, crashes with 2, works with 3:
>
>>From disassembling sch_sfq.ko it seems that it is on line 360 of sch_sfq.c:
> sch->qstats.backlog -= skb->len;
> where "skb" is an invalid pointer:
Is it a NULL pointer or something random?
-
To unsubscribe from
Limit of 1 is forbidden, crashes with 2, works with 3:
https://bugzilla.redhat.com/show_bug.cgi?id=219895
=
If the defect is produced at a console (as in ctrl-alt-f<0-6>) a kernel stack
trace can be seen the moment "ping" is invoked. Since the stack trace is not
written to the /var/log
10 matches
Mail list logo
