netdev - d80211: How does TX flow control work?

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: <459A5945.80909@web.de>
Date:	Tue, 02 Jan 2007 14:08:21 +0100
From:	Jan Kiszka <jan.kiszka@....de>
To:	netdev@...r.kernel.org
CC:	Jiri Benc <jbenc@...e.cz>, Ivo Van Doorn <ivdoorn@...il.com>,
	rt2400-devel@...ts.sourceforge.net
Subject: d80211: How does TX flow control work?

Hi,

can someone explain how TX flow control in d80211 is supposed to work? I
failed to understand the full design so far.

What I (think to) understand is that a low-level drivers call
ieee80211_stop_queue() if they run out of buffers. That flips a
per-queue bit (IEEE80211_LINK_STATE_XOFF), prevents that any further
frame is passed to the low-level TX routine, and can cause that up to
*one* packet per queue is stored in
ieee80211_local::pending_packets[queue]. But it looks to me like nothing
prevents ieee80211_tx() being invoked even in case that there is already
some stuff in that single-packet storage.

That in turn triggers WARN_ONs in ieee80211_tx() under high load for me
(with rt2500usb). And it should also cause orphaned skbs because the
storage is overwritten in that case. Either I'm blind or something is
fishy...

Jan

Download attachment "signature.asc" of type "application/pgp-signature" (251 bytes)