[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080913011018.GA10242@gondor.apana.org.au>
Date: Fri, 12 Sep 2008 18:10:18 -0700
From: Herbert Xu <herbert@...dor.apana.org.au>
To: David Miller <davem@...emloft.net>
Cc: jarkao2@...il.com, netdev@...r.kernel.org, kaber@...sh.net
Subject: Re: [PATCH take 2] pkt_sched: Fix qdisc_watchdog() vs.
dev_deactivate() race
On Fri, Sep 12, 2008 at 04:10:05PM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2@...il.com>
> Date: Fri, 12 Sep 2008 08:02:49 +0000
>
> > Alas I'm still not sure how this whole peek idea is going to be
> > implemented (dequeuing after peeking doesn't have to give us the
> > same skb since in the meantime e.g. in HTB some other class with
> > higher prio can get enough tokens etc., and if there is a break
> > for transmit in the meantime with possible enqueuing, or we can
> > deal with something like sch_multiq, which depends on the current
> > state of the tx_queues, this all looks even more interesting).
>
> That's a good point.
>
> Well, once that is discussed and resolved, at least the patch I
> posted can be used as a base for implementation :-)
Well we should remember the skb returned by peek, and then return
it on the next dequeue. If peek hasn't been called since the
last dequeue then it's equivalent to the current dequeue.
This works for the two scenarios where we're planning to use
peek since they'll both call dequeue immediately.
It'd even work if there was a large gap (i.e., a sleep) after
the peek since we'd just peek again after waking up.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists