netdev
[Top] [All Lists]

Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs
From: Thomas Graf <tgraf@xxxxxxx>
Date: Fri, 5 Nov 2004 20:43:03 +0100
Cc: davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, spam@xxxxxxxxxxxxx, kuznet@xxxxxxxxxxxxx, jmorris@xxxxxxxxxx
In-reply-to: <418BC40E.8080402@xxxxxxxxx>
References: <418B4C7C.8000402@xxxxxxxxxxxxx> <20041105115430.GP19714@xxxxxxxxxxxxxx> <418B4C7C.8000402@xxxxxxxxxxxxx> <20041105141640.GQ19714@xxxxxxxxxxxxxx> <418BA66A.60804@xxxxxxxxx> <20041105163951.GY12289@xxxxxxxxxxxxxx> <418BB7D2.6060908@xxxxxxxxx> <20041105175812.GZ12289@xxxxxxxxxxxxxx> <418BC40E.8080402@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* Patrick McHardy <418BC40E.8080402@xxxxxxxxx> 2004-11-05 19:18
> Yes, but there doesn't seem to be a path where this is true.

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 removed from qdisc_list and otherwise the oops wouldn't
show up with the POISON1.

> __qdisc_destroy is called from a rcu-callback, not directly from
> qdisc_destroy.

You're indeed right, I haven't noticed queue_lock being a softirq
spinlock, stupid me.

So to have qdisc_destroy be reliable we should either make sure
dev->queue_lock is held for every call or switch to list_del_rcu.
since qdisc_destroy might be called from bh context.

I will audit all paths, I'm pretty sure the reported oops is
somehow related to this.

<Prev in Thread] Current Thread [Next in Thread>