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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070614111920.GA25207@gondor.apana.org.au>
Date:	Thu, 14 Jun 2007 21:19:20 +1000
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Krishna Kumar <kumarkr@...ux.vnet.ibm.com>
Cc:	davem@...emloft.net, jamal@...erus.ca,
	peter.p.waskiewicz.jr@...el.com, tgraf@...g.ch, kaber@...sh.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] qdisc_restart - couple of optimizations.

On Wed, Jun 13, 2007 at 02:10:49PM +0530, Krishna Kumar wrote:
> 
> - BUG_ON((int) q->q.qlen < 0) was a relic from old times when -1
>   meant more packets are available, and __qdisc_run used to loop
>   when qdisc_restart() returned -1. During those days, it was
>   necessary to make sure that qlen is never less than zero, since
>   __qdisc_run would get into an infinite loop if no packets are on
>   the queue and this bug in qdisc was there (and worse - no more
>   skbs could ever get queue'd as we hold the queue lock too). With
>   Herbert's recent change to return values, this check is not
>   required.  Hopefully Herbert can validate this change. If at all
>   this is required, it should be added to skb_dequeue (in failure
>   case), and not to qdisc_qlen.

Yes I agree that this check is no longer critical.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ