netdev - pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008]

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-next>] [day] [month] [year] [list]

Message-ID: <5468A0C5.9010409@ziu.info>
Date:	Sun, 16 Nov 2014 14:04:05 +0100
From:	Michal Soltys <soltys@....info>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>
Subject: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] -
 question

Hi,

I was wondering (probably missing some subtleties) about that particular 
patch, namely:

61c9eaf90081cbe6dc4f389e0056bff76eca19ec

Why would that qlen++ change be necessary ? As far as peeked qdisc sees 
things, the packet is already deqeued and gone - so not really part of 
the queue anymore in this context (not ever requeued either). More 
advanced qdiscs such as say fq_codel - if for example they decide to 
drop head during further enqueue operation - obviously won't even 
consider the peeked packet.

Increasing qlen from what I can see artificially shortens queue by 1. 
For some classful schedulers (say like hfsc that instantly peeks next 
packet length after dequeuing), child qdiscs will be almost all the time 
formally operating at queue size decreased by 1.
--
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