netdev - Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080819134230.GA6043@gondor.apana.org.au>
Date:	Tue, 19 Aug 2008 23:42:31 +1000
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, jussi.kivilinna@...et.fi,
	jarkao2@...il.com, netdev@...r.kernel.org
Subject: Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree_skb

On Tue, Aug 19, 2008 at 03:20:04PM +0200, Patrick McHardy wrote:
> 
> I might have misunderstood you, but the way I imagine force_dequeue
> is that it would give you the packet peeked at, even if a higher
> priority packet is available.
> 
> But actually I don't understand the use for force_dequeue at all,
> assuming ->peek behaves correctly ->dequeue should already hand
> out the correct packet.

You're quite right, we don't need a forced dequeue at all because
all dequeueing and enqueueing occur under the root qdisc lock, so
the peek result has to be the same as that of the next dequeue.

Problem solved :)

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