Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+PKT_SCHED\:\s+Initialize\s+list\s+field\s+in\s+dummy\s+qdiscs\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+PKT_SCHED\:\s+Initialize\s+list\s+field\s+in\s+dummy\s+qdiscs\s*$/: 40 ]

Total 40 documents matching your query.

1. [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: al@xxxxxxxx>; Date: Fri, 5 Nov 2004 15:16:40 +0100; The conversion to the generic list API was nice, it really helps in such a case when a poison value shows up in an oops. However it is not nice if new bugs are introduced with such changes. - if (de; /archives/netdev/2004-11/msg00196.html (10,812 bytes)
2. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 05 Nov 2004 19:18:54 +0100; Thomas Graf wrote: * Patrick McHardy <418BB7D2.6060908@xxxxxxxxx> 2004-11-05 18:26 ops->put seems to be safe even without holding dev->queue_lock. The class refcnt is only changed from userspace, and; /archives/netdev/2004-11/msg00208.html (14,282 bytes)
3. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: Hemminger <shemminger@xxxxxxxx>; Date: Fri, 5 Nov 2004 17:39:51 +0100; * Patrick McHardy <418BA66A.60804@xxxxxxxxx> 2004-11-05 17:12 Right, this is indeed the case. This doesn't fix the oops reported but will prevent the oops you are referring to which was triggerd afte; /archives/netdev/2004-11/msg00212.html (11,176 bytes)
4. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: xx>; Date: Fri, 5 Nov 2004 18:58:12 +0100; * Patrick McHardy <418BB7D2.6060908@xxxxxxxxx> 2004-11-05 18:26 You are right, this cannot be the problem. However, there is a potential risk in qdisc_destroy if dev->queue_lock is not held. I'm not; /archives/netdev/2004-11/msg00213.html (12,471 bytes)
5. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: xxxxxx>; Date: Fri, 05 Nov 2004 17:12:26 +0100; Thomas Graf wrote: - if (dev) { - struct Qdisc *q, **qp; - for (qp = &qdisc->dev->qdisc_list; (q=*qp) != NULL; qp = &q->next) { - if (q == qdisc) { - *qp = q->next; - break; - } - } - } + list_del(&q; /archives/netdev/2004-11/msg00214.html (11,954 bytes)
6. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: acc@xxxxxxxxxx>; Date: Fri, 05 Nov 2004 18:26:42 +0100; Thomas Graf wrote: * Patrick McHardy <418BA66A.60804@xxxxxxxxx> 2004-11-05 17:12 Nice catch. I can't understand how you triggered that oops, though. The noop- and noqueue-qdiscs used without qdisc_cr; /archives/netdev/2004-11/msg00217.html (12,684 bytes)
7. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: xxx (Luis R. Rodriguez); Date: Fri, 5 Nov 2004 20:43:03 +0100; * Patrick McHardy <418BC40E.8080402@xxxxxxxxx> 2004-11-05 19:18 I will double check this, there must be something wrong with one of the callers to qdisc_destroy since it's the only way entries can be; /archives/netdev/2004-11/msg00220.html (11,655 bytes)
8. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: rt@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 5 Nov 2004 16:36:50 -0800; I'll apply this, along with the builting qdisc list initializer change too just for cleanliness, thanks Thomas. Ingo Molnar noticed this refcount underflow condition in qdisc_destroy() a couple weeks; /archives/netdev/2004-11/msg00225.html (12,048 bytes)
9. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: " <davem@xxxxxxxxxxxxx>; Date: Sat, 6 Nov 2004 02:18:43 +0100; * Thomas Graf <20041105194303.GA12289@xxxxxxxxxxxxxx> 2004-11-05 20:43 I think I've found the problem and it sounds to banal to be true. qdisc_destroy uses list_del when it used to use a manual list; /archives/netdev/2004-11/msg00231.html (12,340 bytes)
10. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: as Graf <tgraf@xxxxxxx>; Date: Sat, 06 Nov 2004 02:47:44 +0100; Thomas Graf wrote: I think I've found the problem and it sounds to banal to be true. qdisc_destroy uses list_del when it used to use a manual list management which would not interfer any list walkers; /archives/netdev/2004-11/msg00233.html (13,134 bytes)
11. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: ardy <kaber@xxxxxxxxx>; Date: Sat, 6 Nov 2004 02:59:31 +0100; * Patrick McHardy <418C2D40.9020300@xxxxxxxxx> 2004-11-06 02:47 Which might have been the problem, I've been focusing on this for hours overlooking the obvious. The bug report was very well done, may; /archives/netdev/2004-11/msg00235.html (12,351 bytes)
12. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: xxxxxxxxx>; Date: Sat, 6 Nov 2004 15:50:36 +0100; The patch below transforms qdisc_list into a RCU protected list. However, this does not really fix the problem. The below example shows what can happen in case a qdisc is deleted which is classful an; /archives/netdev/2004-11/msg00243.html (16,307 bytes)
13. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: <romieu@xxxxxxxxxxxxx>; Date: Sun, 07 Nov 2004 09:57:34 +0100; Thomas Graf wrote: So using the RCU protected list only enforces the unlinking to be safe while within a list walk and the rcu callback to be deferred until the list walk is complete but may be execu; /archives/netdev/2004-11/msg00252.html (14,044 bytes)
14. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Sun, 7 Nov 2004 15:00:15 +0100; And we should switch back to this again if possible. I haven't audited all paths to dev_activate but we have at most a list addition which might not be protected with an rtnl semaphore. I'm not 100%; /archives/netdev/2004-11/msg00253.html (14,216 bytes)
15. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 07 Nov 2004 17:19:58 +0100; Thomas Graf wrote: You mean before qdisc_lookup and until the reference is released again? These are huge locking regions involving calls which might sleep and possible qdisc_destroy calling paths. S; /archives/netdev/2004-11/msg00254.html (13,062 bytes)
16. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 7 Nov 2004 17:33:30 +0100; I might have misunderstood you in this point, so you increment a refcnt in qdisc_lookup and decrement in once you're done with the reference? I thought you wanted to to bh spin locks. I'm not sure h; /archives/netdev/2004-11/msg00255.html (12,383 bytes)
17. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 07 Nov 2004 18:02:52 +0100; Thomas Graf wrote: I might have misunderstood you in this point, so you increment a refcnt in qdisc_lookup and decrement in once you're done with the reference? I thought you wanted to to bh spin loc; /archives/netdev/2004-11/msg00256.html (13,437 bytes)
18. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 7 Nov 2004 18:49:09 +0100; Right, but what about when the RTM_GETQDISC comes in before the first rcu callback is invoked? I'm not sure if this can happen in practice though. Anyways, I do think we should force the task to be; /archives/netdev/2004-11/msg00257.html (13,634 bytes)
19. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 07 Nov 2004 19:22:08 +0100; Thomas Graf wrote: Anyways, I do think we should force the task to be completed, or at least all the list unlinking, before the rtnl semaphore is given back. I'm fine with postponing the deletion of; /archives/netdev/2004-11/msg00258.html (12,546 bytes)
20. Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs (score: 1): Author: >; Date: Sun, 7 Nov 2004 20:08:41 +0100; Great, that's even better, speeds up deletion of big class trees. Thanks.; /archives/netdev/2004-11/msg00259.html (12,160 bytes)

Current List: 1 - 20
Page: [1] [2]