On Sun, Apr 17, 2005 at 07:46:16PM +0200, Patrick McHardy wrote:
>
> HTB also needs to be fixed. Destruction is usually defered by the
> refcnt until ->put(), htb_put() doesn't lock the tree. Same for
> HFSC and CBQ.
Yes you're absolutely right.
--
Visit Openswan at http://www.openswan.org/
Emai
Herbert Xu wrote:
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
qdisc_destroy can still be invoked without qdisc_tree_lock via the
deletion of a class when it calls qdisc_destroy to destroy its
leaf qdisc.
Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is a
* jamal <[EMAIL PROTECTED]> 2005-04-16 12:04
> The rule of "optimize for the common" fails miserably in this case
> because this is not a common case/usage of qdiscs.
I tend to agree. OTOH, I use exactly such setups... ;->
> I have a feeling though that the patch went in due to
> dude-optimizing-
On Sat, 2005-16-04 at 13:34 +0200, Thomas Graf wrote:
> * Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 21:23
> > On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
> > >
> > > It's not completely useless, it speeds up the deletion classful
> > > qdiscs having some depth. However, it's not w
* Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 21:23
> On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
> >
> > It's not completely useless, it speeds up the deletion classful
> > qdiscs having some depth. However, it's not worth the locking
> > troubles I guess.
>
> RCU is meant to opti
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
>
> It's not completely useless, it speeds up the deletion classful
> qdiscs having some depth. However, it's not worth the locking
> troubles I guess.
RCU is meant to optimise the common reader path. In this case
that's the packet tra
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
>
> qdisc_destroy can still be invoked without qdisc_tree_lock via the
> deletion of a class when it calls qdisc_destroy to destroy its
> leaf qdisc.
Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is another n
* Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 11:49
> On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
> >
> > Another case were it's not locked is upon a deletion of a class where
> > the class deletes its inner qdisc, although there is only one case
> > how this can happen and that's un
On Sat, 2005-04-16 at 11:49 +1000, Herbert Xu wrote:
> Here is a quick'n'dirty fix to the problem at hand. What happened
> between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started
> changing the next pointer of qdisc entries which totally confuses
> the readers because qdisc_destroy doesn
On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
>
> Another case were it's not locked is upon a deletion of a class where
> the class deletes its inner qdisc, although there is only one case
> how this can happen and that's under rtnl semaphore so there is no
> way we can have a dumper
* Steven Rostedt <[EMAIL PROTECTED]> 2005-04-15 17:54
> > ==
> > list_for_each_entry(cq, &cql, list)
> >list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list)
> > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
> > if (q->ops->cl_ops
Don't think the issue is the same. This problem is happening with
Tarhon-Onu Victor. I'm including his previous two posts from LKML here.
So you can read the whole thing in one letter. He states that the
problem started in 2.6.10-rc2 and looking at a diff, between rc1 and rc2
the list walk was ad
Didnt see the beginings of this thread - please post on netdev instead
of lkml network related questions.
The real cause seems to be an ARP issue from what i saw in the oops
posted a while back:
--
[4294692.342000] Call Trace:
[4294692.342000] [] show_stack+0xa6/0xe0
[4294692.342000] [] show_re
On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote:
> On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
>
> > So the problem should be looked in that changes to the pkt sched API,
> > the patch containing only those changes is at
>
> The bug is in this portion of code from net/sche
On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
So the problem should be looked in that changes to the pkt sched API,
the patch containing only those changes is at
The bug is in this portion of code from net/sched/sch_generic.c,
in the qdisc_destroy() function:
==
list_for_each_entry(cq, &c
On Fri, 8 Apr 2005, Tarhon-Onu Victor wrote:
I am not subscribed to this list so please CC me if you post a reply,
if you need additional info or if you suggest a patch (in which I would be
very interested).
[snip]
(Intel Xeon or Itanium, AMD Opteron, Dual P3, etc), so I'm not able to tell
if
I am not subscribed to this list so please CC me if you post a
reply, if you need additional info or if you suggest a patch (in which
I would be very interested).
Occurrence:
- the kernels must be compiled with Hyper Threading support (and
the CPU/MB must support it);
- a (tc) process is rea
17 matches
Mail list logo
