netdev - Re: [PATCH 2/2] qdisc_restart - couple of optimizations.

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]

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