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: <D5C1322C3E673F459512FB59E0DDC3290306A777@orsmsx414.amr.corp.intel.com>
Date:	Wed, 13 Jun 2007 10:51:00 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	<kumarkr@...ux.vnet.ibm.com>, <davem@...emloft.net>,
	<jamal@...erus.ca>, <herbert@...dor.apana.org.au>, <tgraf@...g.ch>,
	<kaber@...sh.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 2/2] qdisc_restart - couple of optimizations.

> - netif_queue_stopped need not be called inside qdisc_restart as
>   it has been called already in qdisc_run() before the first skb
>   is sent, and in __qdisc_run() after each intermediate skb is
>   sent (note : we are the only sender, so the queue cannot get
>   stopped while the tx lock was got in the ~LLTX case).

I somewhat disagree here.  The underlying driver can conceivably stop
the device queue even if the stack holds the queue lock during an
interrupt to clean Tx descriptors, and it finds it's out of them or
needs to grab the device for whatever reason.  Granted this is a corner
case, and the net effect would be a simple requeue of the skb, but
checking the status of the queue at the last possible moment before
entering the driver could alleviate the requeue in the time between
->dequeue() from the qdisc, and hard_start_xmit() if an event like I
mentioned happened.

I'm ok with it either way, especially since this is a corner case.  But
it does need to be considered that it can happen.

Cheers,

-PJ Waskiewicz
-
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