lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 12 Sep 2008 18:10:18 -0700
From:	Herbert Xu <>
To:	David Miller <>
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 <>
> 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.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <>
Home Page:
PGP Key:
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists